3 ms·

This is "not allowing cross site at all" so, technically it's not "request forgery" protection. Yes, this is very semantic, but, CSRF is a vulnerability introd

by nhumrich 10mo ago

This is "not allowing cross site at all" so, technically it's not "request forgery" protection. Yes, this is very semantic, but, CSRF is a vulnerability introduced by enabling CS and CORS. So, technically, same-site cookies are not "protection" against CSRF.

hn_throwaway_99 10mo ago
I don't understand your distinction at all. I may not quite grok your meaning here, but CORS is usually discussed in the context of allowing cross-origin AJAX calls. But cross origin form posts are and have always been permitted, and are the main route by which CSRF vulnerabilities arise. Nothing on the client or server needs to be enabled to allow these form posts. Furthermore, the approach detailed in the article simply has the server block requests if they are cross site/origin requests, so I'm not sure what the semantic difference is.
- true_religion 10mo ago
  Yeah, CORS is not a safety mechanism. It’s a procedure of loosening the default safety mechanism of not sharing any response data from a cross site request with client side JavaScript.
nchmy 10mo ago
Cs and cors have nothing to do with csrf... Though, yes, neither does same-site
- nchmy 10mo ago
  I don't know why I said same-site cookies have nothing to do with csrf. They can be helpful as defense in depth, but not primary defense.
  - hn_throwaway_99 10mo ago
    I haven't seen any proposed attack vectors where they are insufficient primary defense when using SameSite Lax as long as you don't do any sensitive state change operations on non-mutative methods like GET. I feel like people are just parroting the OWASP "they're just defense in depth!" line without understanding what the actual underlying vulnerabilities are, namely: 1. If you're performing a sensitive operation on a GET, you're in trouble. But I think that is a bigger problem and you shouldn't do that. 2. If a user is on a particularly old browser, but these days SameSite support has been out on all major browsers for nearly a decade so I think that point is moot. The problem I have with the "it's just defense in depth" line is people don't really understand how it protects against any underlying vulnerabilities. In that case, CSRF tokens add complexity without actually making you any safer. I'd be happy to learn why my thinking is incorrect, i.e. where there's a vulnerability lurking that I'm not thinking of if you use SameSite Lax and only perform state changes on mutable methods.

hn_throwaway_99 10mo ago

I don't understand your distinction at all. I may not quite grok your meaning here, but CORS is usually discussed in the context of allowing cross-origin AJAX calls. But cross origin form posts are and have always been permitted, and are the main route by which CSRF vulnerabilities arise. Nothing on the client or server needs to be enabled to allow these form posts. Furthermore, the approach detailed in the article simply has the server block requests if they are cross site/origin requests, so I'm not sure what the semantic difference is.

true_religion 10mo ago
Yeah, CORS is not a safety mechanism. It’s a procedure of loosening the default safety mechanism of not sharing any response data from a cross site request with client side JavaScript.

nchmy 10mo ago

Cs and cors have nothing to do with csrf... Though, yes, neither does same-site

nchmy 10mo ago
I don't know why I said same-site cookies have nothing to do with csrf. They can be helpful as defense in depth, but not primary defense.
- hn_throwaway_99 10mo ago
  I haven't seen any proposed attack vectors where they are insufficient primary defense when using SameSite Lax as long as you don't do any sensitive state change operations on non-mutative methods like GET. I feel like people are just parroting the OWASP "they're just defense in depth!" line without understanding what the actual underlying vulnerabilities are, namely: 1. If you're performing a sensitive operation on a GET, you're in trouble. But I think that is a bigger problem and you shouldn't do that. 2. If a user is on a particularly old browser, but these days SameSite support has been out on all major browsers for nearly a decade so I think that point is moot. The problem I have with the "it's just defense in depth" line is people don't really understand how it protects against any underlying vulnerabilities. In that case, CSRF tokens add complexity without actually making you any safer. I'd be happy to learn why my thinking is incorrect, i.e. where there's a vulnerability lurking that I'm not thinking of if you use SameSite Lax and only perform state changes on mutable methods.