Exploiting CSRF

In most cases, an attacker would use something that would automatically send a request as soon as the attacker views that particular webpage.

An attacker would post a message on the community discussion board, using the following code 

<img src=”http://target.com/status.php?updatestatus=I+just+got+hacked” width=”0” height=”0” >

In this case, the following HTTP Header would be sent to the server,

GET / status.php?updatestatus=I+just+got+hacked HTTP/1.1

Host: target.com

Cookie: PHPSESSID=123456789

This HTTP request is as similar is as it came from the original target.com domain, even if it is coming from the attacker’s community board. The cookie value or the PHPSESSID is the cookie used by the target.com domain to keep the user authenticated. 

Now, whoever would come to the community discussion, the image would automatically load, and the request to the web application would be sent on behalf of the user (in case the user is logged in). In this case, the web application, won’t be able to know, that this request is actually coming from an image.

Another way of doing this is through form with hidden inputs.

<form name=”something” method=”post”

action=”http://mysafebankwebsite.com/transfer>

<input type=”hidden” name=”fromaccount” value=”InnocentVictim”>

<input type=”hidden” name=”toaccount” value=”NotinnocentAttacker”>

<input type=”hidden” name=”moneyamount” value=”20000”>

</form>

This could also be demonstrated more perfectly with the following image from

OWASP:

Jeremiah Grossman in his talk “Hacking Intranet from Outside” even showed how it is possible to make a user change his router password without their consent.

Preventing CSRF Attacks 

The most common way of preventing this is increasing a secret value or hidden parameter with session-specific values while performing such requests.

As a result of the Same-origin policy, the attacker won’t be able to get this value as read- access to cross-domain documents would be restricted. But that solution is not that effective in preventive Cross-Site Request Forgeries.

The best use approach is by relying on Synchronizer Token Pattern. The synchronizer token pattern requires the generating of random “challenge” tokens that are associated with the user’s current session.

These challenge tokens are inserted within the HTML forms and links associated with sensitive server-side operations. When the user wishes to invoke these sensitive operations, the HTTP request should include this challenge token.

The CSRF tokens will be randomly generated, so that, they won’t be guessed by the attacker. The token will be specific for each session. After the initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires.

Another useful solution to CSRF is double authentication. This includes the user entering his/her password again while performing an important operation from his account. Also, the referrer should be checked to be valid in order to make an important action on the website.