Hacker News Reader

Comment by simonw | Hacker News Reader

I've been trying to figure out options for 100% robust protection against CSRF for late 2022 (without using csrftokens in requests, which are tried and tested but are a little bit cludgy to build and use).

It's proving surprisingly difficult to research. Here are my notes so far: https://github.com/simonw/public-notes/issues/2

SameSite=Lax is almost but not quite the answer I'm looking for, for a couple of reasons:

- It doesn't protect against attacks from subdomains, since they can trigger requests that use existing Lax cookies. This is a problem because I can never be sure that a future decision won't be made to CNAME helpdesk.mysite.com over to some third party vendor who might themselves have security holes that enable XSS attacks to run against my domain

- SameSite cookie support is at 95.75% global usage. That's not 100% yet. Where security is concerned, I care about that 4.25% of users. https://caniuse.com/same-site-cookie-attribute

View on HN

How about asserting that the referrer must have at least a matching origin, or better yet path?

I don’t immediately know of any sane configurations that strip a same-origin referrer, but that would cause every request to be blocked as cross-site.

Spoofing a third-party referrer to same-origin is rare, but occasionally done (I think uMatrix defaults to doing that). And unfortunately, it looks like Firefox at least (the only one I’ve checked) includes a trailing slash on third-party referrers rather than only including the origin (that is, it sends `Referer: https://example.com/` for different-origin requests rather than `Referer: https://example.com` like I hoped), so you can’t completely reliably distinguish between an actual first-party request of /, and a spoofed third-party request. But if you’re OK blacklisting the root path, it’d work.

(Actually, what about the Origin header? I’m a little rusty on current statuses and usages of the Origin and Referer headers; haven’t been doing loginny HTTP for a few years. Can’t remember how old the Origin header is, either. But is there some reason you’re not just going for it?)

95.75% is pretty close to solid for SameSite. Those same 4.25% of users who don't support same site are using IE6-10 (.15%), Firefox <2018 (.44%), Chrome <2016 (.35%). The amount of vulnerabilities in those browsers are huge and likely just are leaking cookies anyway through known issues that have since been patched. I'm not spending any time working bugs on IE 6-10 just to get to 100%.

SameSite=Lax plus CORS does the trick.

Block requests where origin=helpdesk.mysite.com.

Also, since you're concerned about subdomain attacks, make sure you set the cookie on a subdomain rather than the naked domain to prevent it from leaking.

Edit: you can put it on the naked domain if your app is on the naked domain. If you do that, do not set the Domain= attribute in your Set-Cookie because that will cause it to leak to subdomains.

Lax plus http-only+secure is probably the best solution atm. I can’t remember details, but IIRC, that should work for the last 10 years or so.

Reply on news.ycombinator.com