I Used AI to Exploit XSS Vulnerabilities

インデックス作成: 2026-05-21

[00:00:00]Check this out.

[00:00:01]I'm here in my Linux system and we've got a web app running locally. It's called Voln Poetry. It looks like a simple poetry web app. You can read some cool poetry here.

[00:00:11]And it is kind of like that, but additionally, it is full of bugs.

[00:00:16]Like this web app is vulnerable to cross-site scripting vectors.

[00:00:20]Now in this video, I'll be trying to teach you what cross-site scripting is, how it works under the hood, and what harm an attacker can cause with it to you and your web app. So I've got Grok running alongside this web app and we're also going to take some help from it throughout this video. The web app has multiple cross-site scripting vectors, so it'd be fun to exploit. And if you're new here, maybe hit that subscribe button to help us grow this channel.

[00:00:44]Now if you're unaware of what cross-site scripting or XSS is, let me tell you a bit about it.

[00:00:50]Cross-site scripting or XSS is a type of vulnerability in which an attacker gets malicious HTML or JavaScript snippets rendered by the web browser.

[00:01:02]The key thing to understand here is that the browser has no idea whether that script came from the actual website developer or from an attacker.

[00:01:11]It just runs it. That's what makes this so dangerous. The browser trusts the page and if the page has your malicious code on it, the browser will execute it without asking any questions.

[00:01:23]For example, you can see a search box here.

[00:01:25]Now if I do a simple search for something like romance, it shows no results for us.

[00:01:30]Also, if you pay a bit of attention to the word romance, it looks the same.

[00:01:35]Nothing unusual with it, right?

[00:01:37]Now if we go back and instead of just typing the word, we do some HTML, like use HTML tags. You might know about them, right? For example, the H1 tag, which is used for headings. So if we want to show the word romance as a heading, we type something like the opening H1 tag, then the word romance, then the closing one.

[00:01:57]Now as soon as I press search, you can see the word romance is bigger in size compared to the previous example where it was just small.

[00:02:04]This confirms that the HTML we're giving to the search box is being rendered by the web app without any checks. Just to confirm it again, we've got the U tag which underlines text. So, if we give a payload like this which starts with the opening U tag, then our word romance, then the closing U tag, and click search, we can see a small underline under the word romance. Interesting, right? Well, not yet because it gets really interesting when we can run JavaScript using the script tag, too.

[00:02:32]For example, something like this. In this simple payload, we have a starting script tag. If you've done a bit of web development, you might know about it.

[00:02:41]Then we're using the alert function.

[00:02:43]I've written "subscribe" inside it which is just going to give us a pop-up.

[00:02:48]Then we close the script tag.

[00:02:50]Now, as soon as I click search, it shows us the pop-up which says "subscribe".

[00:02:54]Now, I know what you're thinking. Okay, cool. A pop-up, big deal.

[00:02:59]But think about it this way.

[00:03:00]If we can run an alert, we can run any JavaScript. And JavaScript on a web page can do a lot of things. It can read your cookies, redirect you to another page, make requests on your behalf, steal form data, even silently log everything you type. That is the real threat here.

[00:03:17]This is what cross-site scripting or XSS is. It is one of the most commonly found and high severity vulnerabilities in web apps because it can damage a web app pretty badly, which I'm going to show you in just a moment. But before that, we've got other types of XSS in this web app, too, and we need to find them.

[00:03:38]By the way, this one is called reflected XSS because, as you could see, we were able to trigger that pop-up.

[00:03:44]The reason it's called reflected is because the server takes our input and reflects it right back in the response without storing it anywhere. You typically exploit this by crafting a malicious URL and tricking someone into clicking it, like through a phishing message or a shortened link.

[00:04:01]But we have two more types, stored XSS and DOM-based XSS.

[00:04:08]The reflected one is the least dangerous of the three, mainly because it requires the victim to click a specific link.

[00:04:15]Whereas the other types are way more passive and dangerous. Anyway, I asked Grok where I could find stored XSS and it gave me a list. The most suitable one here for us is the comment section. In our poems, we can leave a reflection for other users to read, kind of like a comment. Now, XSS found here is going to be way more dangerous. Let me show you how.

[00:04:35]So, for the attacker name, I'm not going to do anything special, just going to put something random.

[00:04:41]But in the reflection field, I put this payload.

[00:04:46]It's another very infamous XSS payload and if I kind of break it down for you, we use an image tag and for its source, we give it X.

[00:04:55]But it expects a valid image path, right?

[00:04:57]Because of that, this image tag is going to raise an error.

[00:05:01]Now, we've specified a condition that on error, we want to execute this part.

[00:05:07]As you can read, we're triggering another alert which says subscribe.

[00:05:11]So, now as soon as I post the reflection, I can see the pop-up.

[00:05:16]But it doesn't end here because now this comment is stored in the website's database.

[00:05:22]This is why it's called stored XSS. The payload isn't just reflected once, it's permanently saved and served to every single visitor.

[00:05:31]For example, if I copy the URL for this poem and open a completely new browser and visit the link, you can see the pop-up again. And it's going to be the same for every user who visits that page. In real cases, obviously it's just a local web app, but imagine in an actual web app, a hacker found a stored XSS on a popular page that gets thousands of visitors a day. Every single one of those visitors would be running the attacker's JavaScript without knowing it. Now, they can do a couple of things with that.

[00:05:59]First is cookie theft, which I already wanted to show you in reflected XSS, but I'll show it here instead.

[00:06:06]So, instead of showing the subscribe alert, we can actually grab the cookies of the user using this XSS snippet. Now, instead of showing the subscribe text, it'll show us the website's cookies. And if you've seen any of my recent videos, you might know what hackers can do with your cookies. Basically, they can hijack your session and log in as you without ever needing your password. It does also require a few other security features to be turned off in order to grab cookies via JavaScript like the HTTP only flag needs to be missing, but that approach is getting a bit old now because most modern web apps do set that flag.

[00:06:42]One thing hackers can still do though is website defacement.

[00:06:47]You might have seen those pages where a website is completely replaced with a hacker's own content, sometimes with a political message or just to show off.

[00:06:54]That's called defacement.

[00:06:57]And it's pretty easy to pull off if a hacker has stored XSS on the page. For example, let me show you one quick demo here. Instead of showing cookies, we can run some JavaScript that replaces the entire page content. And now, whenever someone visits this page, they'll see this instead of the actual website content.

[00:07:14]That's how a lot of defacements happen.

[00:07:17]It's not always some crazy server exploit. Sometimes it's just XSS and a few lines of JavaScript.

[00:07:24]Stored XSS is way more dangerous than reflected, but still many web apps today come well sanitized against these kinds of attacks. Those who do still find bugs like these though get paid a pretty good amount of money through bug bounty programs.

[00:07:38]Some researchers have made thousands of dollars just from a single stored XSS on a well-known platform, so it's definitely worth knowing how to find these.

[00:07:46]Now, the last type of XSS is DOM-based.

[00:07:49]It's quite different from stored XSS, but somewhat similar to reflected. It's a type of XSS where the vulnerability exists in the client-side JavaScript code, not on the server. The malicious payload is executed because the JavaScript on the page takes data from the user, usually from the URL, and inserts it directly into the DOM without properly sanitizing it first.

[00:08:10]The interesting thing about DOM-based XSS is that the server never even sees the malicious payload in most cases.

[00:08:18]Everything happens entirely in the browser, which also makes it harder to detect server-side.

[00:08:23]Traditional security filters on the back end won't help here because the back end isn't even involved in the vulnerable part of the flow. In our web app, we can find a DOM-based XSS on the profile page. As you can see here, we've got a URL, and everything specified after the hash symbol is reflected on the page. Like if I type my name, it shows it over there. This means this endpoint could likely be vulnerable to DOM-based XSS. Now, if I replace the whole URL with this crafted URL, our site has been defaced again. That is what DOM-based XSS is. Simple, but effective, and surprisingly common even in modern web apps. So, those were the three main types of XSS, reflected, stored, and DOM-based.

[00:09:10]I tried my best to walk you through all of them with real examples so you actually understand what's happening rather than just memorizing the names.

[00:09:18]But, it's not like these can only be found on these specific endpoints, or that it's always this straightforward to find.

[00:09:25]XSS can literally be anywhere.

[00:09:28]Any place where user input touches the page is a potential vector. And a lot of times it is sanitized. They take your input and strip out those tags, so XSS never triggers.

[00:09:39]But, bypassing those filters is a whole topic on its own, and there are tons of creative ways to get around basic sanitization, which we might cover in a future video.

[00:09:48]XSS can also be found in HTTP headers, which we're going to cover in the next video, hopefully. There's also something called blind XSS, where your payload fires in a completely different context, in like an admin panel, and you don't even see it happen directly.

[00:10:03]That one is super interesting, and we'll definitely get into it eventually.

[00:10:07]That's enough for this one, I think. I hope you enjoyed this video. If you did, make sure to subscribe and like the video for more content like this. And if you want to support the channel, maybe check out the first link in the description. Until we meet next time, happy hacking and peace out.