video transcript

Hello, world. I'm Jesse from Chef Secure.

XSS filters look at values, and either remove them, replace them or block them if something seems dangerous.

Let's take a look. Go to the Attribute Breakout with Escaping example below.

First off, if you look at the URL, you'll see that there is a hash and the word "beautiful" at the end.

Start off by inspecting the beautiful hearts to see what's going on on the page.

In the h1 element that you inspected, it contains a class attribute containing title and the word beautiful again. So now we're gonna click the toggle button and see what happens.

(retching)

Now If you look at the URL, you'll see that the hash changed from beautiful to disgusting. Also, inspecting the h1 element again shows that the beautiful class has been changed as well.

Okay, that's enough of this. Let's toggle back to the hearts.

You already know attackers can put malicious data inside inputs, but URLs can be controlled as well, because it's simple enough just to change a part of it and send a link to a victim.

Let's try this out now. Replace the word "beautiful" in the URL with the attribute breakout payload.

We'll have a quote, a right angle bracket, then enter a script tag, alert, close script tag and then we'll hit enter and see what happens.

"><script>alert()</script>

Somethin's broken. So inspect the page to see what's going on.

Down in the h1 element, you can see that we haven't broken out of the class attribute, so, first of all, we have to solve this before moving on, because we can't do anything else until we get this right.

The way things look right now, it seems impossible, because our double quote didn't break out of the double quoted attribute.

But you are being lied to right now.

The inspector will always show attributes in double quotes, even when that's not the case. So let's try putting in a single quote instead. Replace the double quote in your payload with a single quote.

'><script>alert()</script>

The page is still broken, but we can inspect to see if that worked.

The single quote DID work, but the next problem is that the less-than and greater-than characters are being HTML escaped, and the word script is being filtered and replaced.

In other words, injecting a script element will be impossible.

So, instead of scripts, you might wanna try href or src attributes using JavaScript URLs, but I can tell you, right now, that that's not gonna work, because h1 elements don't pull content from another webpage. So you are gonna need something better.

Events are the actions that take place within the browser, like clicks and keypresses, and event handlers are a way to run JavaScript code when these happen, and can be set using HTML attributes, which you already know how to do.

The attribute name is just the word on followed by the event name, like onclick or onmouseover and it's value is just the JavaScript code you want to run, like your favorite function: alert.

Go back to the example, and modify your payload by replacing everything after the single quote with an event handler to call an alert.

I'm gonna use onclick equals alert.

'onclick=alert()

And if you remember, we broke out of the attribute by using a single quote, so that means there's gonna be an extra single quote at the end, so we're going to need to insert that right before the alert, so our event handler is properly quoted. and hit enter.

Wait a sec. There's nothing to click.

Now sometimes attackers need to take a step back in order to make the web page appear normal before adding in their exploit. In this case, you're gonna need to add either the beautiful or disgusting class in order to make this event handler work.

So right before the single quote, add in either beautiful or disgusting to fix the webpage.

beautiful'onclick=alert()

The element is back so now let's trigger the event handler.

As with JavaScript URLs, this attack requires user interaction on the page. And for XSS, attackers usually want their payload to execute as quickly as possible, but we're gonna learn how to fine-tune event handlers for exploits in a later recipe.

Question: what would happen if every instance of the word javascript:, on-something= or alert were being filtered out by the website?

This is where creativity and persistence win.

Take JavaScript URLs, for instance. Go to the JavaScript URLs with Filtering example below.

What happens when you try adding a normal JavaScript URL to trigger an alert?

javascript:alert()

You can see that "javascript:" is being removed entirely. Since the normal JavaScript URL is being filtered out, let's try being creative and mixing up capitalization, like taking a big S, or taking a big P and –

Wait. That doesn't sound right.

Taking a capital S or taking a capital P sticking them in the middle of the word JavaScript, and maybe it'll work to bypass the filter, but your browser would treat it just the same.

javaScript:alert()
javascriPt:alert()

Are you feeling creative yet?!

Newlines – add them in.

java
script:alert()

Tabs: those work too!

java script:alert()

SPACES!

java script:alert()

Nope. Those don't work.

But that's okay! Because when you're exploring the limits of what's possible, you'll run into dead-ends often. But if you don't give up, you'll learn and accomplish more than you could ever imagine.

Oh yeah, by the way, if you run out of creativity, you can just search the internet for XSS Filter Evasion , and just take what somebody else has already done.

So now you can see why it's so difficult to protect against XSS attacks, and ESPECIALLY why custom-filtering alone is not a good way to protect your beautiful website.