How is using Synchronizer Token Pattern to prevent CSRF safe?

javascript security web csrf
Juliet picture Juliet · Apr 17, 2013 · Viewed 13.4k times · Source

I have been reading about using a synchronizer token pattern to prevent CSRF (CSRF meaning Cross-site request forgery.), and I don't understand how it actually safe.

Let's say I have a fake bank site fakebank.com with two urls:

  • fakebank.com/withdrawForm.html - a GET request which displays the withdraw money form
  • fakebank.com/doWithdraw - POST to this url to do the withdraw

My understanding of the security flaw is that maliciousSite.com can spoof a POST request to fakebank.com/doWithdraw, and if you're currently logged in to fakebank, the POST will be successful.

Let's say we implement a Synchronizer Token Pattern which will embed a secret code on fakebank.com/withdrawForm.html. Can't maliciousSite.com just spoof a GET request for that form, parse the html result, get the token, and then create the POST request with that token?

This is assuming fakebank.com isn't checking HTTP Referrer or Origin or maliciousSite.com is successfully spoofing that the Referrer/Origin is fakebank.com.

Answer

Freedom_Ben picture Freedom_Ben · Apr 17, 2013

The reason why this is secure, and maliciousSite.com cannot simply do a GET, steal the token, and then do a POST is that the request is done by the user's browser, not by the server at maliciousSite.com. All data returned from fakebank.com is returned to the user's browser, not to the server at maliciousSite.com. If maliciousSite.com does perform a GET to retrieve a token, it will be a different token than was issued to the user. maliciousSite.com cannot set this cookie into the user's browser to be submitted to fakebank.com because of same-domain restrictions.

The CSRF POST attack works by tricking the user's browser into requesting fakebank.com/withdrawForm.html directly using a properly formed POST request. The server at fakebank.com happily executes the requested POST, thus transferring funds using the parameters supplied in the POST body (which include a destination account belonging to the attacker that was put there by maliciousSite.com). The server at maliciousSite.com doesn't need to see the data returned, because the action has been taken (unless fakebank.com uses these CSRF tokens, which the maliciousSite.com can't possibly know unless it has been divulged in some way. It can't ask for it). If fakebank.com is using CSRF tokens, then maliciousSite.com will submit a POST request that is missing the token, thus indicating a potential CSRF attack in progress.

Vulnerabilities of this method include using a CSRF token that is not kept sufficiently secret and is divulged in some way. Also, if the CSRF token is not sufficiently random, then maliciousSite.com might be able to guess it. Also, if there is a weakness in the browser's enforcement of same domain policy, this could be exploited. Generally speaking, modern browsers are not vulnerable to this.

Please let me know if this is an insufficient explanation and I'll attempt to articulate it a little better for you.

Related questions

SecurityError: Blocked a frame with origin from accessing a cross-origin frame

I am loading an <iframe> in my HTML page and trying to access the elements within it using Javascript, but when I try to execute my code, I get the following error: SecurityError: Blocked a frame with origin "…

Read More
Why does Google prepend while(1); to their JSON responses?

Why does Google prepend while(1); to their (private) JSON responses? For example, here's a response while turning a calendar on and off in Google Calendar: while (1); [ ['u', [ ['smsSentFlag', 'false'], ['hideInvitations', 'false'], ['remindOnRespondedEventsOnly', 'true'], ['hideInvitations_remindOnRespondedEventsOnly', 'false_true'], ['Calendar ID stripped …

Read More
Why is using the JavaScript eval function a bad idea?

The eval function is a powerful and easy way to dynamically generate code, so what are the caveats?

Read More