Hacker News new | ask | show | jobs
by dagss 253 days ago
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 clients you have decided to trust.

You could say that someone makes a CSRF attack that manages to change these headers of an unwitting client, but at that point absolutely all bets are off you can invent hypothetical attacks to all current CSRF protection mechanisms too. Which are all based on data the client sends.

(If HN comments cannot convince you why you are wrong I encourage you to take the thread to ChatGPT or similar as a neutral judge of sorts and ask it why you may be wrong here.)

1 comments

The doc is wrong and will be updated soon to say that Sec-Fetch-Site is sufficient on its own.

https://github.com/OWASP/CheatSheetSeries/issues/1803

Wow, nice thread!
Yes, this is documenting one particular way of doing CSRF. A specific implementation.

The OP is documenting another implementation to protect against CSRF, which is unsuitable for many since it fails to protect 5% of browsers, but still an interesting look at the road ahead for CSRF and in some years perhaps everyone will change how this is done.

And you say isn't OK, but have not in my opinion properly argued for why not.

It doesn't actually fail to protect 5%, as the top-line 5% aren't really "browsers". Even things like checkboxes often top out at around 95%!

You can change a setting on caniuse.com and it excludes untracked browsers. Sec-Fetch-Site goes up to 97.6, with remainder being a bit of safari (which will likely update soon) and some people still on ancient versions of chrome.

The fallback origin header goes to 99.8 coverage.