Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I understand the purpose of the Access-Control-Allow-Credentials header, but can't see what problem the Access-Control-Allow-Origin header solves.

More precisely, it's easy to see how, if cross-domain AJAX requests with credentials were permitted by default, or if some server were spitting out Access-Control-Allow-Credentials headers on every request, CSRF attacks would be made possible that could not otherwise be performed. The attack method in this scenario would be simple:

  1. Lure an unsuspecting user to my malicious page.
  2. Javascript on my malicious page sends an AJAX request - with cookies - to some page of a target site.
  3. Javascript on my malicious page parses the response to the AJAX request, and extracts the CSRF token from it.
  4. Javascript on my malicious page uses any means - either AJAX or a traditional vessel for a CSRF request, like a form POST - to perform actions using the combination of the user's cookies and their stolen CSRF token.

However, what I can't see is what purpose is served by not allowing uncredentialed cross-domain AJAX requests without an Access-Control-Allow-Origin header. Suppose I were to create a browser that behaved as though every HTTP response it ever received contained

Access-Control-Allow-Origin: *

but still required an appropriate Access-Control-Allow-Credentials header before sending cookies with cross-domain AJAX requests.

Since CSRF tokens have to be tied to individual users (i.e. to individual session cookies), the response to an uncredentialed AJAX request would not expose any CSRF tokens. So what method of attack - if any - would the hypothetical browser described above be exposing its users to?

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

If I understand you correctly, you are saying why is the browser blocking access to a resource that can be freely obtained over the internet if cookies are not involved? Well consider this scenario:

www.evil.com - contains malicious script code looking to exploit CSRF vulnerabilites.

www.privatesite.com - this is your external site, but instead of locking it down using credentials, you have set it up to be cookieless and to only allow access from your home router's static IP.

mynas (192.168.1.1) - this is your home server, only accessible on your home wifi network. Since you are the only one that you allow to connect to your home wifi network, this server isn't protected by credentials and allows anonymous, cookieless access.

Both www.privatesite.com and mynas generate tokens in hidden form fields for protection against CSRF - but since you have disabled authentication these tokens are not tied to any user session.

Now if you accidentally visit www.evil.com this domain could be making requests to www.privatesite.com/turn_off_ip_lockdown passing the token obtained by the cross-domain request, or even to mynas/format_drive using the same method.

Unlikely I know, but I guess the standard is written to be as robust as possible and it doesn't make sense to remove Access-Control-Allow-Origin since it does add benefit in scenarios like this.

share|improve this answer
2  
So, if I might summarize: a browser client could act as an intermediary to help a malicious server reach some destination resource R, normally accessible to only you. Normally, we consider the case where R is protected by a cookie-based auth token system, but you present a situation in which R is protected by network topology instead. The OP's imagined browser (which always assumes A-C-A-O:*) would violate network-topology-based protection. –  apsillers Oct 18 '13 at 15:41
    
@apsillers Yes, that sums up my answer nicely. –  SilverlightFox Oct 18 '13 at 15:50
    
Awesome, I hadn't considered this at all. Accepting this over Philipp's answer because - while his does technically point out a purpose of the Access-Control-Allow-Origin header - this one actually demonstrates a security issue that the existence of the header addresses, which addresses the spirit of my question better. –  Mark Amery Oct 18 '13 at 16:10
add comment

What initially bothered me with CORS policies was their indiscriminate application regardless of resource/type, I feel that sentiment resonates with your question quite well. W3 spec actually advises that:

A resource that is publicly accessible, with no access control checks, can always safely return an Access-Control-Allow-Origin header whose value is "*"

So while the scenario in @SilverlightFox's answer is possible, IMHO it was unlikely to be considered when writing the spec. Instead, W3 appears to be driven by an "everything that isn't explicitly allowed should be restricted" mentality in this instance, which backfires when correct headers aren't set or support is lacking by individual browsers:

  • Rich client-side applications using third-party RESTful APIs where authentication, if any, is sent with every request so that there is no "session" to hijack (that's stateless for you!). Still, .json responses are subject to CORS so now you have to convince the third party to either implement jsonp, or a suitable Access-Control-Allow-Origin header, or give up and set up a tunnel to their endpoint (guess which one I'll be using).

  • Webfonts are subject to CORS, although afaik only Firefox implemented this draft spec. This means that if you're using a CDN for fonts (or a subdomain for all static content), it best be *-enabled!

  • Bonus herp derp points for CDNs which don't reply with an * header but echo the request Origin header value instead: if it gets cached on a proxy with an ...-Allow-Origin: domainA, your users from other domains will not be able to access it without cachebusting (which is kind of a setback in terms of CDN performance benefits).

  • There are also a few fringe scenarios like using external images/videos with canvas.

These inconveniences when accessing *-suitable resources could be simply considered acceptable since at least CORS is in play by default when it matters most.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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