4 ms·

This isn't true. Although SameSite is a good defence in depth, it provides no protection against CSRF from sub-domains (subdomain hijacking is fairly common), o

This isn't true. Although SameSite is a good defence in depth, it provides no protection against CSRF from sub-domains (subdomain hijacking is fairly common), or in older browsers. It also is incompatible with some site features - e.g. OIDC form_post response mode, SAML SLO with HTTP POST binding, etc.

chrismorgan 6y ago
Subdomain hijacking is only possible if you’ve allowed subdomains to be used for such other things, which I strongly assert is rare. Older browsers: all browser releases from the last couple of years support it (including IE11); browsers from before then should not be being used on the public internet under any circumstances. It should be a negligible fraction of your user base that uses such browsers, and so long as you’re also happy to break IE11, a safe path (from a security perspective) is to actively break the site for old browsers by blacklisting them or checking for support of a comparatively recent feature. (Just don’t do a whitelist by user agent string, that approach is unmitigatably bad.) You’re correct about some auth systems not playing nicely with strict same-site cookies, because they’ve been designed with certain assumptions in mind. I’m not particularly conversant with that space, never having had to interact with such a system.
- nmadden 6y ago
  Subdomain hijacking is not rare for the simple reason that websites are built by marketing departments. E.g., here’s Hanno Böck tweeting about a subdomain takeover he found at Kaspersky just recently: https://twitter.com/hanno/status/1257958739132514304 https://twitter.com/hanno/status/1257958739132514304 There’s a whole cottage industry of people finding these vulnerabilities on a very regular basis: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers https://www.hackerone.com/blog/Guide-Subdomain-Takeovers
  - chrismorgan 6y ago
    Which is one reason why a best practice (and a very common practice, though a long way off universal) is to make sure that the cookies are scoped to your app only, e.g. by putting your app on a subdomain of its own and scoping your auth cookies to that subdomain.
    - nmadden 6y ago
      That doesn't impact CSRF at all. If I send a request from a page on foo.example.com to api.example.com your browser will send those cookies no matter how tightly scoped they are because the destination of the request matches the cookie. It will send those cookies whether you use host cookies, add a __Host_ prefix, set SameSite=strict, Secure, HttpOnly, etc, etc, etc. If you want to protect against these attacks with basic cookie attributes you can use SameSite and register your site (and any intermediate sub-domains) on the public suffix list to effectively shun your subdomains as being completely separate sites.
      - chrismorgan 6y ago
        If you’re going from foo.example.com to api.example.com, sure, SameSite won’t protect you because those two origins are considered same-site. So don’t do that: keep your API calls on foo.example.com, with domain=foo.example.com cookies. Also, I seem to recall the PSL maintainers requesting at some point that people not do what you describe, because it wouldn’t scale at all.
        nmadden 6y ago
        Firstly, setting the domain attribute on a cookie explicitly allows sub-domains. You want to leave that off to enable host-only cookies. But secondly, as I just said the host/domain on the cookie does nothing at all to prevent cross-origin requests to that domain, which is the relevant concern for CSRF. Setting the domain/host is completely irrelevant to this attack. Yes, adding to PSL is not at all scalable and will likely cause you a world of pain down the road. It was not intended as a serious suggestion. Use proper CSRF defences.

chrismorgan 6y ago

Subdomain hijacking is only possible if you’ve allowed subdomains to be used for such other things, which I strongly assert is rare. Older browsers: all browser releases from the last couple of years support it (including IE11); browsers from before then should not be being used on the public internet under any circumstances. It should be a negligible fraction of your user base that uses such browsers, and so long as you’re also happy to break IE11, a safe path (from a security perspective) is to actively break the site for old browsers by blacklisting them or checking for support of a comparatively recent feature. (Just don’t do a whitelist by user agent string, that approach is unmitigatably bad.) You’re correct about some auth systems not playing nicely with strict same-site cookies, because they’ve been designed with certain assumptions in mind. I’m not particularly conversant with that space, never having had to interact with such a system.

nmadden 6y ago
Subdomain hijacking is not rare for the simple reason that websites are built by marketing departments. E.g., here’s Hanno Böck tweeting about a subdomain takeover he found at Kaspersky just recently: https://twitter.com/hanno/status/1257958739132514304 https://twitter.com/hanno/status/1257958739132514304 There’s a whole cottage industry of people finding these vulnerabilities on a very regular basis: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers https://www.hackerone.com/blog/Guide-Subdomain-Takeovers
- chrismorgan 6y ago
  Which is one reason why a best practice (and a very common practice, though a long way off universal) is to make sure that the cookies are scoped to your app only, e.g. by putting your app on a subdomain of its own and scoping your auth cookies to that subdomain.
  - nmadden 6y ago
    That doesn't impact CSRF at all. If I send a request from a page on foo.example.com to api.example.com your browser will send those cookies no matter how tightly scoped they are because the destination of the request matches the cookie. It will send those cookies whether you use host cookies, add a __Host_ prefix, set SameSite=strict, Secure, HttpOnly, etc, etc, etc. If you want to protect against these attacks with basic cookie attributes you can use SameSite and register your site (and any intermediate sub-domains) on the public suffix list to effectively shun your subdomains as being completely separate sites.
    - chrismorgan 6y ago
      If you’re going from foo.example.com to api.example.com, sure, SameSite won’t protect you because those two origins are considered same-site. So don’t do that: keep your API calls on foo.example.com, with domain=foo.example.com cookies. Also, I seem to recall the PSL maintainers requesting at some point that people not do what you describe, because it wouldn’t scale at all.
      - nmadden 6y ago
        Firstly, setting the domain attribute on a cookie explicitly allows sub-domains. You want to leave that off to enable host-only cookies. But secondly, as I just said the host/domain on the cookie does nothing at all to prevent cross-origin requests to that domain, which is the relevant concern for CSRF. Setting the domain/host is completely irrelevant to this attack. Yes, adding to PSL is not at all scalable and will likely cause you a world of pain down the road. It was not intended as a serious suggestion. Use proper CSRF defences.