10 ms·
CSRF is really dead
- tptacek 7y agoPreviously: https://news.ycombinator.com/item?id=19853090 https://news.ycombinator.com/item?id=19853090
- jasonhansel 7y agoWhat we really want is a failsafe way of setting cookies: i.e. a way of setting cookies that won't work on browsers without SameSite support. Otherwise this solution will still leave a security hole for the many users not on (the latest version of) Chrome. Ideally we could do this by intentionally making the SameSite cookie syntax non-backwards-compatible.
- feanaro 7y agoSo... Break the web for anyone not on the latest version of Chrome?
- jasonhansel 7y agoNo, just give devs the ability to easily catch the error & use an alternative, secure solution.
- lighthazard 7y ago"easily"
- javagram 7y agoIf there were an easy, alternative secure solution then developers would already be using it. Implementing common anti-XSRF mechanisms like a session token in a form field or extra http header requires modifying every place your app communicates with the server. It’s anything but easy which is why so many apps/websites not built with XSRF in mind still have vulnerabilities.
- hirsin 7y agoHas there ever been a breaking change approved by the IETF? I'm not familiar enough with their history to know of precedence. It seems like the spec/standard should be approved at least before we go about asking developers to incur hundreds of millions of dollars in updates so their sites continue working in Chrome. Ironically, this breaks CSRF protection in OIDC authentication systems (except Google, since they don't implement the form_post standard).
- al2o3cr 7y agoWebsite operators will need to do nothing to have the powerful protection of SameSite by default Alternative phrasing: Website operators who depend on the existing behavior will have to make changes to have their sites work in Chrome at all IMO this is a useless default - sites will still need existing CSRF protection techniques since not everyone runs Chrome - that will marginally increase security on small fraction of sites (that DGAF about CSRF) and break a small fraction of sites.
- al2o3cr 7y agoIt gets better: the linked Chrome feature "Cookies default to SameSite=Lax" mentions a bug in Safari (fixed in a not-yet-released version) that causes cookies with "SameSite=None" to not be sent in cross-site requests. So when Chrome 80 comes out, your options for setting cross-site cookies will look like: * send nothing, and break in Chrome 80+ because of the new default * send "SameSite=None", and break on any Safari besides the latest because of the bug * send anything else, and break because that's what SameSite does Heckuva job, Chrome team.
- tptacek 7y agoDon't you mean "heckuva job, Safari team"?
- hirsin 7y agoNo. They have a bug in their implementation of the spec, but Chrome is going off spec here, and dropping breaking changes into the ecosystem in a way that requires developers to UA sniff. The Safari bug is annoying today, but ultimately didn't impact anyone that was spec compliant. Chrome does impact people who are spec compliant.
- andrei_says_ 7y agoPrecisely this. The 800 pound gorilla changing the rules on everyone is very bad despite short term outcome.
- V3ritas1337 7y agoCalling CSRF dead is the wrong way to interpret it. There would be few security issues surrounding web apps if devs were security conscious, unfortunately only few are. There are many mitigations for security vulnerabilities surrounding web apps, CSRF is very much alive, and it is a common finding of mine.
- noncoml 7y agoI think he means CSRF prevention hacks are dead, because, despite being the norm, adding a CSRF token in each POST request is indeed an ugly hack.
- edoceo 7y agoNot ugly, it's just passing a state-key around - a common practice in loads of other communication channels.
- AmericanChopper 7y agoThat doesn’t really fit in with modern web interfaces though. REST and GraphQL are both stateless architectures. Tracking and mutating a state on every request doesn’t fit very well with with that.
- MaxBarraclough 7y agoDepending on exactly what we're doing, we can work around this with crypto, right? A token can securely prove that it was issued by the server/service, and under what conditions, without the server/service statefully tracking the token after issuing it. I know I'm not the first to think of this, but I'm not sure how widely used this sort of technique is in practice.
- AmericanChopper 7y agoThat’s exactly how authentication JWTs work. They work differently from CSRF tokens though, because the CSRF token is generated for each request, not each ‘session’ (so you need much more complex server-side state management). But that said CSRF isn’t particularly relevant if you’re using a JWT in the Authorization header. CSRF attacks the fact that browsers will use cookies to automatically authenticate requests. If you’re not using cookies for authentication, and adding a JWT to the headers instead, then that automatic authentication doesn’t occur. Correct me if I’m wrong, but I’m not aware of any CSRF attack that targets Authorization headers, I believe any attack that does is just an XSS.
- osrec 7y agoCould we just avoid cookies altogether, and store session info in local storage? Sure it takes a bit of JS to pass the data as part of a request, but at least you're not prone to CSRF issues. I'm not sure there are many use cases where I really need cookies if I have local storage and JS available.
- deleted 7y ago[deleted]
- jusob 7y agoBut any XSS would give access to your authentication token, this is why you should never store it in local storage. Cookies have the httponly flag that prevents javascript from accessing the cookie in case of XSS.
- paulddraper 7y agoXSS is usually really, really bad anyway. CSP plus trusted scripts...you should be working hard to prevent XSS.
- earthboundkid 7y agoIdeally, yes. In the current advertising market? No.
- paulddraper 7y agoI don't know much about advertising. Can't they be easily handled with an iframe?
- amlozano 7y agoHttpOnly doesn't really do much to stop an attacker that already has XSS. The attacker just makes the XSS perform the interactions they want directly instead of bothering to steal the cookie. James Kettle wrote a good blog post that argues that webstorage is probably a better spot for session tokens here: https://portswigger.net/blog/web-storage-the-lesser-evil-for-session-tokens https://portswigger.net/blog/web-storage-the-lesser-evil-for...
- badrabbit 7y agoForgive my ignorance but from what I read making SameSite=Lax the default is a chrome only thing at this time right? If so,how is CSRF dead? Are all major browsers following suit?
- javagram 7y agoThis is good news I think. Devs often just don’t know or pay attention to stuff like XSRF in my experience as a professional developer. It’s not something you notice until your site gets hacked. Or if you do notice it, it’s in a security audit at the end of development and the ticket to fix it might get buried in a backlog below the features and bugs users actually see and want. Having the protection on by default is the only way to solve this for good, it’s how cookies always should have been. Turning cookies to same site by default will definitely break a lot of things though. I implemented SameSite cookie functionality in a library at work and we had several issues with it breaking stuff and confusing people when they updated to the new secure version of the library.
- birdyrooster 7y agoI was mocked at at Black Hat when I asked a question several years ago why people don't consider forward proxying all third party dependencies for the user. Then we could disable CSR entirely. They said that doing that would fundamentally break the web. I think that it would make it so your user could never be MITM or DNS-spoofed to a malicious imposter for that dependent service or asset. Can someone speak to those criticisms?
- benmmurphy 7y agoTechnically following a http link is a cross site request.
- a1369209993 7y agoIf the browser honors a SameSite policy on links it's the browser that's broken.
- xg15 7y agoSeems that is exactly the difference between "lax" and "strict" settings: "strict" will strip cookies from all cross-site requests, "lax" will keep them for GETs. The default setting will be "lax", so following links would be fine. I think the "strict" setting is for the proposed "two sessions cookies" design pattern: You have a basic "I'm logged in" cookie with SameSite=lax and a second "I can do things" cookie with SameSite=strict. The first cookie gives you read access to your account and tracks your session - however, to perform any actions on your account, you need both cookies.
- a1369209993 7y agoLinks are GET requests; you do not "do things" on GET requests.
- xg15 7y agoYes, that's the point. If you e.g. clicked on a link to facebook.com and had previously logged in, the browser will send the "lax" cookie with the request, so that your session is correctly tracked and Facebook shows you the logged-in view. However, the "strict" cookie will NOT be sent, so even if by some accident you have a state-changing endpoint that accepts GETs, an attacker could still not trick you into invoking it via a link. I agree though that if you have state-changing GETs, you'll have bigger problems, so the use-case for "strict" cookies seems a bit of a niche. I suspect the common case will be "lax" everywhere and "none" for special applications - i.e. what the default is encouraging.
- ga-vu 7y agoThis guy and his stupid hot takes again. Of all infosec superstars, I hate this guy the most.
- deleted 7y ago[deleted]
- Osiris 7y ago> When SameSite first came out, nobody wanted to make it the default. It could break things, change expected (legacy) functionality and generally speaking the worry of breaking stuff stops us making progress. So, when it first came out, it was not okay to break things to turn it on by default. But, now it's okay to break things by making it the default. I'm starting to feel like we're back in the Internet Explorer 6 age (in terms on having one browser that dominates and can arbitrarily change the rules/standards of the web).
- VeryHacker 7y agoWell, they've got plenty of time to test the feature. Now time's up
- treggle 7y agoClickbait. This needs a different title. This is NOT saying CSRG is dead. It is saying “same site cookies are an alternative to CSRF”.
- viraptor 7y agohttps://caniuse.com/#feat=same-site-cookie-attribute https://caniuse.com/#feat=same-site-cookie-attribute As usual, supported almost everywhere, apart from the any IE that's not the latest, running on an updated windows 10. So we can't really use it unless we want to leave lots of users insecure.
- IMMUNISE 7y ago^ This. Last I checked it was not supported w/ IE11 on Windows 7. I have no idea why samesite capability would ever depend on the host OS. Shame on Microsoft for not supporting a somewhat simple to implement security feature on older (but supported) operating systems.
- jdnenej 7y ago"lots of users", unless you are working with enterprise software I wouldn't call IE lots of users. Just display a banner for IE users informing them that using the site with IE is insecure and suggest alternatives.
- viraptor 7y agoIn enterprise IE may be the majority, but for common users IE is still often the default. Basically if you don't target tech crowd, IE users are your users. A website I manage (targeted for location only) has 20% IE traffic on desktop.
- jdnenej 7y agoThat is unusual because globally IE makes up almost no users.
- danShumway 7y agoI agree with the change in theory (although as a side-note I wish users had more control over cookie/request headers, and it wasn't just site-operators that could set policies). It's a reasonably obvious oversight that cookies aren't same-site by default, and the thoughts behind this seem pretty solid. There's even a good point that I've seen made that secure-by-default might give browsers/blockers a useful metric for identifying likely tracking cookies. I have no objections on that front. I wish the Chromium team was working more with other browsers to make this a more coordinated change. At the same time, I don't think that there would be significantly less breakage if it was. No matter what, this is 100% going to break websites -- there is just no way to roll out a change like this without disrupting operations. It's gonna be a mess, and it would still be a mess even if all the browsers rolled out this change together. It feels kind of like the JS ``typeof null === "object"`` stuff. Everyone agrees the existing behavior is wrong, but we're not sure when and how to fix it. So I'm a little conflicted. I understand completely why the Chromium team wants this, and I also understand why some people are going to be upset about it. Blocking CSRF by default in a browser is really good. We'd also really like to avoid breaking the existing web. It's complicated.
- thayne 7y ago> I wish the Chromium team was working more with other browsers to make this a more coordinated change. The same change is in development for firefox as well: https://groups.google.com/forum/#!msg/mozilla.dev.platform/nx2uP0CzA9k/BNVPWDHsAQAJ https://groups.google.com/forum/#!msg/mozilla.dev.platform/n...
- zeroimpl 7y agoWhy is the default lax instead of strict?
- rosybox 7y agoBecause strict would break how people expect the internet to work. Any links from a third party website to a site where the session cookie is set with SameSite strict, clicking those links will not include the session cookie for that site. For example, if GitHub implemented SameSite strict for its session cookie and you clicked a link on a site that took you to GitHub, it would not send the cookie for GitHub and it will look like you're not logged in on GitHub, even though if you opened a new tab and went to GitHub you would be logged in. https://www.owasp.org/index.php/SameSite https://www.owasp.org/index.php/SameSite
- zeroimpl 7y agoAh so Strict is super strict, whereas Lax is still stricter than the current default. Lax seems like it should have been named something else, like Partial or Moderate.
- thayne 7y agoI wouldn't say CSRF is dead yet. Chrome is just one browser, until all major browsers have implemented this (and IE11 is still kicking), you still need to implement CSRF mitigations as well.
- fulafel 7y agoRe IE11 - https://caniuse.com/#feat=same-site-cookie-attribute https://caniuse.com/#feat=same-site-cookie-attribute says that IE11 supports it on Windows 10. Still leaves W7+IE11 but that's a much smaller (and shrinkin) set of users.
- foxyv 7y agoExcept when your client uses IE8. pained crying