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

81–90 of 116 posts

Re: CSRF protection without tokens or hidden form fields

#81

Post by kassner »

hatefulheart wrote: post #46
hn_throwaway_99 wrote: post #43

Earlier quoted context omitted.

The only reason CSRF is even possible is because the browser sends (or, well, used to send) cookies for a particular request even if that request initiated from a different site. If the browser never did that (and most people would argue that's a design flaw from the get go) CSRF attacks wouldn't even be possible. The SameSite attribute makes it so that cookies will only be sent if the request that originated them is…

I think I understand now, the Cookie just is not present in the POST if a user clicked on, for example, a maliciously crafted post from a different origin?

Exactly.

Re: CSRF protection without tokens or hidden form fields

#82

Post by rfmoz »

thaumasiotes wrote: post #64
rfmoz wrote: post #57

Adding more security headers every year feels like strapping seatbelts onto a collapsing roller coaster. It would be better to stop this "sec headers stack" in favour of simpler, secure by default browser primitives with explicit opt-out. Getting an example from https://securityheaders.com the list nowadays is as follows: - Strict-Transport-Security - Content-Security-Policy - X-Frame-Options - X-Content-Type-Options…

Yeah, redoing the defaults would probably be good. On the other hand, I tried doing a Google search with javascript disabled today, and I learned that Google doesn't even allow this. (I also thought "maybe that's just something they try to pawn off on mobile browsers", but no, it's not allowed on desktop either.) So the state of things for "how should web browsers work?" seems to be getting worse, not better.

The reference of robots.txt offer a good way to define specific behavior for the whole domain, as example. Something like that for security could be enough for large amount of websites.

Also, a new header like “sec-policy: foo-url” may be a clean way to move away that definitions from the app+web+proxy+cdn mesh to a fixed clear point.

Re: CSRF protection without tokens or hidden form fields

#83

Post by justarandomname »

NorwegianDude wrote: post #61

The simplest way to prevent CSRF is to use the Referer header, and that has been used since forever. If the header is missing, you no-op the post. Origin is similar, and can be used with referer as fallback, but it's not needed for most sites.

I worked on an legacy application that did this as a stop-gap as CSRF tokens were being implemented and it just kept both approaches.

Re: CSRF protection without tokens or hidden form fields

#84

Post by alserio »

zenmac wrote: post #79
hn_throwaway_99 wrote: post #43

Earlier quoted context omitted.

The only reason CSRF is even possible is because the browser sends (or, well, used to send) cookies for a particular request even if that request initiated from a different site. If the browser never did that (and most people would argue that's a design flaw from the get go) CSRF attacks wouldn't even be possible. The SameSite attribute makes it so that cookies will only be sent if the request that originated them is…

Never needed the CSRF and assumed that cookies was always SameSite, but can see that it was introduced in 2016. Just had the sitename put into the value of the cookie since, and never really needed to think about that. Just feels like all these http specs are super duck tapped together. I guess that is only way to ensure mass adoption for new devs and now vibe coders.

I'm not sure I'm understanding your solution

Re: CSRF protection without tokens or hidden form fields

#85

Post by FiloSottile »

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.

SameSite doesn’t protect against same-site cross-origin requests, so you are staking your app’s security on the security of the marketing blog.

Re: CSRF protection without tokens or hidden form fields

#86

Post by zwnow »

rfmoz wrote: post #82
thaumasiotes wrote: post #64

Earlier quoted context omitted.

Yeah, redoing the defaults would probably be good. On the other hand, I tried doing a Google search with javascript disabled today, and I learned that Google doesn't even allow this. (I also thought "maybe that's just something they try to pawn off on mobile browsers", but no, it's not allowed on desktop either.) So the state of things for "how should web browsers work?" seems to be getting worse, not better.

The reference of robots.txt offer a good way to define specific behavior for the whole domain, as example. Something like that for security could be enough for large amount of websites. Also, a new header like “sec-policy: foo-url” may be a clean way to move away that definitions from the app+web+proxy+cdn mesh to a fixed clear point.

These files are just ignored by everything. We dont need .txt files, we need good defaults.

Re: CSRF protection without tokens or hidden form fields

#87

Post by NorwegianDude »

talkin wrote: post #77
NorwegianDude wrote: post #61

The simplest way to prevent CSRF is to use the Referer header, and that has been used since forever. If the header is missing, you no-op the post. Origin is similar, and can be used with referer as fallback, but it's not needed for most sites.

NO. Please don’t spread wrong solutions. Your attempt has similarities to the idea behind Checking Sec-Fetch-Site. Implementing that header is the same amount of work. But this header is exactly meant for this purpose, and referer is haunted with problems. So for officially intended protections, implementing this header and samesite cookies gets you a very long way without any complexity, assumptions, or tricks of ol…

It's not a wrong solution. It's been commonly used since forever, tens of years before the sec-fetch-site header existed, and it stops CSRF. Sec-fetch-site is not supported in old browsers, so relying on that is unsafe without any fallbacks.

Re: CSRF protection without tokens or hidden form fields

#88

Post by c17r »

paffdragon wrote: post #69
thaumasiotes wrote: post #64

Earlier quoted context omitted.

Yeah, redoing the defaults would probably be good. On the other hand, I tried doing a Google search with javascript disabled today, and I learned that Google doesn't even allow this. (I also thought "maybe that's just something they try to pawn off on mobile browsers", but no, it's not allowed on desktop either.) So the state of things for "how should web browsers work?" seems to be getting worse, not better.

I think it still works if you set your user agent to something like lynx. I had a custom UA set for Google search in Firefox just for this purpose and to disable AI overviews.

I just tried with the "links" browser and I get a "Update your browser. Your browser isn't supported anymore. To continue your search, upgrade to a recent version"

Re: CSRF protection without tokens or hidden form fields

#89

Post by tmsbrg »

FiloSottile wrote: post #85
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.

SameSite doesn’t protect against same-site cross-origin requests, so you are staking your app’s security on the security of the marketing blog.

What do you mean with same-site cross-origin requests?

Re: CSRF protection without tokens or hidden form fields

#90

Post by tmsbrg »

tptacek wrote: post #29
miguelgrinberg wrote: post #5

Earlier quoted context omitted.

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.

What do you mean with clientside Javascript CSRF?
Post reply on HN