3 ms·
To mitigate CSRF on a form, send the user a randomly generated, long, unique token every time the form is rendered. Put it in a hidden input. Your server must
by etjossem 11y ago
To mitigate CSRF on a form, send the user a randomly generated, long, unique token every time the form is rendered. Put it in a hidden input.
Your server must expect the POST to answer back with a valid csrf token. Otherwise, the request results in an error and doesn't go through. Attacker pages won't know anything about the csrf token, so they can't forge the form.
- kogir 11y agoThat'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.