3

I am curious of what all the security implications are if I set the following two HTTP response CORS headers;

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: false

The only security issues I see are DoS attacks and CSRF attacks.
CSRF attacks can already be achieved with IMG and FORM elements. DoS attacks related to CORS can be overcome by blocking requests upon the referrer header.

So I'm not sure why it said that only a given set of domains should be given "CORS access".


What are the security implications of adding all domains "CORS access"?

brillout
  • 139
  • 1
  • 4
  • 4
    http://security.stackexchange.com/questions/45030/access-control-allow-origin-wihout-ajax http://security.stackexchange.com/questions/43639/why-is-the-access-control-allow-origin-header-necessary http://security.stackexchange.com/questions/43936/does-returning-access-control-allow-origin-weaken-the-security-of-json-get and http://stackoverflow.com/questions/8117621/is-it-safe-to-use-access-control-allow-origin-setting-on-the-server-and-use – Adi Nov 27 '13 at 11:21
  • 1
    The second link provides some information but still tackles the question from quite a different angle. As for the other links they don't provide any information whatsoever related to my question – brillout Nov 27 '13 at 17:52

1 Answers1

2

Access-Control-Allow-Origin has a different meaning than simply preventing CSRF: It prevents that the requesting script can get the result of the request.

The same applies to Access-Control-Allow-Credentials. This header allows that the script get the response of a request with credentials. Note that you can't use the wildcard * for Access-Control-Allow-Origin when sending Access-Control-Allow-Credentials: true. but you could just use the value of the Origin request header.

The implication is: What could a script with the contents of your site do?

  • If the user is logged in, a script can get all the sites that the user can see, parse it and send the (maybe confidential) data back to it's origin.
  • If you include some kind of anti-CSRF-token in forms/links, they could get the value of the token and do a request with that valid token.
  • It can act on the page on behalf of the user.

For XSS it depends what you mean with XSS. If you mean with XSS that an other script acts on bealf of a user, then you already allowed that.

So while adding to a remote site only reveals a few informations to the origin site (like the time to load it), the information leak (esp. for users that are logged in) can be much higher.

As a side note: Use the Origin header if present to block requests.

Johannes Kuhn
  • 294
  • 3
  • 10
  • As already mentioned in the question, no cookies are sent – brillout Nov 27 '13 at 17:37
  • In this case `Access-Control-Allow-Credentials: true` does not make a difference. – Johannes Kuhn Nov 27 '13 at 19:20
  • I meant; no cookies are sent because they aren't allowed as per ``Access-Control-Allow-Credentials: false`` – brillout Nov 27 '13 at 19:38
  • Wrong. If the script requests that cookies are send, they are send, but if the `Access-Control-Allow-Credentials` response header is false or missing, the script would not get the response. – Johannes Kuhn Nov 27 '13 at 21:56
  • I really doubt it to be the case. This would otherwise pose a considerable security issue with CORS. I didn't read the spec so I'm not entirely sure but my guess is that the purpose of the preflight is to avoid the following catch 22: the browser needs to send the request to know if and how the CORS response headers are set, but if the browser sends the request to realize that no CORS headers are set, then it just did a request that it is not suppose to do – brillout Nov 27 '13 at 22:42
  • The preflight request is only send for request that you could not send otherwise, e.g. you can always add a form with hidden elements and submit it via JS. – Johannes Kuhn Nov 27 '13 at 22:49