Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Securing your API: a modern alternative to CSRF tokens

mixmax.com

Post reply on HN
Print view View original

1–10 of 58 posts

Re: Securing your API: a modern alternative to CSRF tokens

#2

Post by codedokode »

They tried to propose a simple modern solution but after reading the article it does not look simple and works much worse than traditional approach with tokens.

And of course it would be better if browsers would not make cross-origin requests unless permitted by server.

Re: Securing your API: a modern alternative to CSRF tokens

#3

Post by lol768 »

I guess the modern part here is the use of the Origin header, but in all honestly this feels really flaky in comparison to using a CSRF token. I'd argue that SameSite cookies are a better 'modern' alternative than this (for a majority of use-cases), especially because of all the edge cases that have to be dealt with for this approach (Origin not being sent, falling back to Referers, policies for those...). It feels like a giant hack.

Also, I really don't get the relevance of the refutation of "Use only JSON APIs" - it's a fixed bug that seemingly only impacted Chrome anyway? The second point is that preflights are expensive, which might have some weight - but e.g. Twitch seem to cope okay with these preflights and I think a lot of browsers do cache them for a short period of time now anyway.

I'll be sticking to CSRF tokens plus SameSite cookies (for where the browser supports them). The only issue I can see with SameSite is that JS can still send requests (with no credentials), but I'm not convinced this is a credible DoS vector.

Re: Securing your API: a modern alternative to CSRF tokens

#4

Post by wearhere »

codedokode wrote: post #2

They tried to propose a simple modern solution but after reading the article it does not look simple and works much worse than traditional approach with tokens. And of course it would be better if browsers would not make cross-origin requests unless permitted by server.

Hi @codedokode, I'm one of the authors of the post. There's a lot of background material at the top but if you skip to the use of our new module (direct link: https://github.com/mixmaxhq/cors-gate/#usage) I think you'll find it simpler in both code and infrastructure than a typical CSRF setup. https://github.com/expressjs/csurf, for instance, requires you to lock down every API both server-side and client-side, and by default requires session middleware; whereas with cors-gate you can register it once, server-side, before any API routes.

Re: Securing your API: a modern alternative to CSRF tokens

#5

Post by arkadiyt »

I used to prefer the origin/referer approach to blocking CSRF because it can be done upstream of the application server (or in a middleware), transparent to developers who often get these things wrong.

However there's been enough referer spoofing browser bugs lately that I'd rather have the extra safety (and complexity) of CSRF tokens. Just 3 months ago Edge had (another) referer spoofing bug: https://www.brokenbrowser.com/referer-spoofing-patch-bypass/

Re: Securing your API: a modern alternative to CSRF tokens

#7

Post by Eridrus »

arkadiyt wrote: post #5

I used to prefer the origin/referer approach to blocking CSRF because it can be done upstream of the application server (or in a middleware), transparent to developers who often get these things wrong. However there's been enough referer spoofing browser bugs lately that I'd rather have the extra safety (and complexity) of CSRF tokens. Just 3 months ago Edge had (another) referer spoofing bug: https://www.brokenbrows…

And another one on slide 33: https://speakerdeck.com/filedescriptor/exploiting-the-unexpl...

There are plenty of middleware-like solutions that can add solutions automatically too. And if you fail closed, you will always notice in testing and can add tokens where they are missing.

Re: Securing your API: a modern alternative to CSRF tokens

#8

Post by minus7 »

I can't shed the feeling that CORS is just piling more crap onto crap; this seems just way too complex. On one hand, I'm somewhat glad that I don't work on web things and don't have to deal with it, and on the other hand I'm scared of the many web developers are not (sufficiently) aware of the range of possible vulnerabilities and thus not protecting them.

Re: Securing your API: a modern alternative to CSRF tokens

#9

Post by ejcx »

Why make an extremely complicated set up, with many edge cases, all to save yourself from a single token?

    - Privacy extensions often times block referrer headers.

    - POST requests are usually necessary.

    - Open redirects are common bugs, and getting your website to initiate one can be a problem.

    - Disabling CORS also relies on you killing crossdomain.xml, which you might overlook.
Instead you can just roll out CSRF tokens.

Having rolled them out myself many times. You probably want to use a library if you aren't a cryptographer or security person:

    expiration_time_of_1_day || hmac_sha256( secret_key, { expiration_time_of_1_day, user_id })
I've seen other people mention SameSite cookies, but we aren't near a time when browsers all support them. Don't get fancy preventing CSRF. It's a stupid bug.
Post reply on HN