CSRF Synchronizer Token Protection

What is CSRF

Cross-Site Request Forgery (CSRF) is associate degree attack that forces associate degree user to execute unwanted actions on an online application within which they are presently genuine. CSRF attacks specifically target state-changing requests, not larceny of knowledge, since the wrongdoer has no way to see the response to the solid request.

How is using Synchronizer Token Pattern to prevent CSRF 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

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.

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.

 

Implementation of  synchronizer token pattern

1. In your authentication servlet, once successful authentication, set a at random generated token as a session attribute.in here i used php to generate it.

     2.Include the same session token in all your forms.

    3.Whenever a form is submitted verify the form value of the token with the session    token value. It should be equal to verify there no forgery. You can do this verification in a servlet filter

index.php

 

server.php

 

Download demo code       

 

https://stackoverflow.com/questions/16049721/how-is-using-synchronizer-token-pattern-to-prevent-csrf-safe?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa