3 ms·

It's good that folks working on browsers are working on making this easier, but I don't think you can really rely on this for GET requests. It's often easier t

by Eridrus 10mo ago

It's good that folks working on browsers are working on making this easier, but I don't think you can really rely on this for GET requests. It's often easier to smuggle a same-origin request than to steal a CSRF token, so you're widening the set of things you're vulnerable to by hoping that this can protect state mutating GETs. The bugs mentioned in the GitHub issue are some of the sorts of issues that will hit you, but also common things like open redirects turn into a real problem. Not that state mutating GETs are a common pattern, but it is encoded as a test case in the blog post's web framework.

nchmy 10mo ago
I was involved in the effort to add/upgrade Fetch Metadata in the OWASP cheat sheet. We had discussed GET requests, so if you find the guidance lacking about it, please let us know how. Likewise, if you could elaborate on the open redirects issue, that would be great.
- Eridrus 10mo ago
  I haven't actually dug into it, but I would assume that open redirects would strip a Sec-Fetch-Site: cross-site header and replace it with none or same-site or something. So would things like allowing users to specify image URLs, etc. And if you rely on Sec-Fetch-Site for security on GETs, these turn into actual vulnerabilities. I think these sorts of minor web app issues are common enough that state changing GETs should be explicitly discouraged if you are relying on Sec-Fetch-Site.
  - nchmy 10mo ago
    https://www.w3.org/TR/fetch-metadata/#redirects https://www.w3.org/TR/fetch-metadata/#redirects
    - Eridrus 10mo ago
      Well that's a good decision. I doubt it covers client-side redirects, but still good for like 95% of cases. People do still allow 3rd party images/links on websites. Much less common in typical software, but it does happen.
      - nchmy 10mo ago
        why wouldnt it cover client-side redirects?
        Eridrus 10mo ago
        Why would it? Someone has to go and write the code to do it and the spec doesn't look like it covers them. Playing with window.location and meta redirects in jsfiddle, they both seem to lose cross-site context when I link to them.
        nchmy 10mo ago
        Can you share an example?
miguelgrinberg 10mo ago
Hi, blog post author here. With regard to state-changing GET requests, I do not recommend their use and I agree that they create some problems for CSRF protection, but you are correct that I did include tests that verify that they can be enabled in my Microdot web framework. Please correct me if I have missed anything, but I have designed this feature in my framework so that the default action when evaluating CSRF-related headers is to block. I then check all the conditions that warrant access. The idea is that for any unexpected conditions I'm not currently considering the request is going to be blocked, which ensures security isn't put at risk. I expect there are some situations in which state-changing GET requests are not going to be allowed, where they should be. I don't think the reverse situation is possible, though, which is what I intended with my security first design. I can always revisit the logic and add more conditions around state-changing GET requests if I have to, but as you say, these are uncommon, so maybe this is fine as it is.

by Eridrus 10mo ago

nchmy 10mo ago

I was involved in the effort to add/upgrade Fetch Metadata in the OWASP cheat sheet. We had discussed GET requests, so if you find the guidance lacking about it, please let us know how. Likewise, if you could elaborate on the open redirects issue, that would be great.

Eridrus 10mo ago
I haven't actually dug into it, but I would assume that open redirects would strip a Sec-Fetch-Site: cross-site header and replace it with none or same-site or something. So would things like allowing users to specify image URLs, etc. And if you rely on Sec-Fetch-Site for security on GETs, these turn into actual vulnerabilities. I think these sorts of minor web app issues are common enough that state changing GETs should be explicitly discouraged if you are relying on Sec-Fetch-Site.
- nchmy 10mo ago
  https://www.w3.org/TR/fetch-metadata/#redirects https://www.w3.org/TR/fetch-metadata/#redirects
  - Eridrus 10mo ago
    Well that's a good decision. I doubt it covers client-side redirects, but still good for like 95% of cases. People do still allow 3rd party images/links on websites. Much less common in typical software, but it does happen.
    - nchmy 10mo ago
      why wouldnt it cover client-side redirects?
      - Eridrus 10mo ago
        Why would it? Someone has to go and write the code to do it and the spec doesn't look like it covers them. Playing with window.location and meta redirects in jsfiddle, they both seem to lose cross-site context when I link to them.
        nchmy 10mo ago
        Can you share an example?

miguelgrinberg 10mo ago

Hi, blog post author here. With regard to state-changing GET requests, I do not recommend their use and I agree that they create some problems for CSRF protection, but you are correct that I did include tests that verify that they can be enabled in my Microdot web framework. Please correct me if I have missed anything, but I have designed this feature in my framework so that the default action when evaluating CSRF-related headers is to block. I then check all the conditions that warrant access. The idea is that for any unexpected conditions I'm not currently considering the request is going to be blocked, which ensures security isn't put at risk. I expect there are some situations in which state-changing GET requests are not going to be allowed, where they should be. I don't think the reverse situation is possible, though, which is what I intended with my security first design. I can always revisit the logic and add more conditions around state-changing GET requests if I have to, but as you say, these are uncommon, so maybe this is fine as it is.