0

While reviewing an SPA web application the backend API server was reflecting the Origin header from a credentialed request in the Access-Control-Allow-Origin header of the response with Access-Control-Allow-Credentials set to true.

I don't believe there is a CORS issue here as for most of the endpoints there were preflight requests performed except for an authentication request where the Origin was also reflected in the ACAO header. Does this mean that an attacker could cause a victim to login to this site by issuing an authentication request from their own attacking server as there was no preflight request before receiving an Authorization token? Is there any difference or security considerations if the ACAO header is reflecting the Origin header for credentialed requests as opposed to having it set to a wildcard (*)?

1
  • Do the preflights not also reflect the attacker's Origin header? If they do, then preflighting doesn't actually prevent anything, Origin-wise (it might prevent things like using certain headers, if for some reason it only allows those headers from first-party sites).
    – CBHacking
    Nov 14, 2021 at 0:51

1 Answer 1

1

the backend API server was reflecting the Origin header from a credentialed request in the Access-Control-Allow-Origin header

I assume by this you meant that it's reflecting arbitrary Origins, not just trusted ones? Assuming that the API uses cookies (or HTTP basic/digest auth, which is rare), then this is absolutely a problem.

I don't believe there is a CORS issue here as for most of the endpoints there were preflight requests performed

Do those preflights actually block the request if it comes from an untrusted origin? Usually if a server is reflecting arbitrary origins in ACAO, it does that for both preflight and non-preflight requests, and usually if it supports preflights at all, it always returns the same set of CORS permissions (aside from ACAO) in all preflight responses (or at least all that have allowed origins).

Preflights by themselves don't inherently prevent CORS issues. They're a "checkpoint" of a sort - a place where security controls can be enforced - but that depends on them being configured correctly, and "reflect the origin in ACAO, plus ACAC: true" is definitely not configured correctly.

Does this mean that an attacker could cause a victim to login to this site by issuing an authentication request from their own attacking server

Sounds like you're describing "login CSRF", which most sites are vulnerable to (it's possible to put at least some protections in place against it, but almost nobody does). How big of a deal it is depends on things like how likely the user is to notice being signed into the wrong account, and how big the risk of the user sending sensitive data to the wrong account would be, and so on. Of course, it's also possible it won't even work, because...

... before receiving an Authorization token

If by "Authorization token" you mean "Bearer token", sent in the HTTP request header "Authorization"... then all of this is irrelevant. CORS misconfiguration, like CSRF, is only really a threat when the user is authenticated via something that the browser will send automatically (cookies or HTTP basic/digest auth). Bearer auth tokens are not sent automatically, so for them there is basically no risk of either CSRF (even login CSRF, because the returned token won't be stored in the relevant site) or CORS misconfig (because without knowing the header, it can't be set by the attacker, so the attacker's requests will be unauthenticated, there's no way to steal data from the user's account or take actions on the user's behalf).

It's the important details of how your auth works, like whether you use cookies or Bearer tokens, that really matter for questions like this!

Is there any difference or security considerations if the ACAO header is reflecting the Origin header for credentialed requests as opposed to having it set to a wildcard (*)?

Leaving aside the possibility of Bearer tokens, yes there absolutely is! Combining ACAO: * and ACAC: true is a violation of the spec and the client is required to treat it as though ACAC was false / absent. Obviously that's not the case for ACAO with an actual origin, or else ACAC would never have a meaning at all. Because ACAO: * is always treated as uncredentialed, it it can't be used to steal private information from the server. This doesn't prevent CSRF, of course, but usually you don't need XHR/fetch to do CSRF at all.

2
  • Thanks for the info, that answers my question for the most part. Yes, I do mean it was reflecting arbitrary origins, not only trusted ones. Should have been more specific about the wording as I meant 'Bearer token' instead of 'Authorization token'. For a bit more context, in the preflight request the application also mirrored the Origin header from the request in the ACAO header with ACAC set to true. But it seems the fact that they are using a Bearer token is mitigating their risk as it wont be sent by the browser automatically. Nov 15, 2021 at 21:40
  • 1
    @RespectableMan1337 Correct, assuming that you don't also use cookies for auth (or things like trusting specific IPs / subnets implicitly). I've seen systems that are nominally using bearer auth, but in practice they also set the token in a cookie, and will accept the token either in the header or in a cookie. That is at risk of CSRF and CORS attacks. But as long as the server requires something that the attacker doesn't know (e.g. auth token) and that the browser doesn't send automatically (i.e. not a cookie), you're fine.
    – CBHacking
    Nov 17, 2021 at 7:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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