Cross Site Scripting (XSS)
In this article I am going to show you how to exploit Reflected XSS (Cross Site Scripting) vulnerability in DVWA web application (a vulnerable web application for enhancing hacking skills offline). Before we begin, let us know something about XSS like,
- What is XSS attack?
- What are the types of XSS attack?
- Why this vulnerability arises?
Let’s move towards our first question
What is XSS attack??
OWASP (Open Web Application Security Project an online community that produces freely-available articles, methodologies, documentation, tools, and technologies in the field of web app security) defines XSS as an injection attack in which an attacker tries to inject some malicious code in the website’s input field. This code is merely one or two line script written in any language that a web browser executes. Most importantly, in XSS attack an attacker tries to inject some HTML code or some JavaScript code in the input field of the website. The input field can be anywhere in the website’s page. The user gives his input using this input field. The input field can be a HTML form, Signup button, an http header like HOST, COOKIE, USER-AGENT, etc.
Even if an attacker can inject any client side code in the input field, but his main focus is on to inject such code that will give a popup on user’s browser screen. The popup is an alert box which proofs that the given website is vulnerable to an XSS attack. The universal and the most basic method to get a pop up window on browser screen is to include alert () function inside script tag (<script>…. </script>). So, whenever an attacker injects payload (a group of words & characters) <script> alert () </script> in any of the input field of the website it will pop up an alert box on the browser screen which confirms that the website is vulnerable to XSS attack. Let’s move towards our second question which is, what are the types of XSS attack.
What are the types of XSS attack?
There are three types of XSS attacks namely :-
- Reflected XSS
- Stored XSS
- DOM Based XSS
Let us understand the concept behind each types of attack
1. Reflected XSS
Reflected XSS occurs when the input supplied by the user reflects back in the browser window or inside page source of the web page. What does it mean? Let us understand it with an example, suppose I have entered some value let’s say thisisreflecting in the input field of the website, now open the source of the page by pressing CTRL+U and search for the string thisisreflecting in the page source. If this word (thisisreflecting) is reflected or present in the page source then that parameter which is accepting the input may be vulnerable to reflected XSS. Now, you can try the payload <script> alert() </script> in place of thisisreflecting in the same input field. If it is vulnerable it will give popup.
2. Stored XSS
Stored XSS occurs when the input supplied by the user is stored on the server side without performing proper sanitization. The storage place can be a database, a message forum, visitor log, comment field, etc. Instead of reflecting back immediately it may reflect back when you login in the website the next time. When you visit the vulnerable web page you will get pop up alert window. Stored XSS is more dangerous than reflected XSS because, it will harm to whole community by popping alert box on every user’s browser who visit the vulnerable page. The payload used in stored XSS is same as reflected XSS.
3. DOM Based XSS
DOM XSS stands for Document Object Model based Cross-Site Scripting. Here the vulnerability appears in the DOM instead of part of the HTML. It is different from the other two types of XSS in the way that in DOM based XSS user supplied input doesn’t reflect back in the source code but user can see the data in the DOM tree using CTRL+C and taking mouse pointer to the input field where he has entered his data and observing the DOM tree.
According to W3C – “The W3C Document Object Model (DOM) is a platform and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure, and style of a document.”
To exploit this vulnerability, an attacker tries to inject some JavaScript code in the Document Object Model. It has capability to dynamically modify html tags, CSS properties and content of HTML document. And hence, can be used to inject JavaScript code to get popup on screen.
Now we have discussed about the types of XSS attack, let us talk about, why this vulnerability arises?
Why XSS vulnerability arises?
XSS vulnerability occurs in those websites which take input from the user and while reflecting back in the browser they don’t perform any sanitization or content encoding. Sanitization means removing some unwanted characters like >, <, “,”, %, etc. from the input string. And encoding means changing bad characters to some other similar meaning characters including number and letters so that they will not reflect back in the same format as they were entered.
Now I will show you how you can exploit Reflected XSS vulnerability in DVWA application. Although, there are various ways to exploit Reflected XSS in Dvwa but we are going to cover most basic one. So let’s begin,
How to Exploit Reflected XSS in DVWA
Hacking Steps
These are the general steps which have to be followed every time while testing for reflected XSS on any website
- Firstly, input some unique string in the form field and submit it.
- Open page source by right click or by pressing
CTRL+Uand search the unique string in the Page Source. - Use
CTRL+Fto find the unique string which you have entered in step one. If the unique string reflects back in the browser screen or in the page source then the site may be vulnerable to Reflected XSS. - At last, fire the payload of XSS viz,
<script>alert()</script>and submit it to get further response in the browser. If the site is vulnerable you will get an alert box.
Now it’s time to demonstrate our attack on our vulnerable Web Application which is running on our localhost.
Login in your DVWA web app by default creds, username admin and password password. or use your own creds if you have created.
Low Security
We will begin from very basic level so set the security level to low and click submit.
Select Reflected XSS challenge on left button.
Input hackme [unique string ] in the input section and submit it as shown below.
Now, press CTRL+U to view page source and find our unique string which we have entered. It is present in the page source as shown below so this may be vulnerable to XSS attack.
Now type the payload <script> alert() </script> in the same field.
You can see a popup box below which confirms that it is vulnerable to reflected XSS and we have successfully exploited low level.
You can replace alert(“Hacked”) function withalert(document.cookie) in the above payload to get cookie of the logged in user on the victim browser. As can be shown below. Moreover, this cookie can be used to login in the same web app from other web browser which is called Session Hijacking attack.
Let us analyse the source code of low level and find how the application is accepting user input.
Line 1: Contains the function that will accept input from the user [$_GET ]
Line 2: Reflect back the input provided by the user exactly in the same way as it was entered in the input field inside <pre>..</pre> tag without performing any sanitization.
Explanation: As we can see that the input string is echoed back exactly in the same way as it is entered by the attacker, as a result the <script> tag in our payload also get reflected back without any filtering or any encoding. As we know that web browser has the capability to execute any tag which is passed to it that’s why we got an alert box on the screen after the execution of the alert() function inside <script> tag. <script>…</script> tag encloses JavaScript code into it.
Medium Level
To exploit reflected XSS at security level medium change the security level to medium from DVWA Security button as shown below.
Choose the challenge XSS Reflected from the left pane.
Let us, type our unique string [here hackme] in the input field.
Check the source code by pressing CTRL+U and search for the unique string.
In our source code below we found the unique string is reflecting. So, it may be vulnerable to reflected XSS.
Now use the same payload which we have used in the low level.
We don’t get the popup. This is beacuse server is sanitizing or encoding our input string . So let us analyse the source code to confirm what is actually happening.
Line 1: Simply contains the function to accept input from the user which is $_GET
Line 2: Replaces all occurances of <script> tag in the user input by null. As a result, when we used our payload <script>alert(“Hacked”)</script> in the input field it become alert(“Hacked”)</script> and <script> tag is filtered. Also, as we know that <script> tag is a container tag therefore it requires both opening and closing tag for its execution. This is the reason our payload didn’t work.
Line3: Reflects back the input provided by the user inside <pre>..</pre> tag after performing filtering in above line.
Let’s try to bypass the the filter. After analysing the source code we found that our <script> tag is filtered.
Bypass: To bypass it we can try <Script> or <SCRipt> or <ScRiPt> in place of <script> in our payload. It will successfully bypass this filter. So our final payload becomes
<Script>alert(“Hacked”)</Script>. Put this payload in the input field
Hoo, LaLa you can see that we have bypassed the filter and get an alert box. In this way you can exploit Reflected XSS vulnerability in DVWA at medium level. So our medium level payload is <Script>alert(“Hacked”)</Script>
High Level
Now let’s move towards the exploitation at High Level Security. To exploit reflected XSS at security level high change the security level to high from DVWA Security button as shown below.
Choose XSS Reflected on left pane.
Input unique string [here hackme] to confirm that it is reflecting or not.
Open the source code by CTRL+U and search for the string hackme .
Here the unique string hackme is reflecting. So this may be vulnerable to XSS attack.
So, let’s try our basic payload in the input field which is, <script>alert()</script>and check what happens.
We don’t get an alert box. This may be due to some filter or encoding being performed on the server side. Let’s check the source code to see what is actually happening with user input.
Line1: Simply accepts input from the user.
Line2: Replaces all occurances of <script>tag whether capital or small or both mixed with null. So <script> tag is useless.
Bypass: To bypass it we can use some other HTML tag with event handlers to print alert box on the screen. Let’s try this payload <img src=x onerror=alert()> with event handler onerror in input field.
We got an alert box. So we have successfully exploited Reflected XSS in dvwa at high level security.
So, above are the basic methods by which you can exploit reflected XSS in DVWA at low, medium and high security.
Thanks for reading the article. Want’t to say something about the post feel free to write us in comment section or contact us at [email protected].
