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/
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.
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.
Also, bug bounties are not representative of real attacks.
I've written my own share of complicated exploits, but from an actual defense perspective... that's not how people are getting hacked IRL. It's all word macros and sqlmap.
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
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.
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/