Comment by steffenweber | Hacker News Reader

Comment by steffenweber | Hacker News Reader

Parent Full thread

If all browsers sent the "Origin" HTTP header [1] with POST requests (such that web applications could rely on it) then CSRF [2] tokens mentioned in the article would become obsolete. You'd just have to check whether the "Origin" header sent by the browser is identical to your scheme + domain name (e.g. "https://www.example.com") and be done. Chrome and Safari have implemented the "Origin" header long ago but unfortunately Firefox [3] and Edge [4] have not yet done so.

The "Origin" header is similar to the "Referer" header but never contains the path or query. Furthermore, CSRF protection requires it only for "POST" requests (i.e. "GET" requests are unaffected). So there is little incentive for an option disable it for privacy concerns.

[1] https://tools.ietf.org/html/rfc6454

[2] https://en.wikipedia.org/wiki/Cross-site_request_forgery

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=446344

[4] https://developer.microsoft.com/en-us/microsoft-edge/platfor... (filed by me)

"It's probably worth reading through https://github.com/w3c/resource-timing/issues/64 and the proposal I linked above. In short, it's not clear that implementing the Origin header the way Chrome supports it actually helps with CSRF and it makes it harder (impossible really) to distinguish CORS requests."

Seems Firefox will implement it anyway because it's still better than nothing.

The conclusion of this discussion seems to be that "SameSite" cookies should be used to help preventing CSRF.

https://www.igvita.com/2016/08/26/stop-cross-site-timing-att...

The Origin header is not as good to prevent CSRF since it's a known value. A CSRF token is a one-time value generated in the server, it's impossible to guess or get a valid one from the outside.

It boils down to how much you trust browsers to implement this without fucking up. In the past trusting browsers to get it right was a questionable idea, with Flash being a particularly reliable weak point which caused Rails to change how they do CSRF protection. I'm not sure Adobe ever fully fixed the issue in all browsers.

Nonces have the benefit of only relying on browsers preventing cross-domain reads.

When Flash is deprecated, and if a site wants to use CSP, then this might start looking like a better trade off.

ATM though, nonces can be automatically added to all same domain forms on your site with JavaScript and you can check it trivially on all POST requests, getting most of the non-CSP related benefits without waiting on browsers.

And even if browsers were to implement it, there is still a long tail of browsers out there that will take forever to update.

CSRF protection is not about attacks from evil clients (you can easily spoof any header with the HTTP client library of your choice, of course). CSRF protection is about preventing innocent / well-behaving clients from being tricked into POSTing some data on behalf of their (logged-in) user.

Yes. Forwarding a unique CSRF token from the backend gives you some assurance that it's a legitimate request, initiated from a pageview within a timeframe. A header (origin) which always has the same value (the hostname) is inherently less secure, though I overstated how much in the previous comment.

You can use it to identify unsophisticated attacks, sure.

However, if someone has the ability to make malicious HTTP requests on my behalf using my browser can you really be sure that they don't have the ability to make malicious HTTP requests with altered headers through a malicious extension or a browser specific exploit or some other vector?

You still have to do all the other attack mitigation strategies in addition to checking the Origin header, and I'm not sure the extra complexity buys you anything in the long-term.

Not sure I follow your reasoning: CSRF requires a browser, as that's where you'll find a logged-in user that you want to force into doing something without their knowledge. The network layer is already protected by HTTPS. Some browser plugin might modify the header, at which point the whole exercise is pointless anyway as you can't trust the client in that case. Happy to learn where I'm wrong.

Can you expand on the threat model here? After noodling a bit I can't think of an attack that CSRF prevents that an origin header wouldn't, but obviously that doesn't mean there isn't one. Be real curious to hear of one!

Reply on news.ycombinator.com