• caglararli@hotmail.com
  • 05386281520

What is the risk of lenient CORS header for a webapplication that stores tokens in sessionStorage and not in cookies?

Çağlar Arlı      -    4 Views

What is the risk of lenient CORS header for a webapplication that stores tokens in sessionStorage and not in cookies?

Let's assume we have a web-application that stores its auth token in the browser's sessionStorage/localStorage and does not use cookies. If I'm not completely mistaken, such a web application is not vulnerable against CSRF attacks, right?

In such a scenario: What is the risk of having lenient CORS headers like Access-Control-Allow-Origin: * or reflecting back the requests origin or referer header back as the value of Access-Control-Allow-Origin?

The only scenario I can think of is: A complete replication of the web application. Let's assume the back-end runs on my-back-end.org and the front-end on my-front-end.org.

If we config my-back-end.org to reflect back the requests origin or referer header as Access-Control-Allow-Origin, then an attacker could copy the legit front-end to, let's say, evil-front-end.org, lure the legit users onto it and then do whatever they want in the front-end (like add key-loggers or whatever). Classical phishing.

That would not be possible if the my-back-end.org server were to sent Access-Control-Allow-Origin: my-front-end.org.

However, even if the CORS headers were strict, the attacker could achieve the very same effect by having a proxy in between: Again setting up their front-end on evil-front-end.org, but having it connect to evil-proxy-end.org which in turn would connect to my-back-end.org and remove the Access-Control-Allow-Origin: my-front-end.org header before returning any response to the client. A little bit more job for the attackers, but same effect.

One theoretical obstacle: If the legit users of my-front-end.org are behind some strict firewall or the like and they have my-back-end.org on an allow-list, then connections to evil-proxy-end.org would be blocked. But that's a very niche case I'd say.

On the other hand: Setting very lenient CORS headers has some tangible advantages. Especially if parts of your API are in fact public or are planned to be public eventually.