Securing your API: a modern alternative to CSRF tokens • Hacker News Board

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

#21

Post by wearhere » Tue, Jun 13, 2017, 10:56 PM UTC

Eridrus wrote: post #7

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.

Interesting. But in both these cases (yours and @arkadiyt's) these vulnerabilities only affect GET requests right? In which case—though we would love to lock down GET requests, to prevent DOS attacks, and because GET routes _might_ in some cases modify state—the impact is pretty limited.

I (one of the co-authors of the post) would also characterize our approach as "skating to where the puck will be". I'm sure that browsers will patch these bugs, the Edge one was fixed quickly. Our product only nominally supports the latest - 1 versions of Chrome and Safari. This is of course a luxury not available to all developers.

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

#22

Post by tcheard » Tue, Jun 13, 2017, 10:59 PM UTC

boucher wrote: post #17

bhhaskin wrote: post #16

Earlier quoted context omitted.

You are totally correct. CORS also falls apart if the client isn't a browser.

But, CSRF is inherently a browser vulnerability.

Yes, but then you get people that fail to understand that CSRF only applies to a browser, and CORS only affects a user agent that implements a Same Origin Policy. And they fail to protect their resources otherwise.

They add CORS support to their server resources and get the false assumption that their resources can only ever be retrieved from a web page under their origin or an origin they have trusted (via CORS). They believe that this also protects them from malicious users making requests from outside of a browser (eg. via curl).

CORS is not security, it is loosening of security (namely SOP).

The number of times that I have had someone ask "why can someone access the endpoint via curl? I thought this was protected by CORS" makes me sad.

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

#23

Post by wearhere » Tue, Jun 13, 2017, 11:01 PM UTC

alexchamberlain wrote: post #15

I don't really like the word secure next to CORS; you're relying on the browser to be secure... which it is not.

You can trust the browser itself (not application code, but the native code) to issue the appropriate headers. If you could find a way of compromising that, it would be a vulnerability wayyy beyond the scope of our protection.

(Caveat: browsers may not implement the specs completely/bug-free yet, as we cover in our post. But we fully expect they will, and in the meantime our module supports fallbacks. This approach is "skating to where the puck will be".)

Non-browser clients can spoof these headers, but the risk then is DOS, not clients leveraging the user's credentials—which is the primary focus of CSRF protection. It's nice that our method can prevent browser-based DOS attacks, but that's by no means complete DOS protection.

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

#24

Post by skeggse » Tue, Jun 13, 2017, 11:09 PM UTC

homakov wrote: post #18

If I were to drop CSRF tokens (which work reliably) I would go directly to Origin verification. No Referer. Something in the middle is worst of both worlds.

I'm curious about your comment. We (attempted) to address cases where we needed to infer the Origin from the Referer due to incomplete browser support. What about using both makes this necessarily worse, when the use of the Referer is really only a temporary bandage for said incomplete support?

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

#25

Post by Eridrus » Tue, Jun 13, 2017, 11:47 PM UTC

wearhere wrote: post #21

Eridrus wrote: post #7

Earlier quoted context omitted.

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.

Interesting. But in both these cases (yours and @arkadiyt's) these vulnerabilities only affect GET requests right? In which case—though we would love to lock down GET requests, to prevent DOS attacks, and because GET routes _might_ in some cases modify state—the impact is pretty limited. I (one of the co-authors of the post) would also characterize our approach as "skating to where the puck will be". I'm sure that br…

Almost no one ever gets hacked through web app bugs at all, let alone CSRF, so in the end this doesn't really matter.

I still wouldn't recommend this as a solution though, since it's been broken repeatedly.

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

#26

Post by 616c » Wed, Jun 14, 2017, 12:01 AM UTC

Eridrus wrote: post #25

wearhere wrote: post #21

Earlier quoted context omitted.

Interesting. But in both these cases (yours and @arkadiyt's) these vulnerabilities only affect GET requests right? In which case—though we would love to lock down GET requests, to prevent DOS attacks, and because GET routes _might_ in some cases modify state—the impact is pretty limited. I (one of the co-authors of the post) would also characterize our approach as "skating to where the puck will be". I'm sure that br…

Almost no one ever gets hacked through web app bugs at all, let alone CSRF, so in the end this doesn't really matter. I still wouldn't recommend this as a solution though, since it's been broken repeatedly.

Man oh man I used to think the same but I took infosec training.

That taught me little. I held onto the belief hacking a target by website is only for really dumb victims.

Then I started reading Bug Bounty reports on HackerOne and BugCrowd and was terrified at people doing account takeovers with CSRF attacks on oft overlooked functionality in no name sites like Twitter or FB.

That humbled me real quick.

As an aside, FB has to put a stupid interactive prompt to not open the browser JS console unless you type a key code. In an era where people will misguidedly copy paste into that, it is real brazen to believe token stealing and other CSRF vectors are not footholds and do not really happen.

I presume I just misunderstood you, but I wanted to go on the record for those on HN secretly believing this position and call them nuts.

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

#27

Post by ubernostrum » Wed, Jun 14, 2017, 12:26 AM UTC

ejcx wrote: post #9

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 tok…

Not to be That Guy, but: your sample will reuse the same token over and over until it expires, which is how you get the BREACH attack.

In Django 1.10, we switched the CSRF token generation to use a consistent base value, but to combine it in a reversible way with a randomly-generated per-request nonce. CSRF verification then consists of recovering the base value and checking it; this lets you have a longer-lived "token" without sending the same value in every request/response cycle.

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

#28

Post by ubernostrum » Wed, Jun 14, 2017, 12:30 AM UTC

wearhere wrote: post #23

alexchamberlain wrote: post #15

I don't really like the word secure next to CORS; you're relying on the browser to be secure... which it is not.

You can trust the browser itself (not application code, but the native code) to issue the appropriate headers. If you could find a way of compromising that, it would be a vulnerability wayyy beyond the scope of our protection. (Caveat: browsers may not implement the specs completely/bug-free yet, as we cover in our post. But we fully expect they will, and in the meantime our module supports fallbacks. This approach i…

If you could find a way of compromising that

CVE-2011-0696 (the Django version of a bug that did affect several major things) is what happens when you find a way of getting the browser to make a cross-domain request with custom headers.

(the underlying issue there was a combination of a bug in Flash, and the semantics of the HTTP 307 status code)

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

#29

Post by X-Istence » Wed, Jun 14, 2017, 12:36 AM UTC

tcheard wrote: post #22

boucher wrote: post #17

Earlier quoted context omitted.

But, CSRF is inherently a browser vulnerability.

Yes, but then you get people that fail to understand that CSRF only applies to a browser, and CORS only affects a user agent that implements a Same Origin Policy. And they fail to protect their resources otherwise. They add CORS support to their server resources and get the false assumption that their resources can only ever be retrieved from a web page under their origin or an origin they have trusted (via CORS). Th…

CSRF doesn't save you here... I can send up a CSRF token using curl just as easily...

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

#30

Post by jaza » Wed, Jun 14, 2017, 12:47 AM UTC

ejcx wrote: post #9

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 tok…

Agreed. The solution being proposed with CORS is fragile and complex. Maybe it will be viable in another 5 years' time, with better browser support. But I can't imagine that after reading the article, any dev in his/her right mind will be rushing off to ditch CSRF tokens on production sites.

CSRF tokens are taken care of by every web framework out there, anyway. They really should involve zero work to implement. For example, Flask-WTF handles them virtually transparently.