Why ban XSS instead of flagging it?

Question

Consider a browser that allows an XMLHttpRequest downloaded from foo.net to make requests to bar.net, but attaches a XHR-Origin: http://foo.net (or possibly a more descriptive value like http://foo.net/trustedapp.js). The XHR couldn't touch that header and the server could set rules based on where the XHR-instantiating code comes from.

Since the W3C's specification (albeit relaxed with CORS) is more extreme than this, what did they find wrong with this technique? What vulnerabilities exist that truly require an XSS ban?

Answer 1

There are websites out there, that will not be updated as soon as the first browser supports your proposal. Those sites will not check the XHR-Origin header and are therefore vulnerable.

Vulnerability example

Let assume you are logged in to your bank. Without logging out, you visit another website. This website sends an XHR-request to your bank to request a JSON response, which is used in the account history view.

Yes, this request will have a XHR-Origin header, but if the bank software is not adjusted, it will reveal sensitive data.

So it is the responsibility of the browser not to break existing SOP restrictions.

Is CORS fully SOP compatible?

The CORS specification makes a number of exceptions for which the preflight check is not required. Those are based on situations, in which the SOP was never enforced in the psat (e. g. form submissions).

The problem in the current draft is, that it is solely based on the Content-Type header, but web applications tend to ignore it.

There was a nice talk by Shreeraj Shah at Blackhat Europe 2012 on HTML5 Top 10 Threats: Stealth Attacks and Silent Exploits

Answer 2

What vulnerabilities exist that truly require a [Cross-Site Request] ban?

XHR as implemented automatically carries cookies with the request. This means that if the server assumes that requests that have the proper cookie come from a page served by their servers they are vulnerable to csrf (Cross-Site Request Forgery). Since XHR allows the invoking script to programmatically inspect the result in ways that <form> tags don't, cross-site XHR allows exploits that broke the assumptions made by a lot of server writers before AJAX become well-known.

Because of these old assumptions, CORS and competing mechanisms allow sites to opt-into programmatic API access and credential forwarding.