What a well-written, insightful article! You have outdone yourself good sir
Securing your API: a modern alternative to CSRF tokens
41–50 of 58 posts
Re: Securing your API: a modern alternative to CSRF tokens
#42> 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?
Well, it's a bug. It absolutely should send the origin header, but it doesn't ¯\_(ツ)_/¯
I see that it's unclear, but my second set of questions was related to how chrome and safari don't send it for requests caused by img tags.
Re: Securing your API: a modern alternative to CSRF tokens
#43Earlier quoted context omitted.
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.
CSRF tokens do not help you in any way against DDOS. CSRF tokens are handed out willingly on essentially any GET request.
Exactly -- I think that's one of the points of the article.
Re: Securing your API: a modern alternative to CSRF tokens
#44Isn't JWT a modern alternative to CSRF tokens?
Re: Securing your API: a modern alternative to CSRF tokens
#45Why 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…
Not to be That Guy 2.0; but doesn't all of this ad hoc hackery (CSRF tokens included, IMHO) around request authorisation and, if you'll permit me to extend the discussion a bit, also around request rate limiting, indicate that there might be something terribly broken at the heart of web requests?
In a same way that I feel the proliferation of front end frameworks indicates something is terribly broken at a cellular level about UI in HTML.
Might it not be time for a radical rethink? Can we not hope for a piercing, elegant solution?
Re: Securing your API: a modern alternative to CSRF tokens
#46Earlier quoted context omitted.
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.
From the sample code provided I was assuming the value would not update on every request (since, if you were changing the expiration timestamp on every request you'd have a bit more work to do than you've shown here -- and either way the sample you've provided isn't a great way to generate the token).
I've generated this exact token at several companies and it's worked great.
An expiration of one day is not 86400 it's unix_time()+86400, to clarify. It's not stored in the users session and is completely stateless. It's great!
It has every property a csrf token needs
- per user
- not guessable or forgeable
- expires
Since it is stateless it doesn't require db lookups which can be an additional benefit. If you complain that it lacks the ability to be revoked I challenge you to find a single instance of people revoking csrf tokens.
Re: Securing your API: a modern alternative to CSRF tokens
#47Earlier quoted context omitted.
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...
I wasn't saying a CSRF token saves you here.
All I'm saying is that security is a complicated topic. People already misunderstand things like CSRF, CORS, resource protection, etc. And they already get them wrong.
CORS is designed to loosen the security protections added by a same origin policy. It is not designed to increase security.
Piling on CSRF protections is just blurring the use case for CORS. All this is going to do is confuse people more, and more people are going to get it wrong.
Re: Securing your API: a modern alternative to CSRF tokens
#48If 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?
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.
Re: Securing your API: a modern alternative to CSRF tokens
#49Earlier 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.
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 intrusions. Many of those are opportunistic though and not necessarily targeted
Re: Securing your API: a modern alternative to CSRF tokens
#50I 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…
[deleted]