Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSRF protection without tokens or hidden form fields

blog.miguelgrinberg.com

Post reply on HN
Print view View original

21–30 of 116 posts

Re: CSRF protection without tokens or hidden form fields

#21

Post by [deleted] »

maxbond wrote: post #20
altmind wrote: post #9

Are there any approaches to csrf tokens that don't require storing issued tokens on server-side?

The alternative to storing tokens is to use an AEAD encryption scheme like AES-GCM to protect tokens from forgery or tampering. You will still have to worry about reuse, so you will probably want to restrict use of this token to the user it was generated for and to a lifetime (say, 24 hours). That is a very high level description, there are details (like nonce generation) that must be done correctly for the system to…

[deleted]

Re: CSRF protection without tokens or hidden form fields

#23

Post by nhumrich »

tmsbrg wrote: post #4

I'm surprised there's no mention of the SameSite cookie attribute, I'd consider that to be the modern CSRF protection and it's easy, just a cookie flag: https://scotthelme.co.uk/csrf-is-dead/ But I didn't know about the Sec-Fetch-Site header, good to know.

This is "not allowing cross site at all" so, technically it's not "request forgery" protection. Yes, this is very semantic, but, CSRF is a vulnerability introduced by enabling CS and CORS. So, technically, same-site cookies are not "protection" against CSRF.

Re: CSRF protection without tokens or hidden form fields

#24

Post by macNchz »

simonw wrote: post #10
rvnx wrote: post #8

If you want, “SameSite=Strict” may also be helpful and is supported on “all” browsers so it is reasonable to use it (but like you did, adding server validation is always a +). https://caniuse.com/mdn-http_headers_set-cookie_samesite_str... This checks Scheme, Port and Origin to decide whether the request should be allowed or not.

I find that cookie setting really confusing. It means that cookies will only be respected on requests that originated on the site that set them... but that includes when you click links from one site to another. So if you follow a link (e.g. from a Google search) to a site that uses SameSite=Strict cookies you will be treated as logged out on the first page that you see! You won't see your logged in state until you r…

SameSite=Strict is belt-and-suspenders protection in the case where you could have GET requests that have some kind of impact on state, and the extra safety is worth the UX impact (like with an online banking portal).

Discussions about this often wind up with a lot of people saying "GET requests aren't supposed to change state!!!", which is true, but just because they're not supposed to doesn't mean there aren't some floating around in large applications, or that there aren't clever ways to abuse seemingly innocuous side effects from otherwise-stateless GET requests (maybe just visiting /posts/1337/?shared_by_user=12345 exposes some tiny detail about your account to user #12345, who can then use that as part of a multi-step attack). Setting the strict flag just closes the door on all of those possibilities in one go.

Re: CSRF protection without tokens or hidden form fields

#25

Post by paulryanrogers »

tordrt wrote: post #19
tmsbrg wrote: post #4

I'm surprised there's no mention of the SameSite cookie attribute, I'd consider that to be the modern CSRF protection and it's easy, just a cookie flag: https://scotthelme.co.uk/csrf-is-dead/ But I didn't know about the Sec-Fetch-Site header, good to know.

Yep SameSite lax, and just make sure you never perform any actions using Get requests, which you shouldn’t anyway.

Unsubscribe often need to be GET, or at least start as GET

Re: CSRF protection without tokens or hidden form fields

#26

Post by amluto »

est wrote: post #18

reminds me of something similar https://news.ycombinator.com/item?id=46321651 e.g. serve .svg only when "Sec-Fetch-Dest: image" header is present. This will stop scripts

Or sending Content-Security-Policy: script-src 'none' for everything that isn’t intended to be a document. Or both.

IMO it’s too bad that suborigins never landed. It would be nice if Discord’s mintlify route could set something like Suborigin: mintlify, thus limiting the blast radius to the mintlify section.

Re: CSRF protection without tokens or hidden form fields

#27

Post by varenc »

naasking wrote: post #17
varenc wrote: post #7

Earlier quoted context omitted.

If an attacker has a user's private authentication token, usually stored in a __Host prefixed cookie, then it's game over anyway. CSRF is about protecting other sites forcing a user to make a request to a site they're authenticated to, when the malicious site doesn't actually have the cookie/token. CSRF is when you don't have the authentication token, but can force a user to make a request of your choosing that inclu…

> If we were to re-write browser standards today, cross-domain POST requests probably just wouldn't be permitted. That would be a terrible idea IMO. The insecurity was fundamentally introduced by cookies, which were always a hack. Those should be omitted, and then authorization methods should be designed to learn the lessons from the 70s and 80s, as CSRF is just the latest incarnation of the Confused Deputy: https://…

Ah, so true. That's what i mean! Cross domain requests that pass along the target domain's cookies. As in, probably every cookie would default to current __Host-* behavior. (and then some other way to allow a cookie if you want. Also some way of expressing desired cookie behavior without a silly prefix on its name...)

Re: CSRF protection without tokens or hidden form fields

#28

Post by tptacek »

owenthejumper wrote: post #2

Right now the problem is what the author already mentions - the use of Sec-Fetch-Site (FYI, HTTP headers are case insensitive :) - is considered defense in depth in OWASP right now, not a primary protection. Unfortunately OWASP rules the world. Not because it's the best way to protect your apps, but because the corporate overloads in infosec teams need to check the box with "Complies with OWASP Top 10"

The OWASP Top 10 is a list of vulnerabilities, not a checklist of things you have to actually "do".

Re: CSRF protection without tokens or hidden form fields

#29

Post by tptacek »

miguelgrinberg wrote: post #5
tmsbrg wrote: post #4

I'm surprised there's no mention of the SameSite cookie attribute, I'd consider that to be the modern CSRF protection and it's easy, just a cookie flag: https://scotthelme.co.uk/csrf-is-dead/ But I didn't know about the Sec-Fetch-Site header, good to know.

The OWASP CSRF prevention cheat sheet page does mention SameSite cookies, but they consider it defense in depth: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re... .

Because of clientside Javascript CSRF, which is not a common condition.

Re: CSRF protection without tokens or hidden form fields

#30

Post by 8n4vidtmkvmk »

owenthejumper wrote: post #2

Right now the problem is what the author already mentions - the use of Sec-Fetch-Site (FYI, HTTP headers are case insensitive :) - is considered defense in depth in OWASP right now, not a primary protection. Unfortunately OWASP rules the world. Not because it's the best way to protect your apps, but because the corporate overloads in infosec teams need to check the box with "Complies with OWASP Top 10"

Since when are they case sensitive? https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... says otherwise.

It's possible for a server to treat them as case sensitive, but that seems like a bad idea.

Post reply on HN