video transcript

Hey. Let's look at some bad URLs.

NOT THOSE BAD URLs! The kind used for exploiting –

The kind used for penetration te–

Cross-Site Scripting URLs.

Hello, world! I'm Jesse from Chef Secure, and I've got some good news and some bad news.

The good news is you're attacking HTML attributes again. But the bad news: I'm HTML escaping your input so...

(laughs)

Your payload's not gonna work.

Some attributes are specifically designed for URLs. hrefs in anchor tags take in URLs to create links, and sources in iframes take in URLs to embed webpages.

Go to the JavaScript URLs example for this recipe below.

Type anything into the input box, and click UPDATE just so we can see what's going on.

Right-click and inspect the updated element And you can see that your input is being used in both the href attribute and in the h1 content for this link.

Go ahead and try injecting the payload from last recipe to break out of the attribute and inject a script tag.

Click the UPDATE button.

It didn't work this time, so let's inspect the element to find out what's going on.

As you can see, it's being HTML escaped, so the browser doesn't treat your code as code. Instead, it's just text.

So this eliminates breaking out of attributes and injecting script tags from our attack, so, instead, we're gonna attack the URL directly.

But before we do that, what exactly is a URL?

The technical definition of a URL is: it starts with a scheme, followed by a colon followed by a bunch-of-other-stuff.

scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]

Normally on the web, we use http or https schemes, but just linking to another webpage isn't gonna help us out for an attack, so let's not be boring.

What if there was a scheme we could use specifically to launch XSS attacks?

Think of something completely and totally crazy, like...

A JavaScript scheme that can allow us to inject malicious script whenever we wanted thereby compromising the security of every website that doesn't specifically defend against this.

But that would be too easy, like, seriously.

(sarcastically) Okay, here we go. Type in ja- va- script- COLON! alert parenthesis then let's click the UPDATE button. And now we're gonna click this link.

Yeah, it's actually a thing!

The JavaScript scheme can be used in redirects, or in source attributes like in iframes and embeds as well as in href attributes like in anchor elements like we just saw.

AGAIN.

Again?

Again, remember the alert is simply a convention used to show there's a vulnerability on the webpage, but it can easily be replaced by code that could ultimately end up causing harm.

Much like those other URLs you've been visiting.

The next type of URL that can lead to XSS is probably something you're already using.

I'm talkin' about third-party-scripts.

You know, where you pull a script from another webpage and run it on your own?

Hmm, that sounds a lot like Cross-Site Scripting.

I'm NOT gonna tell you don't use third-party scripts, because that would be stupid and unreasonable of me. And I'm not an unreasonable man.

But what I am gonna tell you is to be careful of who you trust, and even if you do have trust, know that security breaches can happen where servers can get compromised, and code can be changed.

I'll show you how to protect yourself from this in a later recipe, but if you already know right now you have some shady scripts that you're trusting, go ahead and look at them just to make sure they're not doing anything they shouldn't.

Finally, this recipe would not be complete without discussing the data scheme.

It can look something like this:

data:text/html,<script>alert()</script>

or, sometimes, encoded with base64 like this:

data:text/html;base64,PHNjcmlwdD5hbGVydCgpPC9zY3JpcHQ+

Data schemes used to work for XSS attacks, but modern browsers have fixed this with updates. This means that any script run from a data schme is not XSS because it's completely isolated, and the script is not run in the context of the webpage.

But if you're forced to support older, insecure versions of browsers that make your website vulnerable to attacks, then I'm sorry, but, you're beyond help.

Whelp! That's the end of this recip–

No, wait!

Defending against the data scheme is the same as with defending against the JavaScript scheme, and I'll walk you through exactly how to do this in a later recipe.

If someone ever tells you they don't need to worry about Cross-Site Scripting, because they have automatic, HTML escaping, be a pal, and share a bad URL or two with 'em.