4 ms·

Sane web frameworks already solve this in some way, as long as you don't mutate any sensitive state in non-POST, so this is really a solution in search of a pro

by Eridrus 10y ago

Sane web frameworks already solve this in some way, as long as you don't mutate any sensitive state in non-POST, so this is really a solution in search of a problem.

bitexploder 10y ago
In my experience until developers have to work extremely hard to create a security bug, disabling numerous defaults, it is never going to be a "solved" problem. Prepared statements fix SQLi. Encoding HTML entities on output fixes XSS. Etc. etc. Even SPA frameworks that default to encoding entities get hit with XSS. Unless it is completely stamped out by default or simply no longer possible I encourage solutions like this. And this is mostly just an XSS problem, but XSS that leverages simple CSRF vulnerable end points is still a problem. To be safer you now need 3 flags on a cookie (HttpOnly, secure, and SameSite). This is a pain for developers and almost ensures weird edge case CSRF type vulns will still creep up on occasion. Similar to how memory corruption mitigations often force an exploiter to combine multiple vulns to achieve the effect of one old school vuln, this raises the bar, but does not eliminate the possibility.
- Eridrus 10y ago
  No-one is going to set a strict SameSite cookie, it just breaks too much, it's the same level of hubris as thinking developers are going to care about CSP. It just breaks too much shit. So we're left with Lax SameSite cookies, which is pretty much the same as what existing web frameworks do. The best you can say is that this is less likely to have bugs in the implementation.
  - mathw 10y ago
    I'd say surely banks will use this for their online banking systems. Then I wonder, because of some of the delightful vulnerabilities I've heard about. So I'll just say banks certainly should use Strict SameSite cookies, and in fact they seem designed to suit banking workloads (especially as banks don't usually offer persistent logins, because that's too dangerous).
pg314 10y ago
Many frameworks have had and probably still have bugs in their CSRF handling. E.g. a quick scan on the Django security issues [1] shows 5 issues involving CSRF, the latest one in September 2016. [1] https://docs.djangoproject.com/en/1.10/releases/security/ https://docs.djangoproject.com/en/1.10/releases/security/
- Eridrus 10y ago
  Sure, the fact that browser vendors have better security sense than framework developers is a plus, but it's not going to be an improvement on the rest. Most people aren't getting hacked via an obscure Google Analytics + Django CSRF interaction. Not people are getting hacked via client-side webapp vulns of any sort anyway.
- huxley 10y ago
  Note: 5 issues including advisories since 2008

by Eridrus 10y ago

Sane web frameworks already solve this in some way, as long as you don't mutate any sensitive state in non-POST, so this is really a solution in search of a problem.

bitexploder 10y ago

In my experience until developers have to work extremely hard to create a security bug, disabling numerous defaults, it is never going to be a "solved" problem. Prepared statements fix SQLi. Encoding HTML entities on output fixes XSS. Etc. etc. Even SPA frameworks that default to encoding entities get hit with XSS. Unless it is completely stamped out by default or simply no longer possible I encourage solutions like this. And this is mostly just an XSS problem, but XSS that leverages simple CSRF vulnerable end points is still a problem. To be safer you now need 3 flags on a cookie (HttpOnly, secure, and SameSite). This is a pain for developers and almost ensures weird edge case CSRF type vulns will still creep up on occasion. Similar to how memory corruption mitigations often force an exploiter to combine multiple vulns to achieve the effect of one old school vuln, this raises the bar, but does not eliminate the possibility.

Eridrus 10y ago
No-one is going to set a strict SameSite cookie, it just breaks too much, it's the same level of hubris as thinking developers are going to care about CSP. It just breaks too much shit. So we're left with Lax SameSite cookies, which is pretty much the same as what existing web frameworks do. The best you can say is that this is less likely to have bugs in the implementation.
- mathw 10y ago
  I'd say surely banks will use this for their online banking systems. Then I wonder, because of some of the delightful vulnerabilities I've heard about. So I'll just say banks certainly should use Strict SameSite cookies, and in fact they seem designed to suit banking workloads (especially as banks don't usually offer persistent logins, because that's too dangerous).

pg314 10y ago

Many frameworks have had and probably still have bugs in their CSRF handling. E.g. a quick scan on the Django security issues [1] shows 5 issues involving CSRF, the latest one in September 2016. [1] https://docs.djangoproject.com/en/1.10/releases/security/ https://docs.djangoproject.com/en/1.10/releases/security/

Eridrus 10y ago
Sure, the fact that browser vendors have better security sense than framework developers is a plus, but it's not going to be an improvement on the rest. Most people aren't getting hacked via an obscure Google Analytics + Django CSRF interaction. Not people are getting hacked via client-side webapp vulns of any sort anyway.
huxley 10y ago
Note: 5 issues including advisories since 2008