[V3ritas1337]

Calling CSRF dead is the wrong way to interpret it.

There would be few security issues surrounding web apps if devs were security conscious, unfortunately only few are.

There are many mitigations for security vulnerabilities surrounding web apps, CSRF is very much alive, and it is a common finding of mine.

[noncoml]

I think he means CSRF prevention hacks are dead, because, despite being the norm, adding a CSRF token in each POST request is indeed an ugly hack.

[edoceo]

Not ugly, it's just passing a state-key around - a common practice in loads of other communication channels.

[AmericanChopper]

That doesn’t really fit in with modern web interfaces though. REST and GraphQL are both stateless architectures. Tracking and mutating a state on every request doesn’t fit very well with with that.

[MaxBarraclough]

Depending on exactly what we're doing, we can work around this with crypto, right?

A token can securely prove that it was issued by the server/service, and under what conditions, without the server/service statefully tracking the token after issuing it.

I know I'm not the first to think of this, but I'm not sure how widely used this sort of technique is in practice.

[AmericanChopper]

That’s exactly how authentication JWTs work. They work differently from CSRF tokens though, because the CSRF token is generated for each request, not each ‘session’ (so you need much more complex server-side state management). But that said CSRF isn’t particularly relevant if you’re using a JWT in the Authorization header. CSRF attacks the fact that browsers will use cookies to automatically authenticate requests. If you’re not using cookies for authentication, and adding a JWT to the headers instead, then that automatic authentication doesn’t occur. Correct me if I’m wrong, but I’m not aware of any CSRF attack that targets Authorization headers, I believe any attack that does is just an XSS.

[exelib]

Well, where you store your JWT on the client? LocalStorage? Then you have probably much broader surface for an attacker.

In case of XSS you lost anyway. But with HttpOnly-Cookies the attacker can't steal your token and do everything from everywhere with your token.

[edoceo]

When you send a PATCH request, and include a token of the object you're patching, so the system knows your using an up-to-date object? In that REST like example that hash/token on the object is the same function as CSRF-token. I see this model on APIs daily.

[AmericanChopper]

That sounds more like an integrity check than a CSRF control. Unless you have poor CORs settings, wouldn’t SOP prevent CSRF on PATCH endpoints anyway?

[edoceo]

It's that too. My point (still) being that passing state keys is old, common and still in use.

[olalonde]

This is what cookies are for. No one will be using CSRF tokens once cookies are fixed (e.g. SameSite is widely supported). "Just passing a state-key around" is not mutually exclusive with "being an ugly hack".

[all_blue_chucks]

Having to add state to fundamentally stateless operations is not a good thing.

[NohatCoder]

Being logged in is not a stateless thing. Cookies are state.

[all_blue_chucks]

It actually is stateless. The cookie is just one part of the stateless request.