4

I have done some research but have not found an absolute answer to my specific question. I understand the basic concept of how this header will allow or disallow website A from sending request and viewing response to resources on website B.

However, suppose website B set the header Access-Control-Allow-Credentials to false, and Access-Control-Allow-Origin: *, can this cause any concrete security risk to the user who is browsing website A (suppose website A is malicious)?

5
  • If website B uses authentication that ACAC doesn't understand, such as source IP address, that's vulnerable - but this will be rare. Security advice generally implies ACAO is dangerous, but I can't think of a concrete example of a weakness, and I reckon probably no impact. Interesting question, thanks
    – paj28
    Mar 26 '20 at 2:34
  • @paj28, I've seen the example following the link in the link you've provided, and yes I think the scenario is very specific, and the decision to solely based on IP for access-control is not safe by itself.
    – SamTest
    Mar 26 '20 at 3:28
  • 1
    Just a reminder: Access-Control-Allow-Origin: * implies Access-Control-Allow-Credentials: false, and ignores any actual Access-Control-Allow-Credentials header that is returned. Actually returning ACAC is pointless - it's required to be ignored - if you return ACAO: *.
    – CBHacking
    Aug 28 at 9:13
  • Does this answer your question? Why is the Access-Control-Allow-Origin header necessary?
    – Ajedi32
    Sep 7 at 21:29
3

[S]uppose website B set the header Access-Control-Allow-Credentials to false, and Access-Control-Allow-Origin: *, can this cause any concrete security risk to the user who is browsing website A (suppose website A is malicious)?

Access-Control-Allow-Origin: * can be too permissive

In particular, consider a situation in which site B is accessible by an unauthenticated victim only from a privileged position within the target network (e.g. behind a network firewall). In such cases,

  • because no ambient authority (like cookies) is involved, the presence or value of the Access-Control-Allow-Credentials header is irrelevant; and
  • the attacker, by tunnelling through to site B via the victim's browser when she visits site A, can read site B's responses from site A.

A real-life example

A few years ago, a similar vulnerability affecting multiple JetBrains IDEs was disclosed. Those IDEs would start a server bound to localhost with an excessively permissive CORS policy, which allowed an external attacker to exfiltrate sensitive data. The server in question reflected arbitrary origins in Access-Control-Allow-Origin (as opposed to using a wildcard *) but the idea is the same.


Resources

  • The OWASP testing guide mentions this risk:

    Although [Access-Control-Allow-Origin: *] cannot be used with the Access-Control-Allow-Credentials: true at the same time, it can be dangerous where the access control is done solely by the firewall rules or the source IP addresses, other than being protected by credentials.

  • James Kettle (a.k.a. albinowax from PortSwigger), in his AppSec EU 2017 talk about CORS misconfiguration, further discusses CORS misconfigurations that do not involve credentials.

  • See also James's thoughts on the topic in written form:

    Without [Access-Control-Allow-Credentials: true], the victim user's browser will refuse to send their cookies, meaning the attacker will only gain access to unauthenticated content, which they could just as easily access by browsing directly to the target website. However, there is one common situation where an attacker can't access a website directly: when it's part of an organization's intranet, and located within private IP address space. Internal websites are often held to a lower security standard than external sites, enabling attackers to find vulnerabilities and gain further access. [...] If users within the private IP address space access the public internet then a CORS-based attack can be performed from the external site that uses the victim's browser as a proxy for accessing intranet resources.

1
  • 1
    Yes, authorization by network position (server bound only to loopback, incoming IP filter, requiring IPsec, etc.) is the only place I can think of where this matters, but it does matter there.
    – CBHacking
    Aug 28 at 9:11

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.