4 ms·
Are CSRF attacks that common nowadays though? Even if your app is used by the 5% of browsers that don’t set the Origin header the chances of that being exploite
by ale 1y ago
Are CSRF attacks that common nowadays though? Even if your app is used by the 5% of browsers that don’t set the Origin header the chances of that being exploited are even more miniscule. Besides, most webdevs reach for token-based auth libraries before even knowing how to set a cookie header.
- monster_truck 1y agoYes
- zwnow 1y agoAlso cant you just spoof the origin header?
- kevinyew 1y agoYou can if you want to deliberately CORF yourself for some reason - it's there to protect you, but spoofing it doesn't give you any special access you wouldn't otherwise have. The point is that arbitrary user's browsers out in the world won't spoof the Origin header, which is protecting them from CORF attacks.
- masklinn 1y agoA CSRF is an attack against a logged in user, so has to be mediated via their browser. If you can spoof the origin header of a second party when they navigate to a third party, a CSRF is a complete waste of whatever vulnerability you have found.
- littlecranky67 1y agoCurious about that too. In a modern web-app I always set HttpOnly cookies to prevent them being exposed to anything JavaScript, and SameSite=strict. Especially the later should prevent CSRF.
- jeremyscanvic 1y agoErratum: What I'm saying here only applies for cookies with the attribute SameSite=None so it's irrelevant here, see the comments below. (Former CTF hobbyist here) You might be mixing up XSS and CSRF protections. Cookie protections are useful against XSS vulnerabilities because they make it harder for attackers to get a hold on user sessions (often mediated through cookies). It doesn't really help against CSRF attacks though. Say you visit attacker.com and it contains an auto-submitting form making a POST request to yourwebsite.com/delete-my-account. In that case, your cookies would be sent along and if no CSRF protection is there (origin checks, tokens, ...) your account might end up deleted. I know it doesn't answer the original question but hope it's useful information nonetheless!
- RagingCactus 1y agoThe SameSite cookie flag is effective against CSRF when you put it on your session cookie, it's one of its main use cases. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#samesitesamesite-value https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... for more information. SameSite=Lax (default for legacy sites in Chrome) will protect you against POST-based CSRF. SameSite=Strict will also protect against GET-based CSRF (which shouldn't really exist as GET is not a safe method that should be allowed to trigger state changes, but in practice some applications do it). It does, however, also make it so users clicking a link to your page might not be logged in once they arrive unless you implement other measures. In practice, SameSite=Lax is appropriate and just works for most sites. A notable exception are POST-based SAML SSO flows, which might require a SameSite=None cookie just for the login flow.
- jeremyscanvic 1y agoThanks for correcting me - I see my web sec knowledge is getting rusty!
- hmry 1y agoThis page has some more information about the drawbacks/weaknesses of SameSite, worth a read: https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF#defense_in_depth_samesite_cookies https://developer.mozilla.org/en-US/docs/Web/Security/Attack... You usually need another method as well