1

This question already has an answer here:

We have api.example.com that communicates with app.example.com, a native Android app and an iOS app. We want to allow other third parties to communicate with the API too if they want, and as such we have Access-Control-Allow-Origin: * header set.

We have some API routes that do not require prior authentication such as /reset-password and /login.

Every other API route requires an authentication token appended to it, for example /important-action?authtoken=abc123. It does not accept cookies in headers or the body of requests. app.example.com saves the auth token in a cookie to preserve the session.

What I'm struggling to understand is how evil.com can exploit this setup- Can somebody please give some examples of how an attack could work or stop me worrying and let me know CSRF isn't an applicable risk.

I've read other answers that refer to "using cookies" but they do not clarify what exactly "using" means. In our case, we're storing the authtoken in a cookie and appending it to the request URL. The API ignores any cookies sent in the request header.

marked as duplicate by Conor Mancone, Eric G, Tobi Nary, Xiong Chiamiov, Polynomial Jan 25 '18 at 13:24

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1

Cross-Site Request Forgery requires that the attacker be able to predict the request to be made. Assuming the authtoken values are difficult to predict (i.e., large random values, hash values, etc.), then it would be difficult for an attacker to forge the request.

Note that if you set Access-Control-Allow-Origin: *, you should make sure no endpoints reflect valid tokens, or an attacker could just read them from there.

  • Thanks for your answer, to clarify, the authtokens are a 32 character random hex and the only time the API will expose one is in the response from a successful POST to /login. Does this mean CSRF is something we should be safe from? – Merlin Mason Jan 16 '18 at 12:47
1

There are two possibles paths an attacker has to explore here:

  1. Can anything be done with the paths that does not require authentication?
  2. Can I somehow get my hands on the token?

Lets look at #1, and the two paths. If the /reset-password path just sends an email to the account owner, it isn't of much use.

The other, /login, is more problematic. If you also set Access-Control-Allow-Credentials: true evil.com could "force" a login (by having the token cookie set). This opens you up to login CSRF, which can be anything from not a big deal to very bad depending on your application. If you don't set that header, the cookies in the response will be discarded and you're fine.

As for #2, it depends on if that token is available anywhere else than in the cookie. The sender of cross origin requests is never allowed to read cookies, so it can't read the token from there. But maybe it is included somewhere else? Perhaps the response contains some URL with the authtoken param in it?

Not that if the cookie itself was used as authentication when sent from the client, this would be a different story. Then you could indeed have a huge problem here.

CSRF aside, putting secrets in the URL is discouraged. After all, URLs ends up in all sorts of logs, not to mention browser history. If there is no reason not to, I would just put the token in a header instead. The header would actually help protect against CSRF as well, since evil.com wouldn't be allowed to set it.

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