6 ms·

I deeply appreciate this thorough review of CSRF protection via headers. I've been looking into the topic to see if I can get rid of csrf tokens, and it seems l

by nchmy 1y ago

I deeply appreciate this thorough review of CSRF protection via headers. I've been looking into the topic to see if I can get rid of csrf tokens, and it seems like I can now - if I ignore/don't care about the 5% of browsers that don't support the required headers. It makes me wonder though - most browser APIs top out around 95% coverage on caniuse.com. What are these browsers/who are these people...? The modern web is very capable and can greatly simplify our efforts if we ignore the outliers. I'm inclined to do so. But am also open to counterarguments

anal_reactor 1y ago
From business perspective it makes a lot of sense to just drop that bottom 5%. Actually, many businesses support Chrome only, they don't even support Firefox. Technological counterargument though is that you should allow people to tinker and do weird shit. Once upon a time tech wasn't about maximizing stock value, it was about getting Russian game crack to work, and making Lora's boobs bigger. Allowing weird shit is a way to respect the roots of modern tech, and allow hobbyists to tinker.
- nchmy 1y ago
  Thanks for confirming. I don't know that it has to be framed as a "business perspective" though. I'm a solo dev for a non-profit project, so ignoring the 5% is just a matter of pragmatism. I most defintiely do not care about tinkerers, and in fact would generally classify them as something akin to attackers. I just want to allow as many people to use the app as possible, while keeping things simple and secure.
- cryptonym 1y ago
  Empathy and accessibility. Does it make sense to have a ramp in front of your shop for < 5% customers?
  - nchmy 1y ago
    My question, though, is who are the 5% of users in this case who are using some arcane browsers? Surely that's largely a choice, physical disabilities are not. It doesn't seem unreasonable to say to those folks "were evidently not using the same web"
    - littlestymaar 1y ago
      It's not comparable to a physical disability byt gatekeeping the people who just don't want to be tracked all day by Google doesn't sounds right to me though.
      - nchmy 1y ago
        There's plenty of other chromium browsers - Vivaldi seems to do a good job in this regard. Also, Firefox exists, though they don't seem to care about privacy much anymore either. And, of course, safari, which is terrible in most regards
        littlestymaar 1y ago
        > There's plenty of other chromium browsers - Vivaldi seems to do a good job in this regard. Being chromium derivatives, they don't really have a say in what's included in “their” browser though. > Also, Firefox exists Well, you disregarded is as “arcane browser” right above.
        nchmy 1y ago
        In what way did I call Firefox arcane? Firefox generally has better support for web features than safari.
        littlestymaar 1y ago
        It has less than 5% market share left…
- wongarsu 1y ago
  For a lot of businesses, 5% of revenue is a lot more than the cost of supporting older browsers What shifts the discussion a bit is that many of the bottom 5% aren't lost customers. If your website doesn't work on my minority browser, smart TV or PS Vita I might be willing to just try it in Chrome instead
johannes1234321 1y ago
Those 5% are probably a wild collection of devices. TVs with embedded Browsers, old phones and other computers elsewhere. As example: my late grandfather of 100 years took records of his stamp collection in Excel. He used the computer for Wikipedia as well, but we didn't upgrade ist as he was comfortable, but upgrading to later Windows to ruin newer browser would have been too much of a change and rather made him stop doing what brought him fun. The router etc blocked worst places frequent backups allowed restore, thus actual risk low. Anecdote aside: there are tons of those machines all over. And then another big one: bots claiming to be something which they aren't.
- veeti 1y ago
  There are a lot of people happily browsing away on unsupported Apple devices that don't get any more Safari updates. Lot of strange webkit edge cases to be found that don't exist in any other browser.
  - nchmy 1y ago
    Apparently less than 1.5% of global internet users are on versions of safari that don't support Sec-Fetch-Site.
    - saurik 1y ago
      That's a lot of people...
kijin 1y ago
If a browser is too old to send either the Sec-Fetch-Site header or the Origin header, it will probably ignore Referrer-Policy and always set the Referer header, which contains the origin. So I wonder why the author didn't consider falling back to the Referer header, instead of relying on an unrelated feature like TLS 1.3. Checking the referrer on dangerous (POST) requests was indeed considered one way to block CSRF back in the day. Assuming all your pages are on the same https origin, is there an edge case that affects Referer but not the Origin header?
- nchmy 1y ago
  Caniuse.com shows both origin and referer headers have 96.3% support, with Sec-Fetch-Site not far behind at 94.2. So it's probably a moot point. Ive read in various places though that referer has all sorts of issues, gotchas etc such that it isn't really a reliable way of doing this. https://security.stackexchange.com/questions/158045/is-checking-the-referer-and-origin-headers-enough-to-prevent-csrf-provided-that https://security.stackexchange.com/questions/158045/is-check...
  - kijin 1y ago
    Caniuse.com looks wrong in this case. It marks old versions of Internet Explorer and Android browser as either unknown or not supporting Referer, when in fact they only lacked support for hiding the Referer in potentially insecure situations. That's the point I was trying to make above. Even old browsers send it, even when they shouldn't. This behavior is uncontrollable, even by potential attackers. A missing Referer header probably doesn't mean much one way or another. But you can at least block requests with Referer pointing to URLs outside of your origin. This fallback would seem preferable to the fail-open policy described in the article (request always allowed if neither Sec-Fetch-Site nor Origin headers are present).

by nchmy 1y ago

anal_reactor 1y ago

From business perspective it makes a lot of sense to just drop that bottom 5%. Actually, many businesses support Chrome only, they don't even support Firefox. Technological counterargument though is that you should allow people to tinker and do weird shit. Once upon a time tech wasn't about maximizing stock value, it was about getting Russian game crack to work, and making Lora's boobs bigger. Allowing weird shit is a way to respect the roots of modern tech, and allow hobbyists to tinker.

nchmy 1y ago
Thanks for confirming. I don't know that it has to be framed as a "business perspective" though. I'm a solo dev for a non-profit project, so ignoring the 5% is just a matter of pragmatism. I most defintiely do not care about tinkerers, and in fact would generally classify them as something akin to attackers. I just want to allow as many people to use the app as possible, while keeping things simple and secure.
cryptonym 1y ago
Empathy and accessibility. Does it make sense to have a ramp in front of your shop for < 5% customers?
- nchmy 1y ago
  My question, though, is who are the 5% of users in this case who are using some arcane browsers? Surely that's largely a choice, physical disabilities are not. It doesn't seem unreasonable to say to those folks "were evidently not using the same web"
  - littlestymaar 1y ago
    It's not comparable to a physical disability byt gatekeeping the people who just don't want to be tracked all day by Google doesn't sounds right to me though.
    - nchmy 1y ago
      There's plenty of other chromium browsers - Vivaldi seems to do a good job in this regard. Also, Firefox exists, though they don't seem to care about privacy much anymore either. And, of course, safari, which is terrible in most regards
      - littlestymaar 1y ago
        > There's plenty of other chromium browsers - Vivaldi seems to do a good job in this regard. Being chromium derivatives, they don't really have a say in what's included in “their” browser though. > Also, Firefox exists Well, you disregarded is as “arcane browser” right above.
        nchmy 1y ago
        In what way did I call Firefox arcane? Firefox generally has better support for web features than safari.
        littlestymaar 1y ago
        It has less than 5% market share left…
wongarsu 1y ago
For a lot of businesses, 5% of revenue is a lot more than the cost of supporting older browsers What shifts the discussion a bit is that many of the bottom 5% aren't lost customers. If your website doesn't work on my minority browser, smart TV or PS Vita I might be willing to just try it in Chrome instead

johannes1234321 1y ago

Those 5% are probably a wild collection of devices. TVs with embedded Browsers, old phones and other computers elsewhere. As example: my late grandfather of 100 years took records of his stamp collection in Excel. He used the computer for Wikipedia as well, but we didn't upgrade ist as he was comfortable, but upgrading to later Windows to ruin newer browser would have been too much of a change and rather made him stop doing what brought him fun. The router etc blocked worst places frequent backups allowed restore, thus actual risk low. Anecdote aside: there are tons of those machines all over. And then another big one: bots claiming to be something which they aren't.

veeti 1y ago
There are a lot of people happily browsing away on unsupported Apple devices that don't get any more Safari updates. Lot of strange webkit edge cases to be found that don't exist in any other browser.
- nchmy 1y ago
  Apparently less than 1.5% of global internet users are on versions of safari that don't support Sec-Fetch-Site.
  - saurik 1y ago
    That's a lot of people...

kijin 1y ago

If a browser is too old to send either the Sec-Fetch-Site header or the Origin header, it will probably ignore Referrer-Policy and always set the Referer header, which contains the origin. So I wonder why the author didn't consider falling back to the Referer header, instead of relying on an unrelated feature like TLS 1.3. Checking the referrer on dangerous (POST) requests was indeed considered one way to block CSRF back in the day. Assuming all your pages are on the same https origin, is there an edge case that affects Referer but not the Origin header?

nchmy 1y ago
Caniuse.com shows both origin and referer headers have 96.3% support, with Sec-Fetch-Site not far behind at 94.2. So it's probably a moot point. Ive read in various places though that referer has all sorts of issues, gotchas etc such that it isn't really a reliable way of doing this. https://security.stackexchange.com/questions/158045/is-checking-the-referer-and-origin-headers-enough-to-prevent-csrf-provided-that https://security.stackexchange.com/questions/158045/is-check...
- kijin 1y ago
  Caniuse.com looks wrong in this case. It marks old versions of Internet Explorer and Android browser as either unknown or not supporting Referer, when in fact they only lacked support for hiding the Referer in potentially insecure situations. That's the point I was trying to make above. Even old browsers send it, even when they shouldn't. This behavior is uncontrollable, even by potential attackers. A missing Referer header probably doesn't mean much one way or another. But you can at least block requests with Referer pointing to URLs outside of your origin. This fallback would seem preferable to the fail-open policy described in the article (request always allowed if neither Sec-Fetch-Site nor Origin headers are present).