Cross-site request forgery (CSRF or XSRF)

Cross-site request forgery (CSRF or XSRF)

Cross-site request forgery, known as CSRF, XSRF, Sea Surf or Session Riding is also one of famous web security vulnerability which facilitates attacker to gain over fully access victims’ account when the user logged in particular account like Online Banking, otherwise can define as it attacks a web application in which they’re currently authenticated. The previous article I wrote about the XSS attack that is also a famous attack.

In this case, the attacker does not want the victim’s data instead of he does want to victims realtime activities (state change requests) such as “changing passwords”, “fund transfers” since attacker no way to see the response of the requests. With the help of social engineering, the attacker will be able to send malicious link or data to the victim’s web browser which convince the victim sending a forged request to a server. When the time of attacking the server can not distinguish what is the legitimate request or what is the forged request. Before sending a forged request attacker has a better understanding of the structure of the targeted application.

CSRF | XSRF | Attack | Cross Site | Request | Forgery

How does it work

Let’s try to understand how does Cross-site request forgery work using the above image. The user is trying to send funds using his online banking option, at that time he notices there is an image or link it indicates some useful message. Here I used “How to make money”, sometimes it can be gossip or something which is sent by an attacker. Then the user induces to click it. Once he clicks it will execute malicious content behind the sense. In the first paragraph, I mentioned the attacker should know about the structure of the target application. So he creates an exact forge request because now he can access the victim user’s cookie, session, IP. After he sends the forged request with his account details, Then he unintentionally sends money to the attacker’s account but the bank end it is a legitimate request.

Simulation of how does it work

GET method

Pashan is transferring money to Bhanuka using an unsecured bank’s online web portal.

GET https://unsecuredbank.com/transfer?account=Bhanuka&amount=$100 HTTP/1.1

In this case attacker can easily change the value in URL as below

GET https://unsecuredbank.com/transfer?account=Attacker&amount=$100 HTTP/1.1

He can execute this link behind the hyperlink. Example: I used above “How to Make Online Money”

<a href="https://unsecuredbank.com/transfer?account=Attacker&amount=$100">How to Make online Money</a>

POST method

If the bank is using the attacker can not execute his malicious code using <a> tag, instead of that he can write a code to open a new tab once he clicks the malicious link or image. He can write a simple code as below.

<html>
  <body>
    <form action="https://unsecuredbank.com/transfer" method="POST">
      <input type="hidden" name="account" value="Attacker" />
      <input type="hidden" name="amount" value="100$" />
    </form>
    <script>
      document.forms[0].submit();
    </script>
  </body>
</html>

This is the basic idea of the nature of the attack, but it is not as easy as above. In my next article, I will demonstrate how to simulate this exactly.

How to find CSRF vulnerabilities in the application

In my experience, I used some commercial tools like Appspider (for dynamic code analysis) and Checkmarx (for static code analysis) to identify the vulnerabilities in my applications. Please read them on how to create a scheduler to be scanned your applications.