Assume that we are creating a CSRF token and inject it in a form on the page sendmoney.php. What prevents the attacker from sending a request to sendmoney.php to get the CSRF token and then submitting the form?

Any ideas how to prevent two-stage CSRF attack?


1 Answer 1


There are two choices for the attacker to make the request to sendmoney.php to generate the token. Case 1: the attacker does it from the victim's computer using the victim's credentials. In this case, the browser's built-in protections will prevent the attacker from reading the generated token, so they can't send it along with the form. Case 2: the attacker does it from their own computer using their own credentials. In this case, the token won't be valid if submitted with a form bearing the victim's credentials.

  • can you elaborate on "the browser's built-in protections"?
    – Tailer
    Commented Oct 28, 2018 at 18:33
  • I think a simple XHR request can take the token from sendmoney.php
    – Tailer
    Commented Oct 28, 2018 at 18:36
  • @Adam read about CORS: developer.mozilla.org/en-US/docs/Web/HTTP/CORS Basically, one site can't use XHR to read another site's content without its permission. Commented Oct 28, 2018 at 18:37
  • 3
    @Adam More generally, read about the Same-Origin Policy. It's basically the critical factor that makes all web security even possible. Without SOP, every web page could read the full contents of, and control the behavior of, every other web page; you could never safely have a browser that was logged into any one site and interacting with any other site. Obviously, that's not how the real world is (thank goodness). XHR respects SOP; in fact, the original XHR (pre-CORS) didn't even allow cross-origin requests at all.
    – CBHacking
    Commented Oct 28, 2018 at 21:41
  • @CBHacking Yeah, I used to apply the same-origin policy to secure my server.
    – Tailer
    Commented Oct 29, 2018 at 19:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .