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
  • 64,406
  • 24
  • 178
  • 215
Adam
  • 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,110
  • 3
  • 21
  • 35
  • can you elaborate on "the browser's built-in protections"? – Adam Oct 28 '18 at 18:33
  • I think a simple XHR request can take the token from `sendmoney.php` – Adam 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](https://developer.mozilla.org/en-US/docs/Web/Security/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. – Adam 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? – Adam 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. – Adam 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](https://en.wikipedia.org/wiki/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](https://developer.mozilla.org/en-US/docs/Web/HTTP/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