How does CORS prevent XSS?

  • I recently learned about CORS and got the impression that its purpose is to prevent XSS. With CORS, the browser blocks requests to different domains, unless particular headers are in place.

    But if a person with malicious intent injects some JavaScript into a page to steal users' cookies and send them to a URL he controls, all he has to do is add the following header on the server side to make the request work anyway:

    Access-Control-Allow-Origin: *

    So how does CORS prevent XSS? Or did I misunderstand the purpose of CORS, and it simply has nothing to do with XSS per se?

    `all he has to do is add the following header on the server side to make the request work anyway` - if somebody has access to HTTP header config on the server there are bigger problems than cross-domain attacks.

    He can do that because it's his server (in the scenario I suggested): "a URL he controls".

  • marstato

    marstato Correct answer

    5 years ago

    TL;DR: How does CORS prevent XSS? It does not. It is not meant to do so.

    CORS is intended to allow resource hosts (any service that makes its data available via HTTP) to restrict which websites may access that data.

    Example: You are hosting a website that shows traffic data and you are using AJAX requests on your website. If SOP and CORS were not there, any other website could show your traffic data by simply AJAXing to your endpoints; anyone could easily "steal" your data and thus your users and your money.

    In some cases that sharing of data (Cross Origin Resource Sharing) is intended, e.g. when displaying likes and stuff from the Facebook API on your webpage. Simply removing SOP to accomplish that is a bad idea because of the reasons explained in the above paragraph. So CORS was introduced.

    CORS is unrelated to XSS because any attacker who can place an evil piece of JavaScript into a website can also set up a server that sends correct CORS headers. CORS cannot prevent malicious JavaScript from sending session ids and permlogin cookies back to the attacker.

    Whether or not SOP and CORS were there, any other website could proxy its users' requests.

    @tepples: But in this case the cookies for the original site will not be sent with the request and thus it would not be possible to read data which only the logged in user can see.

    @SteffenUllrich That would explain the behavior if the same-origin policy just blocked cookies. But it blocks client-side scripted access even to public resources that the user can access without cookies.

    Correct. But this is how CORS works - as everything else, it has its weaknesses.

    Exactly. CORS doesn't restrict or prevent anything. CORS is intended to provide a controlled way to *relax* the restrictions imposed by the same-origin policy. Without CORS, the web would still be just as secure (though not as functional).

    Can't other sites access your public website data indirectly via- the server side? Isn't it *only* preventing willing clients from accessing your websites data while visiting another website? If my understanding is correct, your answer is wrong and this only specifically stops sites from directing a non-malicious user's browser to your site's data via- client side js.

    Yes, they can unless the sensitive data is protected with a login. A foreign website has no access to the session cookies of the "target"/"cors-protected" website. Thus, a malicious server cannot send a valid request for the data - only the users browser and the resource owning party can construct a valid request

    The example is misleading. This is not the purpose of CORS. Your rival can make a similar website to your, which on the backend would call your server with proper origin headers, and CORS won't stop it.

    @GeorgiiOleinikov Yes, they could. But in that case i can effectively block their IPs without affecting my legitimate users. This *is* the purpose of CORS. You can post your own answer if you think that CORS has a fundamentally different purpose.

    @marstato Can you block the entire AWS fleet address space? What if some of your legitimate users are using proxy on AWS? The purpose of CORS in my opinion is to relax SOP, and purpose of SOP is to make sure CSRF attacks aren't performed with Javascript

    @GeorgiiOleinikov Depending on the use case, yes. Legitimate end users dont have an AWS IP. Generally thats a good point. I havent read up on the W3C documents on that - they will provide clarification as to what the intent behind CORS is.

    @GeorgiiOleinikov I think the point is that your proxy server could not pretend to be that someone else. i.e. it can't proxy requests to pretending to be a logged in user such as Alice as your AWS server does not have access to her cookie information. That is why the CORs adds a layer of protection.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM