0

Since application is not responding with allow credentials header, an attacker can't craft cross domain request with cookies, but I was wondering if allow origin * alone (Without credentials being true) can be exploited?

I know allow origin can't be * if allow credentials header is true, what am asking is that is this alone a flaw, is this exploitable in any way?

Jack
  • 1
  • This fully depends on your unknown application. Can anything be done there without cookies? – Steffen Ullrich Mar 10 '21 at 18:28
  • No, without cookie there's no way to identify a user. Does this mean ACAO header being * is useless in this case? – Jack Mar 11 '21 at 06:21
  • Does everything in your application even require a user? Again, this question cannot be answered with the current amount of information. – Steffen Ullrich Mar 11 '21 at 07:28
  • Yes, most part of the application is only available to authenticated users which requires cookies. – Jack Mar 11 '21 at 07:55
  • Unauthenticated user on this application have access to only static pages. – Jack Mar 11 '21 at 07:56
  • 3
    Does this answer your question? [Concrete example of how can Access-Control-Allow-Origin:\* cause security risks?](https://security.stackexchange.com/questions/227779/concrete-example-of-how-can-access-control-allow-origin-cause-security-risks) – jub0bs Sep 09 '21 at 15:38

2 Answers2

1

Is there an issue if application responds with access control allow origin * but there is no allow credentials header?

This question is literally exactly the same as:

Is there an issue if application responds with access control allow origin *?

And that question is already answered at Concrete example of how can Access-Control-Allow-Origin:* cause security risks?

Beyond that, CORS does not inherently prevent CSRF attacks; you still need a way to block those. That's true even if you don't return any ACAO: header at all, though.

CBHacking
  • 40,303
  • 3
  • 74
  • 98
-1

No, if the server's API follows REST principles (which it should).

If in a fetch with GET you set credentials: "include" then the request will be performed and credentials will be included. But:

  1. response's content won't be made available to the browser when either Access-Control-Allow-Origin: * or Access-Control-Allow-Credentials: false (or if either of them is missing). So the client won't be able to read the response even if the server responded with something user-specific.
  2. since this is a GET request then the server shouldn't do anything state-changing (this is the "follow REST" part)

Using POST, PUT or DELETE in a cross-origin fetch with credentials: "include" will require a preflight request beforehand -- to ask the server if these methods are allowed to be performed with credentials. So if the server does allow credentialed state-changing requests then it must reply to the preflight with headers Access-Control-Allow-Origin: https://the-clients-origin.com and Access-Control-Allow-Credentials: true.

(There is a slight exception to the previous for POST requests with content-types either application/x-www-form-urlencoded, multipart/form-data or text/plain. These are there for cross-origin form-submit handlers (someone correct me on this).)

Read more on MDN: CORS: Simple requests or Fetch specification.

Cigarette Smoking Man
  • 101
  • 1
  • 1
    This is wrong in multiple ways! Perhaps most centrally, POST requests do *NOT* inherently require pre-flights! POST *might* require a preflight depending on conditions, but so can GET. The distinction is "simple" requests (those that could be made using an HTML form, which does allow POST) aren't preflighted; everything else is. **CORS does not inherently prevent CSRF!** – CBHacking Dec 06 '21 at 22:58
  • @CBHacking The original question isn't about whether something requires a preflight or not and also not directly about CSRF, but about whether `access-control-allow-origin: *` can be exploited. So for GET and HEAD regardless of if there is a preflight or not they shouldn't be exploitable as per REST they shouldn't cause a state change on the server, neither won't they show the response if credentials were included. The exception content types where a POST request doesn't require a preflight are mentioned at the end in parenthesis. Surely the answer could be improved, but how? – Cigarette Smoking Man Dec 07 '21 at 13:47