6 ms·
CORS is confusing to understand because the kind of attack it protects against is confusing. CORS does not protect endpoints against malicious clients, since y
by goto11 5y ago
CORS is confusing to understand because the kind of attack it protects against is confusing.
CORS does not protect endpoints against malicious clients, since you can always just make the same request outside of a browser. And it doesn't protect any site from making or receiving cross-site requests, since CORS can always be disabled on the server side.
CORS protect against the scenario where a malicious site tricks an unmodified browser to make a cross-site request to a legitimate site. If the user has an authentication cookie for the legitimate site, the cookies will be sent along with the request. So the malicious site can perform transactions in the legitimate site on behalf of the user, despite not having direct access to the authentication cookie.
CORS is further complicated because certain forms of cross-site requests have always been allowed by browsers, and therefore must remain enabled by default for backwards compatibility. GET requests to separate sites is allowed, since this has always been allowed e.g. to embed images from other domains. POST requests are allowed with the caveat that you can't inspect the result, because you have always been able to initiate a post to a different site from a html form.
- JanSt 5y agoAgain, CORS does not protect, the SOP does :-)
- goto11 5y agoYou can consider CORS a relaxation on top of SOP (same-origin policy), since CORS allows you to opt-in to certain cross-site requests which are not allowed under SOP. Then again, SOP allows certain requests like 'PUT' and 'DELETE' requests back to the origin server which was not allowed before SOP, so in that sense SOP is also a relaxation. Bit it is a good point that CORS enables more forms of cross-site requests than what is allowed under the same-origin policy. But the requests are enabled under certain confusing restrictions which is better understood if you understand the scenarios they are designed to protect against.
- JanSt 5y agoSOP is certainly not a relaxation. SOP restricts all those cross-origin request. I don't quite understand what you mean with PUT and DELETE not being allowed before SOP? What exact operations where not possible before SOP and are now (and pose a security risk?)
- goto11 5y agoIt was not possible to initiate a PUT or DELETE request from browsers until XMLHttpRequest with same-origin-policy was introduced.
- JanSt 5y agoThat doesn't matter at all in a security context. POST can (and is used) for everything DELETE and PUT are used. Adding DELETE and PUT did not relax anything. The only question is whether requests are restricted (i.e. in terms of sending resources like cookies).
- goto11 5y agoIf that is the case, then SOP does not restrict anything either, since you can still send cross-origin POST requests under single-origin-policy. I don't think this is a useful way to look at things.
- feanaro 5y agoSOP should primarily be understood as a restriction on reading responses, not making requests.
- SahAssar 5y agoSOP certainly does make restrictions on making requests, like setting any non-default headers (including content-type). It is one of the reasons that validating content-type to not be one of the normal form values used to be a valid way to handle CSRF for APIs.
- fivea 5y ago> Again, CORS does not protect, the SOP does :-) This is simply false. You are somehow wrongly assuming that only same-origin requests exist or are needed. This scenario never existed in the real world beyond the scope of small personal projects.
- feanaro 5y agoTo explain your error a bit less facetiously, the point my sibling is making is that SOP is the default policy, which is maximally restrictive. CORS is a technology used to relax SOP, to make it less restrictive. So it is not CORS that protects, since it restricts nothing, but SOP (potentially relaxed by CORS).
- shukantpal 5y ago> You are somehow wrongly assuming that only same-origin requests exist or are needed. No they are not making that assumption.
- JanSt 5y agoHow am I assuming that? How exactly does CORS add security?
- lolinder 5y agoStrictly speaking you are correct, but is there any actual harm in people using the word CORS as a shorthand for the whole system of Same Origin Policy + Cross Origin Resource Sharing? If there's some kind of dangerous misunderstanding that stems from this, I can understand emphasizing it, but otherwise it just feels pedantic.
- JimDabell 5y ago> is there any actual harm in people using the word CORS as a shorthand for the whole system of Same Origin Policy + Cross Origin Resource Sharing? Yes. Consider: > Hey, the results from the security audit are in and it’s mostly fine, except the pen testers said that we don’t need CORS for our /foo endpoint. Can you disable it entirely please? If you understand what CORS is, you will interpret that as “Our security is too lax, let’s tighten it up by removing the exceptions to the SOP that CORS grants” and correctly increase security. If you think CORS is how you described, you will misinterpret that as “We don’t need security for this endpoint, open it up to the world with Access-Control-Allow-Origin: *” and create a massive security vulnerability. If you think of CORS as something that restricts things in the name of security, your understanding is 100% backwards from what it actually is, and this can be disastrous for security.
- JanSt 5y agoThere are misunderstandings arising - reading this thread or the articles makes it clear for me…
- EGreg 5y agoI know the official line is that CORS “protects” the relying party (the website that initiates requests) but in practice I have found it to be quite the opposite. From having to deal with CORS over the years, to me is just a tool to protect one thing… the intellectual property of whatever site we are loading resources from. For example, images arrive “tainted” and you can’t get their pixels on a canvas no matter how hard you try. You can’t generate a “screenshot” you can print, and so forth. If this was just about protecting the relying party website, that website would have a way to get around this “protection” to get something done. Sure, people can try to get at the intellectual property directly, but they’d have to have an authenticated account first. If they do it on the site where it’s hosted, they are subject to its rules. If they are coming from some random site, eg loading it in bulk, the resulting info they get can’t be analyzed by the Javascript. Yes CORS is just a relaxation of SOP, which makes it impossible to get sensitive data that would have otherwise been revealed to the relying party. Again — SOP is protecting the user’s data loaded from the ORIGIN. Its main job is’t “protecting the receiving site”, that’s a pretty disingenuous characterization.
- marcosdumay 5y agoHum... I've never seen this use-case, but CORS and SOP are implemented on the browser under total control of the end user. If you create a scraping tool, you are perfectly capable of replacing it with any policy you want. (Besides, I'm not sure where it falls inside the new Firefox extension rules, but this is the kind of thing to implement on an extension, or in the worst case, on a plugin.)
- JanSt 5y agoCORS does not protect the website at all…
- TheCoelacanth 5y ago> I know the official line is that CORS “protects” the relying party (the website that initiates requests) You're getting that wrong. It doesn't protect the website that initiates the requests. It protects the user from the website initiating the requests. SOP is to stop website A from doing shady things to the user using their session from website B. It does protect you in the sense that protecting your users is also protecting you, but it requires voluntary cooperation from the user, so it doesn't do anything to protect you from malicious users. In the "hotlinking" example you're giving, CORS is only protection from the absolute laziest of attackers, since you can get around that with about 5 minutes of setting up nginx to proxy from your domain to the resources you want to re-use. You can also get the same protection without CORS by blocking requests based on the Referer header
- systemvoltage 5y ago> CORS protect against the scenario where a malicious site tricks an unmodified browser to make a cross-site request to a legitimate site. If the user has an authentication cookie for the legitimate site, the cookies will be sent along with the request. So the malicious site can perform transactions in the legitimate site on behalf of the user, despite not having direct access to the authentication cookie. Can you please give an example of this?
- earthboundkid 5y agoYou are logged into example.com and see a page from evil.com in an ad iframe on a third site. Evil.com tells the browser to post example.com/transfer-money?dest=badguy.
- zdragnar 5y agoIt is a solution for AJAX requests to the same problem that CSRF tokens solve for html forms. Imagine a user is logged into facebook, and visits legitimate website X, which has been hacked to inject malicious script Y. Malicious script Y makes a bunch of API calls to Facebook; since the user has been logged in, the Facebook cookies are sent along with the request by the browser. Malicious site Y could delete your posts, make you join pro-Nazi pages, or exfiltrate your network. With CORS in place, the requests would be denied, because API requests can be set up to reject any requests that are not from a specific list of domains. This is a bad example, because Facebook doesnt rely just on cookies, and in fact does have an SDK for making API requests from third party sites. The principle remains, however, if that were not the case, then CORS would be one possible remedy to the problem.