Hi, every security enthusiast out there. In this blog, we are going to tell you how to approach to find Cross-Site Scripting vulnerabilities in a web application.
So what is XSS and why is it so dangerous?
XSS or Cross-site scripting is a type of web application vulnerability. It is considered to be one of the most dangerous vulnerabilities present in a website.
An attacker can get various sensitive and personal details like the username or password by redirecting you to a spoofed website, steal your cookies and the worst of them hijack your user-session.
If you are new to XSS please check out these two references before reading any further. Since in this post we will only focus on how to test for XSS instead of what it is and the prerequisites.
Read the second reference and all the other links mentioned in it carefully. In case you don’t understand check out some videos on Youtube on XSS, it will give you a basic knowledge of what XSS is and why many web applications are vulnerable to them.
Bug bounty hunters, try different platforms to learn and practice XSS. These are one of the most dangerous vulnerabilities and have been in the OWASP Top 10 for quite a long time. Companies provide good bounties for XSS hunting in their web application.
How do I test if this web application has XSS vulnerability?
A web application can contain several XSS vulnerabilities in different parts of the application. That’s why an application needs to be thoroughly tested without leaving any page because even “one vulnerable input field” can lead to the privacy leakage of users.
XSS can be found in the places where there is some sort of user input required. For example, it can be a search box, a comment section and form input fields like name, address or credit card information.
How does XSS occur?
Let’s consider a site http://www.askyourqueries.com. The website has a search box where a user can ask any personal or professional queries. But the attacker instead of that tries to insert a payload something like this:
“;alert('XSS');”
If the search input field is vulnerable to XSS, a popup will be shown in the browser on clicking the Submit button. The popup will look something like this,
Now, what is happening here?
Improper HTML sanitization and encoding lead to this. This payload instead of being treated as a simple text is getting executed as a code. Read more about sanitization here.
Note: Payload is a fancy term for code snippets simply. Different payloads are injected at different input fields for XSS testing.
Cool, I get the theoretical part, but in practice how do we approach for finding XSS vulnerabilities?
This is the main part of the blog. We hope that you have already gone through all the previous references about XSS and HTML sanitization.
As mentioned before, the code “;alert('XSS');” is actually a payload. An attacker tries to insert different payloads in an input field for finding an XSS vulnerability. You can find many XSS payloads on the internet but you need to understand which type of payloads will work for that particular field. When you can distinguish between the different contexts then you will be able to create your own payloads.
For choosing a payload, you need to understand the context.
Now, what is a context?
When hunting for XSS, we need to check where the payload shows up in the source code. You can use a proxy like Burp Suite for this and in the Repeater tab can take a look at both the Request and Response side by side. Now in the Response tab, you need to search for the payload you injected. Make a note where the payload is going. It can be directly between HTML tags, or between script tags or in the attribute field.
Burpsuite is an excellent tool for Web Application penetration testing. Try to learn to use Burpsuite more proficiently and effectively. Check the official site here for getting started.
For example when the Response shows the payload in between the script tags:
<script>var a = "Injection point" ;</script>
You will need to inject payloads like
";alert(1);"
in the Injection Point.
The motive of payloads is to insert the code in such a way that it gets executed instead of being treated as raw data. If you look at the two payloads closely and insert it in place of the injection point, you will note that all they are trying to do is to execute the payload simply by closing and opening the script tags or opening and closing of quotes.
There is another type of context called the Attribute context. For example, if the place where your payload gets reflected is:
<div class = "Injection point">Attribute context</div>
So what should we do now? You can’t just use the previous payload "alert(1);" and think that it will work somehow. It is not the correct attribute for this context. Look again and you will find that there are no script tags present here to execute the code alert(1).
That’s why we need to think of some other payload that will make the code execute. Something like this, "onmouseover=" alert(1);. It will close the first quotes and then it will execute the code after that.
Some developers use single quotes instead of the double quotes, so make sure you are using the correct payload for that context. That means use 'alert(1);' instead of "alert(1);".
Few points to remember:
- Don’t get discouraged if you can’t find XSS. Nowadays, developers are taking special care by properly sanitizing their tags so that there is no chance for vulnerabilities like XSS. Just keep checking on all the input fields on all the pages of the website.
- Not only this but Encoding is also being used so that the code can be treated as normal text. Take a brief look on HTML encoding at this page. It’s an important topic for understanding XSS.
Important tips for finding XSS
Penetration testers do know how to search for XSS and which payloads they should use but sometimes they miss out on the little things. Some of these are:
- “Try 100 different input fields instead of using 100 different payloads on the same field.” You should try out a maximum of 10 different payloads on a field, else start moving on to the other. That’s the basic formula for finding an XSS.
- Many times while testing, the popup will be on a different page than the one you were testing on. So keep that in mind.
- Use Mozilla instead of Chrome when testing for XSS vulnerabilities. Google Chrome uses an XSS auditor, which when testing thinks that you are doing that with malicious intent and many times you won’t get the popup. So try using Firefox until you learn how to bypass the XSS auditor.
This post was intentionally written to give you the approach to finding XSS vulnerabilities. It’s not a post on XSS or XSS payloads or different types of XSS present. For that, you can read the OWASP reference. Many times new professionals can’t understand where to start and that’s what this post was for.
To sum up the blog you need to do these things in sequence,
- Learn using Burpsuite(Watch Youtube videos and the official site here).
- Read the OWASP reference from here.
- Practice on vulnerable applications like Webgoat and DVWA. When ready for live action, switch to bug bounty sites like Hackerone and Bugcrowd. Pick up a target of your choice and start XSS hunting using Burpsuite.
Feel free to comment in case you need to clarify any query, can’t understand something on XSS or think that we should update this blog with something. We will be more than happy to help you and will reply to you as soon as possible.
Till then keep learning and start hacking now.:)
