4 ms·
This vulnerability would appear to be mitigated by using a CSRF secret in a server-side session rather than solely cookie based. For example, Cookie: SHA1(salt
by Osiris 11y ago
This vulnerability would appear to be mitigated by using a CSRF secret in a server-side session rather than solely cookie based.
For example, Cookie: SHA1(salt + secret), then CSRF-TOKEN header/value is taken, the salt extracted, hashed against the server-side secret and compared.
- xrstf 11y agoWhat's the advantage of still having the cookie with some value in it when we use a random token as a hidden form value plus this token being stored on the server? Your suggestion seems overly complex to me, so maybe I'm missing an attack vector that can be mitigated by throwing salts, hashing and a cookie at the issue.
- Osiris 11y agoWe serve static HTML and site is driven entirely by JavaScript with all communication with the server being solely through a REST API. There's no mechanism to add a value to a form field, thus we use a cookie. Really the difference is that you compare the user's response to a known value on the server rather than two values in the same request body which cannot be independently verified.
- amenghra 11y agoHow do you bind the value stored on the server to the logged-in user? If it's a global value (same for all users), you aren't correctly protecting against CSRF. If it's tied to the logged-in user, storing a value is essentially the same as deriving a value using HMAC (or some other one way function).
- xrstf 11y agoThe CSRF token is generated on login and then stored in the user's session. We accept the risk of not having a per-form token for pure developer/user convenience reasons.
- amenghra 11y agoThis is exactly what the parent suggests doing. Keep in mind that if you don't change the client's view of the token on every page load (using some kind of salt), you are potentially vulnerable to CRIME/BEAST.
- ejcx 11y agoThere are a TON of different CSRF schemes and once you have billions of requests per day, storing and distributing each CSRF token for each user can be a large burden. Most advanced CSRF schemes use some crypto primitives in a manner like client-side sessions work (Enc+Mac on the server, give token to user, Validate Integrity+Dec on the server when you get it back), or HMAC some user meta-data. This allows you to distribute the key and then any server with the key can validate the token without needing to know the token in advance. I've written a blog post about a bunch of types of CSRF schemes and their pros and cons, but never published it. Is this interesting enough for me to publish?
- xrstf 11y agoIt is. I want to finally understand why and how I can secure a login form against CSRF (i.e. when I don't yet have a session for the visitor).
- Osiris 11y agoHow we do it is a little wonky. Our web app calls GET /login which returns a CSRF cookie and an anonymous session cookie and an object that says there's no active session. The app then uses that CSRF token to POST to /login. Once the auth is successful, the anonymous session is destroyed and a new CSRF secret is generated on the authenticated session.
- ZoFreX 11y ago> I've written a blog post about a bunch of types of CSRF schemes and their pros and cons, but never published it. Is this interesting enough for me to publish? Definitely. Having looked myself, I can tell you there aren't many resources online that get this right.
- amenghra 11y agoSolely cookie based CSRF is the only way to do logged-out csrf. Once you are logged-in, you want to do session based to prevent a MITM-over-http from doing a CSRF on the https connection. HSTS partially prevents the MITM-over-http, but not 100% the person doing the MITM potentially controls the clock (NTP is unauthenticated). Unless you do HSTS by whitelisting the domain in the browser. Security is hard :(
- ZoFreX 11y agoLogged-out users could have sessions too, potentially. (Although logged out users don't need CSRF protection on many websites)
- amenghra 11y agoLogged-out csrf is an issue if you are serving as an oauth provider. There might be other use cases that I haven't thought about. I would ere on the side of precaution and implement logged-out csrf. If you create a session for the logged-out user, you must be careful about not recycling the same session once logged in or you expose yourself to session fixation. http://stephensclafani.com/2011/04/06/oauth-2-0-csrf-vulnerability/ http://stephensclafani.com/2011/04/06/oauth-2-0-csrf-vulnera... and http://homakov.blogspot.com/2014/01/two-severe-wontfix-vulnerabilities-in.html http://homakov.blogspot.com/2014/01/two-severe-wontfix-vulne... explain the issue pretty well.