3 ms·

Help me understand: Strict means I break the basic way in which the web works, links? It seems to me a useful feature (Ironic!) I could get that in certain cas

by LukaAl 10y ago

Help me understand: Strict means I break the basic way in which the web works, links? It seems to me a useful feature (Ironic!) I could get that in certain case it is a good idea to be strict (e.g: banking, e-commerce), but it is a relatively small percentage of the web. And the Lax policy doesn't solve the issue because, well, someone could always screw and forgot they don't accept submission on Post. Don't get me wrong, it is a useful and powerful tool. What I'm simply saying is that CSRF is paraphrasing Mark Twain right now: "The reports of my death are greatly exaggerated". P.s: also the other comments are right...

Cogito 10y ago
Strict doesn't break links, it breaks sites that set "expected" cookies to strict. Those expected cookies won't be available in some situations that might have been expected, such as navigating to the site directly. So if news.ycombinator.com cookies were set to strict, they will not be sent when I open the site, or indeed at all unless I was navigating from within the site (thus stopping cross origin attacks, but also stopping them being sent on first page load). If these cookies were used to identify a logged in user, the user will not be logged in as the cookie would not be sent. The link still works, but the behaviour is perhaps unexpected. One solution is to have a trusted, strict cookie, and it is required for any actions that originate from the origin site - upvoting, new posts, comments, etc. You then have a second, untrusted, non-strict cookie that is used to identify a user. As long as this cookie is not used for any trusted operations, you have restricted the potential attack surface a lot. None of this breaks links, it only breaks user experience expectations if utilised naively (like hacker news using strict cookies for their persistent login tokens).
- ludwigvan 10y ago
  So if the user refreshes after landing on the strict site, cookies will be sent right? Kind of breaks the idempotency of GET.
  - Cogito 10y ago
    Correct, strict cookies will be sent with a request that originates from the same origin as the cookie. It doesn't really break the idempotency of GET, as the idempotency assumes the cookies sent with the request are the same. That is, the expectation remains that if you send the same GET request with the same headers (including the same cookies) you should get the same response back. Note that this is a client-side feature. The browser is choosing to not send cookies based on this policy. If you're crafting a request yourself it is up to you to include the correct cookies, just as it always has been. All this is doing is providing a way for websites to ask browsers "never send this cookie unless the user is already on my site" (strict) and "never send this cookie unless the user is already on my site, or is performing a top-level request with a safe method" (lax). The protocol still expects idempotent behaviour, but the user may be surprised that the browser didn't include their auth token with a top-level request, if the site had requested it be a strict cookie. If that happens it's a shortfall of the site, not of this addition to the protocol.
    - ludwigvan 10y ago
      Thank you for the detailed information, Cogito.
- LukaAl 10y ago
  Well, from a user perspective it breaks links meaning that they work in an unexpected way. For sure it is a much-needed improvement, but it is not a fix it all feature.
  - Cogito 10y ago
    The feature itself doesn't break links in that way at all. If, and only if, (1) a website uses strict cookies on a cookie (2) the website assumes that cookie (1) is always available for 'valid requests' (3) the website assumes that 'valid requests' (2) include top-level navigation events (such as typing the website's url into the browser bar) then any behaviour that relies on the existence of that cookie will break in some situations. That is, only a naive use of this feature will cause breakage. Worthwhile knowing about for developers, but in an ideal world would never cause issues for users. In an ideal world there would be a solution without this shortfall, but it seems like an almost necessary feature due to how some cross origin requests are made (by spawning a new window etc).

by LukaAl 10y ago

Cogito 10y ago

Strict doesn't break links, it breaks sites that set "expected" cookies to strict. Those expected cookies won't be available in some situations that might have been expected, such as navigating to the site directly. So if news.ycombinator.com cookies were set to strict, they will not be sent when I open the site, or indeed at all unless I was navigating from within the site (thus stopping cross origin attacks, but also stopping them being sent on first page load). If these cookies were used to identify a logged in user, the user will not be logged in as the cookie would not be sent. The link still works, but the behaviour is perhaps unexpected. One solution is to have a trusted, strict cookie, and it is required for any actions that originate from the origin site - upvoting, new posts, comments, etc. You then have a second, untrusted, non-strict cookie that is used to identify a user. As long as this cookie is not used for any trusted operations, you have restricted the potential attack surface a lot. None of this breaks links, it only breaks user experience expectations if utilised naively (like hacker news using strict cookies for their persistent login tokens).

ludwigvan 10y ago
So if the user refreshes after landing on the strict site, cookies will be sent right? Kind of breaks the idempotency of GET.
- Cogito 10y ago
  Correct, strict cookies will be sent with a request that originates from the same origin as the cookie. It doesn't really break the idempotency of GET, as the idempotency assumes the cookies sent with the request are the same. That is, the expectation remains that if you send the same GET request with the same headers (including the same cookies) you should get the same response back. Note that this is a client-side feature. The browser is choosing to not send cookies based on this policy. If you're crafting a request yourself it is up to you to include the correct cookies, just as it always has been. All this is doing is providing a way for websites to ask browsers "never send this cookie unless the user is already on my site" (strict) and "never send this cookie unless the user is already on my site, or is performing a top-level request with a safe method" (lax). The protocol still expects idempotent behaviour, but the user may be surprised that the browser didn't include their auth token with a top-level request, if the site had requested it be a strict cookie. If that happens it's a shortfall of the site, not of this addition to the protocol.
  - ludwigvan 10y ago
    Thank you for the detailed information, Cogito.
LukaAl 10y ago
Well, from a user perspective it breaks links meaning that they work in an unexpected way. For sure it is a much-needed improvement, but it is not a fix it all feature.
- Cogito 10y ago
  The feature itself doesn't break links in that way at all. If, and only if, (1) a website uses strict cookies on a cookie (2) the website assumes that cookie (1) is always available for 'valid requests' (3) the website assumes that 'valid requests' (2) include top-level navigation events (such as typing the website's url into the browser bar) then any behaviour that relies on the existence of that cookie will break in some situations. That is, only a naive use of this feature will cause breakage. Worthwhile knowing about for developers, but in an ideal world would never cause issues for users. In an ideal world there would be a solution without this shortfall, but it seems like an almost necessary feature due to how some cross origin requests are made (by spawning a new window etc).