Hacker News Reader

Comment by hatsunearu | Hacker News Reader

I'm not too well versed on netsec; how do you fix something like this?

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.

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.

> the attacker just requests a valid one

How?

wget, 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.

The CSRF token should be tied to the user session, so you'd need to perform session fixation for that to work.

That works if you have sessions. HN doesn't.

Tying 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.

Correct. By "a valid token" I mean one that corresponds to the user session it was dispensed to.

Reply on news.ycombinator.com