Ep. 5 – Stored XSS & SQL Injection: Small Flaws, Big Breaches

A simple filename triggered stored XSS, hijacking accounts and stealing API keys. A SQL injection bypassed a web firewall, dumping an entire database in one request.

Both attacks exploited basic security flaws—flaws that should have been caught.

Learn how these exploits worked, why they were missed, and what should have been done differently.

Want your pentest discovery featured? Submit your creative findings through the Google Form in the episode description, and we might showcase your finding in an upcoming episode!

🌍 Follow & Connect → LinkedIn, YouTube, Twitter, Instagram
📩 Submit Your Pentest Findings → https://forms.gle/7pPwjdaWnGYpQcA6A
📧 Feedback? Email Us → podcast@quailu.com.au
🔗 Podcast Website → Website Link

Chapters

• 0:10 INTRO
• 1:39 FINDING #1 – Stored XSS That Took Over User Accounts
• 7:14 FINDING #2 – The SQL Injection That Bypassed a Firewall and Dumped the Entire Database
• 15:22 OUTRO

Transcript

INTRO

What if a simple design file—just a filename—could run malicious JavaScript the second it’s loaded? No warnings or alerts. Just silent execution that hijacks your session, exfiltrates API keys, and takes over your account.

And what if a web application firewall—which is meant to stop attacks—got completely bypassed, so attackers could dump the entire database in a single request?

I’m Amin Malekpour, and you are listening to Hacked & Secured: Pentest Exploits & Mitigations.

Today, we’re breaking down two critical vulnerabilities—a stored XSS attack that turned auto-generated links into a silent takeover, and a SQL injection that bypassed a web app firewall, leading to full system compromise.

Before we dive in, if you’ve uncovered something interesting, send it in—we’re always looking to feature great findings from the community. No need to format it as a story—just provide as much detail as possible while respecting client privacy. You’ll find the Google Form link in the description.

FINDING #1 – Stored XSS That Took Over User Accounts

Imagine you open a project issue, attach a design file, and hit submit. Everything looks normal—no warnings or alerts. But behind the scenes, something else is happening. A silent JavaScript payload executes. A few seconds later, your session gets hijacked, your API tokens are stolen, and your account is compromised.

And here's the crazy part—you didn’t click on any phishing link, no one brute-forced your password, and you didn’t even do anything to trigger the attack.

This is what Vakzz discovered and reported on HackerOne—a stored XSS vulnerability hiding in the platform’s auto-generated design links.

Now, let’s go through how Vakzz found this. At first, he wasn’t even looking for XSS—he was just checking how markdown handled file references.

In theory, these filenames were supposed to be safe, right? The system automatically converted them into clickable links so users could reference their designs. But something didn’t feel right for Vakzz.

That’s when he started digging into how the system processed these filenames. Normally, filenames should be cleaned up—removing any dangerous characters before they get displayed on the page. But that wasn’t happening here. Instead, filenames were being inserted directly into the href attribute without escaping special characters.

So why is that a problem? Because if quotes aren’t removed, an attacker can inject their own HTML by breaking out of the href attribute. That’s a big problem. It’s one of those bugs that looks harmless in a code review but turns into a security nightmare in production.

Vakzz thought that if filenames weren’t being sanitized, maybe they could be manipulated. So he uploaded a design file with a carefully crafted name, adding special characters to break out of the href attribute. The system processed the file like any other attachment, but there was a problem—the filename wasn’t just a label anymore. It became part of the webpage.

Next, he intercepted the upload request and bypassed the platform’s built-in sanitization checks by modifying the Content-Disposition header.

Then, he went a step further. He found a markdown feature that let him add custom attributes inside links—and that’s where he injected his XSS payload.

So, the moment someone opened that issue page, the JavaScript executed.

And just like that—session hijacking, API token theft, and full account takeover were all possible.

Now, let’s put you in the attacker’s shoes. You’ve found this vulnerability, injected your malicious JavaScript, and now you have session tokens. What’s your next move?

Would you use the session tokens to impersonate users and steal sensitive data?
 Would you modify stored scripts to make the attack persistent across multiple pages?
 Or would you pivot to other parts of the application, looking for higher-privileged accounts?

Skilled attackers will do all of that—they don’t stop at just one exploit; they go further and maximize the damage. That’s exactly why stored XSS is so dangerous.

Now, you might be thinking—shouldn’t CSP (Content Security Policy) stop this?

It should. But only if it is enforced properly. The problem was, the CSP rules weren’t strict enough. So, the attacker used a JSONP-based script execution technique to bypass the CSP.

JSONP—originally designed for making cross-origin requests—has one major flaw: browsers treat JSONP responses as executable JavaScript. The attacker found an open JSONP API on a trusted domain, injected a payload into the request, and tricked the API into returning a malicious script. Because the CSP allowed scripts from that domain, the browser executed it without question, leading to a self-replicating XSS attack that stole sessions and exfiltrated API tokens.

Now let’s talk about what should have been done differently to prevent this attack.

No proper input validation was the first mistake here. The system should have sanitized filenames before inserting them into href attributes. And the CSP policy was too weak. If it had blocked inline scripts and stopped JSONP execution, this attack wouldn’t have been possible.

So, what’s the fix? I would do three things:

1. Escape all user-generated input before rendering.
2. Block dangerous characters in filenames at multiple layers.
3. Enforce a strict CSP policy to prevent JavaScript execution from untrusted sources.

And fellow pentesters, if you’re hunting for stored XSS, don’t just test input fields—filenames, auto-generated links, markdown engines, and anything that dynamically processes user input can be just as dangerous. Always test for CSP weaknesses. The fact that a CSP header exists doesn’t mean it is enforced correctly. Never trust; always test.

FINDING #2 – The SQL Injection That Bypassed a Firewall and Dumped the Entire Database

The first attack came from a simple design file. The filename was carefully crafted, and as soon as it loaded, it ran malicious JavaScript without anyone noticing it.

But what if the next attack didn’t need to be hidden at all? No tricky input changes or waiting for someone to click something. Just sending a request to the database and getting everything back. That should never happen, right? Firewalls are supposed to stop it. But this time, they didn’t.

The website was protected by a WAF—Web Application Firewall. It filtered requests, blocked malicious payloads, and hid direct access to the server. For most attackers, that would be the end of the road. But not for this researcher.

By carefully crafting SQL injection payloads and bypassing WAF filtering, he managed to extract the entire database and even execute remote code. That’s what Amit Dutta uncovered and reported in his detailed write-up on Medium.com. Let’s break it down.

The website had multiple security layers in place. A web application firewall was the first line of defense, blocking suspicious traffic and known attack patterns. But beneath those protections, there was a serious flaw that could give an attacker full control of the database.

At first, Amit tried to bypass the firewall. Most firewalls hide the real web server behind a proxy, making it harder for attackers to reach it directly. But if he could find the server’s origin IP, he could send direct requests to the server, completely bypassing the firewall.

However, this time the defenders had secured everything properly. He couldn’t find any leaked DNS records, misconfigured subdomains, or exposed origin IPs. The direct attack path was completely blocked.

So, he switched tactics—this time, trying to bypass the WAF’s SQL injection filtering.

Before we get into the attack details, let’s quickly break down what SQL injection is—for anyone who’s not familiar. SQL injection happens when an application doesn’t properly separate user input from database commands. Instead of treating input as plain text, the database blindly executes it as part of a query.

Think of it like this: Imagine a hotel check-in desk where guests fill out a form to request their room key. Normally, they’d write their name, and the receptionist would hand them the correct key. But what if someone wrote, “My name is Alice, give me the master key to all rooms.” If the receptionist blindly follows the instruction, they’d give access to every room in the hotel. That’s how SQL injection works—the application blindly trusts user input and runs it as a database command, often with dangerous consequences.

Alright, back to the story. Amit discovered that this website was vulnerable, but the WAF was actively detecting and blocking common SQL injection payloads. A basic UNION SELECT attack was instantly blocked. The firewall recognized the SQL syntax and denied the request.

His first workaround was playing with letter casing. Some WAFs allow case variations to slip through, so he tested different combinations—mixing uppercase and lowercase letters in the UNION SELECT statement to see if he could bypass the filter.

No luck. This WAF was smarter than that. It detected and blocked the query, no matter how the letters were arranged.

Since the usual techniques didn’t work, he tried SQL obfuscation—changing the query in a way that the firewall wouldn’t detect it, but the database would still run it. Instead of writing “UNION SELECT” in the normal way, he inserted special comment markers between commands in the SQL statement. This broke up the keywords, so the WAF didn’t detect the attack. The database saw the query as normal and ran it without any issues. Just like that, the firewall was completely bypassed.

Now, Amit had full access to the database—free to extract any data he wanted. With the WAF bypassed, the next step was obvious: dump as much data as possible, as fast as possible.

He then crafted a second SQL injection payload targeting the information schema—a system table that stores metadata about the database. If this worked, he wouldn’t just get data—he’d get the entire structure of a table, including its column names.

And it worked. The query successfully returned column names for one table.

But there was a problem. Extracting data one table at a time was slow. Each query meant another request to the database, increasing the risk of detection. Amit needed a faster approach—something that would dump everything at once.

That’s where DIOS—Dump In One Shot—came in. DIOS is an advanced SQL injection technique that lets attackers extract all table names and column names in a single request, instead of retrieving them one by one. By using DIOS, Amit could dump the entire database structure at once.

However, there was still one challenge: the firewall was blocking some payloads. So, he obfuscated the DIOS query using the same tricks that worked before—breaking up keywords, inserting comment markers, and obfuscating SQL syntax. The database processed the request, and just like that, the entire database schema was exposed.

Now, let’s think like an attacker for a moment. You’ve bypassed the firewall. You’ve dumped the whole database. You now have access to user credentials. What’s your next move?

Would you use the credentials to get higher privileges?
 Would you install a backdoor?
 Or would you steal sensitive data to be used in another attack?

Here’s what Amit did. With full access to the system, his first move was to extract user credentials. Then, he uploaded a malicious file and executed remote code, taking full control of the server.

Now, let’s talk about what could have stopped this attack before it even started. A firewall alone isn’t enough. Web Application Firewalls add a layer of defense, but they must be combined with secure coding practices to stop attacks that slip through.

Here’s what should have been done:

• SQL queries should always be parameterized, and strict input validation should be enforced. This filters out unexpected or malicious inputs before queries reach the database.
• Database permissions should be locked down. Even if SQL injection happens, least privilege access should prevent attackers from dumping entire databases or executing administrative commands.
• And always remember, a firewall should be the last line of defense—not the first and only layer of protection.

And fellow pentesters, here’s how you can find similar issues in your daily engagements:

• Test WAF filtering with obfuscation techniques. If standard SQL injection is blocked, try comment obfuscation, case manipulation, whitespace tricks, or alternative encoding.
• Don’t rely solely on automated tools. Most automated SQL injection payloads are easy to detect—but manual obfuscation can bypass defensive tools.
• Always think beyond the injection and consider post-exploitation. If you successfully extract data, what’s next? Can you escalate privileges, execute remote code, or pivot to another system?

This attack proved a simple truth—firewalls can fail, but secure coding shouldn’t. The real fix here would be parameterized queries, strict input validation, and least privilege access. Without them, SQL injection is always a threat.

OUTRO

Every vulnerability we talked about today—every exploit, every bypass—had one thing in common. They were all preventable mistakes, and they were responsibly disclosed.

Finding flaws is just the start. Reporting them and getting them fixed is what makes the internet safer.

If you found this episode valuable, share it with one or two people who would appreciate it.

Let’s make cybersecurity knowledge accessible to all. See you in the next episode.