Do we still need _HOST?
A modern approach to preventing CSRF in Go
91–100 of 104 posts
Re: A modern approach to preventing CSRF in Go
#92Re: A modern approach to preventing CSRF in Go
#93Earlier quoted context omitted.
It has less than 5% market share left…
it is included in Baseline and passes more tests than safari, so i would hardly call it arcane
Yet people treat it as such and drop support. Remember this is the comment you argued in favor above: https://news.ycombinator.com/item?id=45590086
> From business perspective it makes a lot of sense to just drop that bottom 5%. Actually, many businesses support Chrome only, they don't even support Firefox.
Re: A modern approach to preventing CSRF in Go
#94Earlier quoted context omitted.
Grandma or poor folk with their old device may not be "largely a choice"
It still depends on the target audience. Some websites or apps are single-page applications (SPAs), can older devices handle that? For example, my mum’s Android phone was too slow to even load a page. Secondly, users should upgrade their devices to stay safe online, since vulnerabile people are often scammed or tricked into downloading apps that contain malware. So we should not cater to outdated browsers when they c…
Should we build SPA given it's poorly accessible and provide bad performance?
Tried old school SSR? Even on modern devices, it's waaaayy faster and much more enjoyable than JavaScript bloated "modern" website.
Re: A modern approach to preventing CSRF in Go
#95Earlier quoted context omitted.
There are a lot of people happily browsing away on unsupported Apple devices that don't get any more Safari updates. Lot of strange webkit edge cases to be found that don't exist in any other browser.
Apparently less than 1.5% of global internet users are on versions of safari that don't support Sec-Fetch-Site.
That's a lot of people...
Re: A modern approach to preventing CSRF in Go
#96Earlier quoted context omitted.
I don't think this is accurate. As your parent comment said, Csrf defenses (tokens, origin/Sec-Fetch-Site) serve a different purpose from Auth token/jwt. The latter says that your browser is logged in as a user. The former says "the request actually came from a genuine action on your page, rather than pwned.com disguising a link to site.com/delete-account. You're conflating the two types of Auth/Defense.
You're misunderstanding my point, the Sec-Fetch-Site is not a replacement for CSRF tokens (be they cookies (classic CSRF tokens, auth tokens, JWTs; all of these can be made to work for the client to prove to the server that they are allow to submit a form (and came from the "right" form), some obviously easier than others), a header (such as X-CSRF-Token - Ruby on Rails, Laravel, Django; X-XSRF-Token - AngularJS; CSR…
That’s not correct, or is at least seriously misleading. `Sec-Fetch-Site` is a replacement for CSRF tokens. The sole purpose of CSRF tokens is to prevent CSRF, and enforcing that all unsafe[1]-method requests have a `Sec-Fetch-Site: same-origin` header serves exactly the same purpose – in other words, adding a CSRF token to this policy doesn’t achieve anything. The most relevant difference for most apps is that `Sec-Fetch-Site` isn’t sent by older browsers.
Now, I would actually prefer to make this claim about the `Origin` header, since the spec for `Sec-Fetch-Site`[2] says that “in order to support forward-compatibility with as-yet-unknown request types, servers SHOULD ignore this header if it contains an invalid value.” But given that Go 1.25 is deploying a `Sec-Fetch-Site` check[3] as mentioned in the article and that places are recommending it as defence in depth, the `same-origin` value will probably never change in a way that’s backwards-incompatible with this kind of use.
[1] in the HTTP spec sense
[2] https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-si...
[3] https://cs.opensource.google/go/go/+/master:src/net/http/csr...
Re: A modern approach to preventing CSRF in Go
#97Earlier quoted context omitted.
Sorry, but you seem to be lost. I, the article and most comments here quite explicitly talked about server security via Auth and csrf protections. None of this has anything to do with browser security, such as stealing csrf tokens (which tend to be stored as hidden fields on elements in the html, not cookies). MOREOVER, Sec-Fetch-Site obviates the need for csrf tokens.
"MOREOVER, Sec-Fetch-Site obviates the need for csrf tokens.", you're just posting misinformation, you are flat out wrong. "It is important to note that Fetch Metadata headers should be implemented as an additional layer defense in depth concept. This attribute should not replace a [sic] CSRF tokens (or equivalent framework protections)." -- OWASP; https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
That quote is probably referring to the limitations listed later on the page (https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...). I think if you understood that this was the caveat, you wouldn’t use the phrasing “flat out wrong” or have brought up all the irrelevant stuff about client/server security earlier in the thread. You have some kind of deeper misunderstanding, but it’s not clear where.
Re: A modern approach to preventing CSRF in Go
#98Earlier quoted context omitted.
"MOREOVER, Sec-Fetch-Site obviates the need for csrf tokens.", you're just posting misinformation, you are flat out wrong. "It is important to note that Fetch Metadata headers should be implemented as an additional layer defense in depth concept. This attribute should not replace a [sic] CSRF tokens (or equivalent framework protections)." -- OWASP; https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
That quote is probably referring to the limitations listed later on the page ( https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re... ). I think if you understood that this was the caveat, you wouldn’t use the phrasing “flat out wrong” or have brought up all the irrelevant stuff about client/server security earlier in the thread. You have some kind of deeper misunderstanding, but it’s not clear where.
[deleted]
Re: A modern approach to preventing CSRF in Go
#99Earlier quoted context omitted.
I don't think this is accurate. As your parent comment said, Csrf defenses (tokens, origin/Sec-Fetch-Site) serve a different purpose from Auth token/jwt. The latter says that your browser is logged in as a user. The former says "the request actually came from a genuine action on your page, rather than pwned.com disguising a link to site.com/delete-account. You're conflating the two types of Auth/Defense.
You're misunderstanding my point, the Sec-Fetch-Site is not a replacement for CSRF tokens (be they cookies (classic CSRF tokens, auth tokens, JWTs; all of these can be made to work for the client to prove to the server that they are allow to submit a form (and came from the "right" form), some obviously easier than others), a header (such as X-CSRF-Token - Ruby on Rails, Laravel, Django; X-XSRF-Token - AngularJS; CSR…
False. OWASP will now be modifying it's doc on the topic to say that Sec-Fetch-Site is sufficient on its own, rather than defense in depth. You really have no idea what you're talking about.
Re: A modern approach to preventing CSRF in Go
#100Earlier quoted context omitted.
You say you should "never trust the client". Well trust has to be established somehow right, otherwise you simply cannot allow any actions at all (airgap). Then, CSRF is preventing a class of attacks directed against a client you actually have decided to trust, in order to fool the client to do bad stuff. All the things you say about auth: Already done, already checked. CSRF is the next step, protecting against clien…
https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
The doc is wrong and will be updated soon to say that Sec-Fetch-Site is sufficient on its own.