I have a question about csrf mitigation. The literature recommends to use a token on each page, which must be submitted along with any forms - this token must be valid for the transaction to occur.
How does having a token on the page protect from csrf? Can't I just make a http GET request, parse the token from the html, then use that token in a POST (within some time limit) since http is stateless?
Yes, you can. But that's not CSRF. CSRF is when I sneakily get you to perform an action that you didn't intend on carrying out. Example, what if you were logged into a particular website and I tricked you into clicking on a link like so:
You click on the link and to your dismay, you end up deleting a resource that you didn't want to delete. Or what if I got you to view an image like so (look at the src):
<img src="http://test.com/action.php?delete_id=324" />
However, what if action.php required a token? Then I (the attacker), would have to try and figure out what token you're currently using.
http://test.com/action.php?delete_id=324&token=89723gdeHDdhipd823igb9bd87309287bhdebvtaGY
Otherwise, the action will not take place and the request will be rejected (or at least it should be).
CSRF protection is not designed to prevent DOM parses or bots from getting the token and submitting a form. A CSRF is when a malicious site submits a form or request to the target site with the intention of changing some setting or performing an action on the logged in user's account.
What happens is when the form is submitted, the user's cookies for the target site are sent with the request and so without a anti-CSRF token, the malicious site could affect the user's account or perform some action on the target site. There is no way for the malicious site to get the user's specific anti-CSRF token and so the attempt will fail.
