Same Origin Policy - XHR response

Question

I know that Same Origin Policy (SOP) prevents a page/script from one origin to read response from another origin, but it does not prevents the page/script from making a XMLHttpRequest (XHR) request to a different origin. From Mozilla's Developer site:

• Cross-origin writes are typically allowed. Examples are links, redirects and form submissions. Certain rarely used HTTP requests require preflight.
• Cross-origin reads are typically not allowed, but read access is often leaked by embedding. For example you can read the width and height of an embedded image, the actions of an embedded script, or the availability of an embedded resource.

My question: If it only prevents page/script from reading the response from another origin, can't we just use a proxy listener like Burp or a sniffer like wireshark to capture the response before it even reaches the browser (where SOP is implemented)? Why does the server even respond to such requests from another origin? Shouldn't they only respond when Cross-origin resource sharing (CORS) is enabled on them?

Answer 1

If it only prevents page/script from reading the response from another origin, can't we just use a proxy listener like Burp or a sniffer like wireshark to capture the response before it even reaches the browser (where SOP is implemented)?

These are two different types of attack. Preventing reads from another origin prevents an attacker's site (evil.example.com) that the user has visited from making an XHR request to the site that the user is logged into (webmail.example.com) and getting the data. In this case it is stopping other websites from reading the user's email messages.

If you can configure the user's machine to use an intercepting proxy or if you can position Wireshark listening on promiscuous mode on the user's network then it is likely that as the attacker, you do not need a cross domain XHR request - you could just observe normal traffic. An exception to this is in the case of attacks such as POODLE. For example, if you could listen to traffic over the network, but the user's connection is made to the website using SSL, you may need to inject XHR traffic as a MITM in order to decrypt one byte at a time via the POODLE attack vector.

The Same Origin Policy does not help here, but if it did not exist there would be no need for the MITM attack nor the POODLE vector. The Same Origin Policy defends against some web based attacks that would otherwise be possible, nothing more.

Why does the server even respond to such requests from another origin? Shouldn't they only respond when Cross-origin resource sharing (CORS) is enabled on them?

Yes, it would be a hell of a lot more secure if servers only responded to requests from their own origins. However, this would break most of the internet if it was implemented as standard in new web server releases. It would also be possible to create a browser that did not make cross origin requests. Nobody will use it because it will not work on many sites.

You can in fact disable 3rd party cookies in most browsers. This would in effect make cross origin AJAX requests anonymous, as no cookies would ever be sent. Certainly Chrome will prevent setting or reading cookies, other browsers may only restrict the setting of such cookies. Of course if another authentication method is used, such as basic HTTP auth, it can't help you here. However, if you try it, for the most part you will be able to see which functionality breaks.

Why does the server even respond to such requests from another origin?

The Origin browser header is not read until headers are parsed, and at that point the browser has already sent cookies across - any restriction on cross origin would be better implemented at browser level because a web server will not be able to block the request before it is sent.

Allowing cross origin requests is the way things have worked historically and security needs to be balanced with compatibility. CORS has been designed in such as way that if the server does not opt into CORS, the security level is just the same as using a pre-CORS browser. Before CORS it was possible for sites to make requests to other domains via forms or resource requests (but not via XHR), and it is the same now. If you think about it from the server's perspective, an XHR GET request is just the same as including an image from another domain using an <img /> tag. An XHR POST request is just the same as creating a form that submits to another domain.

You could configure your server to block these requests (say using the Origin header), and this is actually a valid way of preventing CSRF attacks. This should be done on a case-by-case basis though, and it should be borne in mind that the presence of this header can vary between browsers and versions (e.g. no older browser support).

Note that this would not help in your example as a MITM could, in most cases, simply just spoof the Origin.

Shouldn't they only respond when Cross-origin resource sharing (CORS) is enabled on them?

All the problems with cross origin requests have been solved in some way such as browsers all following the Same Origin Policy and websites using tokens to prevent CSRF. This is the web - insecure by default. If a website is developed with security in mind, these problems can be overcome.

Answer 2

Why does the server even respond to such requests from another origin? Shouldn't they only respond when Cross-origin resource sharing (CORS) is enabled on them?

For the server a CORS XHR and a cross-site request triggered by including the resource (i.e. <img src=, <script src=) or a resource accessed by a link (<a href=) all look to similar and can not reliably distinguished. This is due to the existing architecture of the web and you can not expect all servers to change the behavior just because some web application like to use CORS XHR.

It is also usually not a problem if a resource can be accessed this way. The only real problem is if you can trick the user and its browser to access a site with XHR while logged in into this site (that is browser sends session cookie), because then you might use XHR to extract sensitive information and forward them to the attacker. Thus the protection is added where the problem starts: the browser sends the session cookie to the external site on all requests and thus the browser should make sure that Same Origin Policy can only be weakened (i.e. read from external site) if the external site explicitly agreed to it, i.e. is aware that this request is cross-origin and checked and allowed this origin.

CORS XHR rules do not see the user of the browser as the potential attacker, because this user can access the resource anyway. Instead it sees some external attacker as the problem, which tries to extract information from a site where the user is logged in. This is in a way similar to CSRF, but CSRF is only for triggering actions and not reading the results. Thus it does not matter if the user itself installed some MITM solution to watch traffic. If the attacker would be able to install such thing it would be a danger indeed, but then the attacker would not need XHR at all because classical includes (<img src= etc) would already be enough to trigger the access to the resource. Therefore this attack vector does not need to be considered specifically for CORS XHR.

Answer 3

can't we just use a proxy listener like Burp or a sniffer like wireshark to capture the response before it even reaches the browser

Firstly, a Cross-site request forgery (CSRF) attack definitely does not assume or imply that the attacker can intercept (MITM) the network connection. If you can man-in-the-middle (MITM) your victim then a CSRF attack is almost redundant because you could just observe authentication data (eg. session cookies) and log in yourself, at best a CSRF might be useful in causing them to expose their authentication data without having to wait for them to visit your target site. In general though, if you have the capability to MITM your victim then you have more effective attack vectors available than a regular CSRF.

Secondly, even if you could MITM your victim and it was useful to observe the response of a request which would otherwise be prevented by SOP, most valuable targets would employ SSL/TLS. This will prevent you from being able to observe the response, and if you're able to compromise SSL/TLS (such as by installing a malicious CA certificate on their machine) then you probably also have better attack vectors available.

Why does the server even respond to such requests from another origin?

It's not the web servers responsibility to enforce SOP and it really only makes sense in the context of a web browser. A web browser can be sure which page is making which request, but a server has no idea what page is making the request other than the referrer header and there's no guarantees about the integrity of that data.

As for why a browser allows the request to be made in the first place, I assume it's because the browser can't evaluate the Access-Control-Allow-Origin until it receives the response.