5 ms·
That's actually not always enough. For example, to fix this login CSRF on HN, you need a per-visitor secret an attacker can't read (like a cookie) plus a form v
by kogir 11y ago
That's actually not always enough. For example, to fix this login CSRF on HN, you need a per-visitor secret an attacker can't read (like a cookie) plus a form value based on that secret. Note it can't be tied to the user account, because the visitor hasn't logged in yet.
A random CSRF token on a login form is easily defeated - the attacker just requests a valid one and uses it when submitting the CSRF form.
- jonny_eh 11y ago> the attacker just requests a valid one How?
- kogir 11y agowget, curl, whatever. If I'm the attacker, I ask for a new one from my server each time and put the result in the form I serve your browser.
- r1ch 11y agoThe CSRF token should be tied to the user session, so you'd need to perform session fixation for that to work.
- kogir 11y agoThat works if you have sessions. HN doesn't.
- ubernostrum 11y agoTying to the session is a common practice but not necessary. You can do non-session-tied CSRF tokens so long as you don't expose your cookie.
- etjossem 11y agoCorrect. By "a valid token" I mean one that corresponds to the user session it was dispensed to.