The ability for extension to tamper with Cross-Origin Resource Sharing (CORS) headers disables the Same Origin Policy (SOP) in Opera

[doliere]

doliere last edited by

We would like to bring into discussion an extension capability we thing represent a serious threat: that is the ability for an extension to manipulate CORS headers and make successful unauthorized cross-origin requests.

Simply put, an application A makes an XHR request to B, which does not respond with any CORS headers. This means that normally, any data returned by B will not be delivered to A. Unfortunately, this is not always true. An extension in the browser can add the necessary CORS headers to the response, causing the data to be delivered to A.

There are around 10% of extensions that have the necessary permissions (webRequest, webRequestBlocking, host permissions) to tamper with cross-origin requests/responses headers in order to authorized such unauthorized cross-origin accesses.
The CORS Toggle extension ( https://addons.opera.com/en/extensions/details/cors-toggle/ ) is the only extension we found effectively tampering with CORS headers to allow cross-origin requests.
This extension can potentially break legitimate CORS headers because of an misunderstanding of the CORS mechanism. It always changes or adds the value of the Access-Control-Allow-Origin response header to *. This has the consequence of breaking legitimate CORS headers with credentials.
Installing this extension prevents you from playing youtube videos

But we wanted to know how vendors consider the ability for extensions to manipulate CORS headers. To do so, we wrote the CORSER extension and submitted it for publication.
We were surpised that CORSER successfully passed extension review process and is now a publicly available for download ( https://addons.opera.com/en/extensions/details/corser-authorize-cors-requests/ ). This was done only for research purposes, and the extension is not collecting any user information for us. However, if an attacker (say our A application) is aware of such extension being installed in the user's browser, then it can make successfull cross-origin requests to fetch any data from B, whatever B is: Gmail, Facebook, Twitter, bank application, etc.
Doing so, we confirmed that tampering with CORS headers is considered benign from the point of view of browser vendors, despite the fact that such practice has the consequence of disabling the Same Origin Policy in browsers regarding cross-origin requests.

We would like to know your thoughts about this particular extensions capability.
As for us, we think that the ability for extensions to tamper with CORS and other security-critical headers (CSP, X-Frame-Options) must not be granted directly with permissions like webRequest and webRequestBlocking. We argue that tampering with such headers must be forbidden by default (as is the case for some requests headers such as cache headers) or extensions would have to request dedicated permissions in order to tamper with those headers. For instance, an extension that is willing to tamper with the Access-Control-Allow-Origin header would have to declare it in its permissions. This way, browser vendors can notify users about the fact that an extension that is being installed is requesting the capability to tamper with the declared CORS headers.

[doliere]

doliere @doliere last edited by

Any comment about this issue ?

[burnout426]

burnout426 Volunteer last edited by

Some Opera staff have been FYI'd about it, but that's all I know.

[doliere]

doliere @burnout426 last edited by

@burnout426 Ok thanks !