Application security

How cross-site scripting attacks work: Examples and video walkthrough

What is a cross-site scripting vulnerability and how does an attacker carry out a cross-site scripting attack? Find out in this walkthrough from Infosec Skills author John Wagnon.

How does cross-site scripting work?

Cross-site scripting attacks use insecure web applications to send malicious code to users. This can lead to a variety of negative outcomes for end users and organizations ranging from account compromise to data theft.

In this episode of Cyber Work Applied, John walks through what a cross-site scripting attack is, how they work and what you can do to defend against them. Watch the full walkthrough below:

New episodes of Cyber Work Applied are released every other week. Check out the full collection of free Cyber Work Applied training videos.

Cross-site scripting attack: Demo and walkthrough

The edited transcript of John's cross-site scripting walkthrough is provided below.

Cross-site scripting and the OWASP Top 10

(0:00–0:25) Many of you have heard the term cross-site scripting, but do you know how it works?

Cross-site scripting has been one of the OWASP Top 10 security risks since the list was created way back in 2003, and it remains on the list today. So all cybersecurity professionals should learn about this risk. I'm Infosec skills author, John Wagnon, and I'm going to show you how cross-site scripting attacks work.

What is a cross-site scripting attack?

(0:26–1:41) Cross-site scripting attacks are a type of injection where malicious scripts are sent to trusted websites. These attacks occur when an attacker uses a web application to send malicious code to a different end user. Flaws that allow these attacks to succeed are quite widespread. They occur anywhere a web application uses input from a user as a part of the output it generates — without validating that output.

There are actually several forms of cross-site scripting, usually targeting the user's browser.

What is a reflective cross-site scripting attack?

A reflective cross-site scripting attack is the simplest variety of cross-site scripting. It happens when an application receives data in an HTTP request, and it includes that data in the immediate response in an unsafe way.

What is a stored or persistent cross-site scripting attack?

Another type is stored or persistent cross-site scripting. This happens when an application receives data from an untrusted source, and then it includes that data in its later HTTP responses in an unsafe way.

What is a document object model cross-site scripting attack?

The last type is the document object model (DOM) cross-site scripting. This happens when an application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way. This is usually done by writing data back to the DOM.

Cross-site scripting attack examples

(1:42–3:48) Cross-site scripting attacks target things like session stealing, account takeover, multi-factor authentication bypass, DOM node replacement or defacement, tricking users into downloading malicious software and even keylogging.

Let's say a user posts a status message on a vulnerable web application saying, "Hello world." The web application will display this message on the user's browser the way it's intended, but if the web application, being vulnerable, doesn't check for proper script insertion, then it could be fooled into running a malicious script that could do all kinds of bad things.

Let's use a vulnerable social media site as another example. If a good user posts a status update, it might look something like this to the application.

POST /form/sample_post.php HTTP/1.1

Host: socialsite.com

name=john&post=Hello World!

In this case, there's a post to a form and sample_post.php website using the HTTP protocol. The host there is socialsite.com, and you can see that the name of the user is John and the post itself is "Hello World!" That's the way it's supposed to work. But if the application is vulnerable and doesn't check against user input correctly, then an attacker could post something like this.

POST /form/sample_post.php HTTP/1.1

Host: socialsite.com

name=john&post=<script>/bad code/</script>

It's that same sample_post.php website using HTTP. The host is still socialsite.com, but in this case, it's vulnerable. The name is still John, but you'll notice the post is actually a script that has a bunch of bad code in it.

That bad code script could do all kinds of bad things. Let's say it's written in such a way that it steals the session cookie from the user, and it silently sends a copy of that session cookie back to the attacker. When an unsuspecting user visits the social media site and comes across that particular post, the user's browser could run the script and the attacker would be able to steal that particular user's session cookie.

The attacker could then start to impersonate that user and do anything that user could do. This could create all sorts of problems.

How to prevent cross-site scripting

(3:49–4:39) Cross-site scripting is a big problem with web applications today, but there are things you can do to protect against it.

Cross-site scripting prevention includes things like:

Filter input based on what you expect
Encode data so that it's not interpreted as active content
Use security products like a web application firewall to detect and block cross-site scripting attacks

You can see that cross-site scripting attacks are really dangerous. That's why it's important cybersecurity professionals know how cross-site scripting attacks work and how to mitigate cross-site scripting.

Check out my Infosec Skills OWASP Top 10 learning path to learn more about these types of attacks and how you can prevent them.

See John's courses