Securing your API: a modern alternative to CSRF tokens

Post by Eridrus » Wed, Jun 14, 2017, 12:54 AM UTC

616c wrote: post #26

Eridrus wrote: post #25

Earlier quoted context omitted.

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

Post by stouset » Wed, Jun 14, 2017, 1:05 AM UTC

jordanlev wrote: post #11

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…

I believe the point of the article is that tokens don't get sent for HEAD or OPTIONS requests, and it's very possible that your API/server are still performing some sort of action on such requests. Or even if not performing a specific action, it still needs to be dealt with and hence is a DDOS vector.

Post by ejcx » Wed, Jun 14, 2017, 1:47 AM UTC

ubernostrum wrote: post #27

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

Post by ubernostrum » Wed, Jun 14, 2017, 3:40 AM UTC

ejcx wrote: post #35

ubernostrum wrote: post #27

Earlier quoted context omitted.

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

You're wrong. If this is generated every time the page loads you get a new token each time. OR you have to transmit a god awful amount of data on the same page. When I work for a company that accepts GBs of data over the same TLS connection on a single page, I'll worry about breach and only generating a CSRF token every time a page loads.

Post by skeggse » Wed, Jun 14, 2017, 4:05 AM UTC

hamandcheese wrote: post #36

> Firefox will not send the Origin header with any same-origin requests (bug) Am I the only one very surprised to hear this? In 2017? Is there any reason browsers shouldn't just send origin headers along with all requests? Why the exceptions?