Same Origin Policy - XHR response

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.