I understand CSRF and why cross-domain AJAX requests with cookies or other credentials can't be permitted without an Access-Control-Allow-Credentials header explicitly permitting them - otherwise I'd be able to do things like lure people to a site that hijacks their Facebook cookies to post something on Facebook in their name.

What I don't understand is why even uncredentialed cross-domain AJAX requests are not permitted without an Access-Control-Allow-Origin header. With no credentials involved, CSRF seems impossible and so the only arguments that I know about for the Same Origin Policy seem not to apply. What vulnerability would sites or users be exposed to if this restriction were not in place?

  • I wrote this question in ignorance of how CSRF works, and as such, it's plainly and simply a bad question. Rook's answer, now accepted, helped me with this because it explains CSRF, which was the more important gap in my understanding than the question I actually asked. However, the question asked in the title has not been answered. I can't fix the question without rendering Rook's (great) answer irrelevant, so I'm going to ask a new question instead covering the ground that I intended this question to cover. Please don't close it as a dupe of this one.
    – Mark Amery
    Oct 10 '13 at 16:37
  • My new, less confused question: security.stackexchange.com/questions/43639/…
    – Mark Amery
    Oct 10 '13 at 17:11

You have stumbled on a bit of a of an irregularity caused by an attempt to make secure standards. In short, CSRF exploits can't use a CORS XHR because of the preflight requst, attackers are forced to use other techniques. In an XHR, you can read the response. However in a CSRF attack, the attacker doesn't care about reading the response. A GET based CSRF exploit can just be a simple <img> tag. A POST based CSRF exploit is as follows:

<form id="csrf_exploit" action="https://victim_site/passsword_change" method="POST">
  <input name="new_password" value="hacked">
  <input name="repeat_password" value="hacked">
  <input type=submit>

In the above exploit, the entire browser is redirected when the POST request is sent. Often an exploit like this is placed within an iframe to hide this redirection from the victim. The browser renders the response, and the attacker gains the benefits from the side-effect produced by the request. In this case the side-effect is changing the users password.

  • Right, but the exploit example you've provided again relies upon credentials being sent with the request (or relies upon the user typing their username and password for victimsite.com into a form on evilsite.com, which endangers them just as much even with the Same Origin Policy in place). I'm asking for an example of a vulnerability that would exist if only uncredentialed requests could be sent without the server spitting out a CORS header; your example just demonstrates the necessity of the Access-Control-Allow-Credentials part of CORS, which I already understand.
    – Mark Amery
    Aug 21 '13 at 16:31
  • You're right that I was needlessly restrictive in discussing only AJAX in my question - I'm not too familiar with how the Same Origin Policy applies to other kinds of requests, like img or script tags, and should probably experiment a bit - but I think the core of my question (why Access-Control-Allow-Origin needs to exist instead of just having Access-Control-Allow-Credentials and permitting uncredentialed cross-domain requests being the default) applies to your examples as much as to AJAX requests.
    – Mark Amery
    Aug 21 '13 at 16:34
  • @Mark Amery CSRF does not require user interaction and does not violate any part of any variant of the SOP. Perhaps you should try PoC exploit provided. XHR can never be used in a CSRF request because of the preflight request. In terms of the <img> tag, there are probably a dozen images on this page loaded from another domain.
    – rook
    Aug 21 '13 at 16:37
  • @Mark Amery here are some real world XSRF exploits i have written: exploit-db.com/author/?a=628 . The PHPMyAdmin one is pretty leet if you ask me.
    – rook
    Aug 21 '13 at 16:47
  • Wow, you're quite right. Turns out I didn't understand CSRF or the same origin policy. I always assumed that form POSTs were covered by the same origin policy - I never knew that it was perfectly possible for evilsite.com to send a request complete with the user's cookies to victimsite.com via form submission. Perhaps something else that I ought to be asking (and will ask in a new question, after some thought) is why that is possible, since it seems to remove much of the value of the same origin policy.
    – Mark Amery
    Aug 21 '13 at 16:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.