It worries me that there doesn’t seem to be any visible effort to determine how many websites this would break (which would have to opt out of the new default behavior). I assume there is some, but it’s not mentioned here at least.
It looks like 10% of Internet users don’t use browsers that support this so I suggest it’s too early to declare CSRF dead.
This one is just one of many security features these browsers don’t have. If these users haven’t updated their browsers for so many years, they’re probably not installing regular security patches too.
One thing that I don’t think this cookie thing solves is CSRF when it comes to POSTs done by unauthenticated users.
If you have a comment form on your site but no anti-CSRF token in the submit form, then people could just trigger POST requests for your website from theirs.
the anti-CSRF token lets you verify that the form was generated by you, so to speak.
I would be pretty interested in not needing to deal with anti-CSRF tokens on validated forms in general though…
That’s what this brings you. Doesn’t it? You can get it NOW by explicitly setting your cookies as SameSite. All major browsers already support the SameSite attribute, but not all set it by default.
No? The question being asked here is whether you can get CSRF protection on forms with no required cookies. A mitigation that limits cookies won’t fix that.
If the form is anonymous, is CSRF even a thing? If there’s no user to attack, then there’s no harm. At best it seems like nuisance comparable to hotlinking.
Kind of, though it’s a bit more work than just what CSRF normally takes.
A typical site that accepts anonymous submissions will use IP address rate limits. A site operator that wants to screw over another site could embed a script that submits a hidden form in an iframe over and over, essentially using the visitors as DoS reflectors. (Obviously, you could make them deny service with just image hotlinking, but having everybody that visits your site automatically submit a question to Stack Overflow in the background would be much more damaging with much fewer visitors).
Not even a nuisance: a feature! Lots of useful things can rely on forms from one site POSTing to another – in fact, even CSRF would be useful if there were some way a browser could warn a user to prevent the attack-mode version of it.
Oh, thank you. I misread that. You can soon get this with fetch-metada though.
From a 2017 article by the same author, just set SameSite=lax on the cookies you send to your visitors:
Set-Cookie: sess=abc123; path=/; SameSite=lax
The OP is that Chrome is about to make this the default for all received cookies in an upcoming release.
This cookie option allows the cookie to be sent with a request only when the browser is viewing the page, and is not sent for cross site requests. In other words, if a server is getting the cookie, the server must have sent it, the browser supports the option, and the option was set to “Lax,” then there’s no reason for the anti-csrf token.
You could issue one SameSite cookie to all unauthenticated users and check for that cookie (or one for a logged-in session) when validating the form submission.
It’s a fundamental problem of web that you have to actually do a fix top stop CSRF. It’s unfortunate that we can’t just repair the system to not have the issue.
But this is repairing it! :)
The issue is ambient authority (your cookies being sent in all cross site requests, regardless if it’s form, image, script etc). The fix is not doing so (samesite by default).