CSRF

What is Cross-Site Request Forgery (CSRF)?

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

OWASP

Cross-Site Request Forgery attack Example

In order for perform a Cross-Site Request Forgery attack, the victim must be authenticated with the target website. The attacker includes a script in a third-party website that the victim visits. When the victim visits that website, the script will be executed without the victim noticing. For example, in a car forum, an attacker posts a message which contains a script which performs transfers in the victim's bank account (target website).

<div style="display:none;">
<iframe id="frame" name="frame"></iframe>

<form target="frame" id="formid" action="http://www.mybank.com/transfer" method="post">
  <input type="hidden"
      name="toAccount"
      value="55555555555555555555"/>
  <input type="hidden"
      name="amount"
      value="666"/>
   <input type="hidden"
      name="fee"
      value="5.0"/>
  <input type="hidden"
      name="description"
      value="EVIL ACCOUNT"/>
  <input type="submit"
      value="View"/>
</form>

<script>
    document.getElementById("formid").submit();
</script>
</div>

Even if HTTP POST is disabled, the same attack could be performed with HTTP GET request.

<img src="http://www.mybank.com/transfer?toAccount=555555555&amount=1000000&fee=5&description=EVIL">

How to prevent Cross-Site Request Forgery (CSRF)

Use Synchronizer Token Pattern

Custom Token

A token must be added to the request for it to complete successfully. This token is generated when the user first creates their session and is stored as session data on the server (not as a cookie).

Use Hdiv

Risk Covered

Hdiv prevents CSRF attacks by inserting a random token in links and forms

Hdiv adds an aleatory token to each link or form existing within the application. This makes it extremely difficult to implement a CSRF attack as the attacker does not know the token value.

In order to offer an extreme security level Hdiv does not use an aleatory token per session and creates a new token for each requested page. Even the token used by links and forms within the same page are different avoiding the reuse of link tokens to exploit a web form.