search

ProtonMail / WebClients

Monorepo hosting the proton web clients
GNU General Public License v3.0
4.35k stars 553 forks source link

CSP blocking List-Unsubscribe POST request in ProtonMail (both BETA and non-BETA) #196

Closed charukiewicz closed 3 years ago

charukiewicz commented 4 years ago

Hi, I emailed this bug to support@protonmail.com last week but did not get a reply, so I figure this would be a good place to post it.

I'm using the BETA version of the ProtonMail web application (beta.protonmail.com), but have also tested this functionality on the non-BETA web application and the issue described below is present in both.

To Reproduce

The web client's implementation of the List-Unsubscribe functionality is failing due to the Content-Security-Policy. The screenshot below shows an example:

Screenshots

When clicking 'Unsubscribe' from a mailing list email that defines a POST URL in List-Unsubscribe:

Screenshot from 2020-07-30 15-10-29

The following error occurs:

protonmail-one-click-unsub-csp

Desktop (please complete the following information):

Additional context

The issue is what is stated in the console error—the XHR POST request is failing because the connect-src directive won't allow it.

This can be fixed by changing the directive from connect-src 'self' blob: to something like connect-src 'self' blob: https:, which would allow XHR requests to any URL over TLS, but that may still be too strict, as some sites may include a List-Unsubscribe header that contains a non-HTTPS url. You may have to include both https: and http: in connect-src for this to work.

bartbutler commented 4 years ago

Hi @charukiewicz , sorry about the slow reply from support, we did receive your message and were discussing internally how to fix it. We'll probably do it via an API route for the client to request that the server send the unsubscribe on its behalf, as I think allowing unrestricted XHR to any domain in the CSP would be an unacceptable security risk.

charukiewicz commented 4 years ago

@bartbutler makes sense. Definitely a good approach. With the server making the request on behalf of the browser, you also have the benefit of not getting blocked by a misconfigured CORS policy that the mailing list server has. Unless they explicitly include something like:

access-control-allow-origin: *
access-control-allow-methods: POST

as OPTIONS headers, the endpoint will not work in most modern browsers, since they will refuse to make cross-origin requests.

bartbutler commented 4 years ago

Yes, misconfigured CORS could also be a problem in certain cases with the client-side approach--we hadn't thought of that. In any case, server-side definitely seems to be the right way to go.