1

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?

Anders
  • 65,582
  • 24
  • 185
  • 221
Tailer
  • 155
  • 6
  • 1
    This behavior is already prevented by Same Origin Policy. see https://security.stackexchange.com/a/157065/21234 – Shurmajee Oct 29 '18 at 09:13

1 Answers1

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.

Joseph Sible-Reinstate Monica
  • 7,519
  • 3
  • 24
  • 35
  • can you elaborate on "the browser's built-in protections"? – Tailer Oct 28 '18 at 18:33
  • I think a simple XHR request can take the token from sendmoney.php – Tailer Oct 28 '18 at 18:36
  • @Adam read about CORS: https://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. – Joseph Sible-Reinstate Monica Oct 28 '18 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 Oct 28 '18 at 21:41
  • @CBHacking Yeah, I used to apply the same-origin policy to secure my server. – Tailer Oct 29 '18 at 19:17
  • @Adam that's not something you apply. The browser just always enforces that. – Joseph Sible-Reinstate Monica Oct 29 '18 at 20:26
  • @JosephSible even without adding Access-Control-Allow-Origin', 'SAMEORIGIN' x-frame-options', 'SAMEORIGIN' headers? – Tailer Oct 29 '18 at 20:38
  • @Adam Yes. Despite sounding similar, that's unrelated to the same-origin policy as we're discussing here. – Joseph Sible-Reinstate Monica Oct 29 '18 at 20:40
  • I've removed x-frame-options', 'SAMEORIGIN' from my headers and tried to make an CSRF attack and it did work. – Tailer Oct 29 '18 at 20:42
  • @Adam then something is seriously wrong with your website's security. That by itself shouldn't make CSRF possible. – Joseph Sible-Reinstate Monica Oct 29 '18 at 21:10
  • X-Frame-Options mitigates clickjacking, which is an area that SOP does not cover by default. It's an important header to have on most web apps. Access-Control-* headers are for CORS, and should only be sent if you need to weaken the same-origin policy (that's what CORS is, a way to controllably make holes in SOP). In fact, misconfigured CORS is one of the few ways that you could be vulnerable to the "two-stage CSRF" that you described. Done wrong, CORS can mostly turn off SOP. – CBHacking Oct 30 '18 at 06:33