Cross-Site Request Forgery (CSRF)

OWASP Top 10 - A8

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.

Example of a Cross-Site Request Forgery attack

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 (target website).

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

        <form target="frame" id="formid" action="" method="post">
          <input type="hidden"
          <input type="hidden"
           <input type="hidden"
          <input type="hidden"
              value="EVIL ACCOUNT"/>
          <input type="submit"


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

<img src="">

How to prevent Cross-Site Request Forgery (CSRF)

How do I prevent Cross-Site Request Forgery attacks?

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 adds an aleatory token to each link or form existing within the application. It makes extremely difficult to implement an CSRF attack because the attacker does not know which is the 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.