On the same topic of CSRF prevention, we also recently wrote about the dangers of using Content Types for security -- https://medium.com/@longtermsec/chrome-just-hardened-the-nav...
Securing your API: a modern alternative to CSRF tokens
51–58 of 58 posts
Re: Securing your API: a modern alternative to CSRF tokens
#52Earlier 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.
You're wrong. If you MITM the connection you can block that response and the token will be user over and over again allowing these attacks
Re: Securing your API: a modern alternative to CSRF tokens
#53Isn't JWT a modern alternative to CSRF tokens?
It's not. If you think it is you probably store JWT unsafely instead of in an httpOnly secure cookie.
Re: Securing your API: a modern alternative to CSRF tokens
#54Why 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…
In addition to everything you've mentioned, the double submit cookie approach for csrf defense saves you from storing any state if you don't want to use a backend session.
So does using the client to hold information.
Re: Securing your API: a modern alternative to CSRF tokens
#55Earlier quoted context omitted.
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?
Worst because it is neither proven as tokens which are used for decades already nor as convenient as simply whitelisted Origin and you even offer an extra dependency. Are those scenarios without Origin important? Like ff for form request - you can use xhr there and drop referer support entirely.
You're right, support for cross-origin form POSTs isn't important for us. What is important, however, is same-origin requests, and Firefox doesn't send the Origin header with those. For us, the Referer serves its most important role by indicating where those requests originate from.
EDIT: when Firefox _does_ start sending the Origin header, we may drop the Referer - we'll see.
Re: Securing your API: a modern alternative to CSRF tokens
#56Earlier 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.
Having worked in IR in various capacities in the past, I'd like to point out that many intrusions are not shared publicly. There are definitely targeted intrusions that begin with XSS or CSRF, you just don't hear about them. As for the majority of hacks being something else I full on agree. I think phishing for credentials and malware installs, and leaked credentials in recent years, makes up the majority of intrusio…
So, I acknowledge there are breaches which started with XSS (Atlassian, etc), but even when you look at breaches that started with "client-side web bugs", how many of those are CSRF rather than XSS? Probably only a fraction, since they're shittier bugs.
And then, from the pool of "client-side web bugs", how many involve browser bugs?
This is just such a tail risk that it's hard to make myself care.
Re: Securing your API: a modern alternative to CSRF tokens
#57Earlier quoted context omitted.
Worst because it is neither proven as tokens which are used for decades already nor as convenient as simply whitelisted Origin and you even offer an extra dependency. Are those scenarios without Origin important? Like ff for form request - you can use xhr there and drop referer support entirely.
You're right, support for cross-origin form POSTs isn't important for us. What is important, however, is same-origin requests, and Firefox doesn't send the Origin header with those. For us, the Referer serves its most important role by indicating where those requests originate from. EDIT : when Firefox _does_ start sending the Origin header, we may drop the Referer - we'll see.
Just checked, indeed no origin on same site. It sucks, this makes origin barely reliable.