If someone is using my website, and they close a tab, then the CSRF token is now gone on the client side, because it was embedded on the page. If that same person opens the site in a new tab, the page will be delivered with the CSRF token in a meta tag. They didn't need to send the CSRF token for the page to be delivered, because the CSRF token was gone.

If a malicious website was somehow able to send my website a cross origin request, then what would stop it from simply requesting a page and then scanning through the response data for the CSRF token?

  • Because the browser should not allows to scan the response of a cross origin request (otherwise, it would be able to also scan the HTTP response headers and get the Cookie it contains) It's the Same-Origin policy – Xenos Jul 19 '18 at 12:30
  • But if the malicious site can't read cross-origin response data then what is the purpose of the token anyways? – csrftokens Jul 19 '18 at 12:34
  • 1
    @csrftokens even though it cannot read the response data, a malicious site can still submit a form to your site. Which is what the CSRF prevents. – Daniel A Jul 19 '18 at 12:39
  • The purpose is to avoid the server processing the request. When you do a CSRF attack on /user/delete?id=15, the response does not matter: the goal is to make the victim request this page and make the server delete that user. Reading the response is not required to do that. The CSRF token is not known by the attacker's code, and must not be automatically part of the victim's request. Therefore, server cannot find it in the request, and refuses to process it. – Xenos Jul 19 '18 at 12:40

They are safe because of the Same-Origin Policy: an origin A (site.com) cannot read a resource from another origin (other.fr) unless you've whitelisted that using Access-Control-Allow-Origin.

In case of basic CSRF, the attack does not consist in reading the response, but it consists in tricking the server to do an action that was fired by a victim user without this victim being aware of it.

So in basic CSRF, the victim has a token that attacker cannot know (Same-Origin policy prevents it). When victim requests something from the server (/user/delete?id=15 but in real world, do not pass the ID by GET but by POST since it's changing server's state), then the server will check if that token is present and valid. If not (because it's fired by the attacker, which cannot know the token) then the server refuses to process it and the user 15 is not deleted. When token is here and valid, the server deletes the user and returns the response (that one can still not be read by attacker).

So Same-Origin prevents attacker from reading the response, while CSRF token prevents the server from processing an unwilled request.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.