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.
Correct. By "a valid token" I mean one that corresponds to the user session it was dispensed to.
> 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.
Re:Hacker News CSRF Vulnerability
by ubernostrum on Thursday February 25, 2016 @09:10PM
(#11179407)
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.
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.