Cross‑Site Scripting: Old Yet Dangerous
Key Points
- XSS (cross‑site scripting) is a decades‑old injection attack that remains the top‑impact threat in recent IBM X‑Force Cloud reports and ranks among OWASP’s top web‑application vulnerabilities.
- Attackers embed malicious JavaScript into benign sites (e.g., comment fields), which then executes in a victim’s browser under the trusted site’s context.
- Because the malicious code runs as if it originated from the legitimate website, attackers can deface pages, inject misleading UI elements, or manipulate user actions.
- The injected script can also steal session cookies or other credentials, effectively hijacking the user’s authenticated session.
- Mitigation strategies focus on proper input sanitization, output encoding, and security best practices to eliminate XSS vectors and reduce its prevalence.
Sections
- Cross‑Site Scripting Still Threatening Web - The speaker outlines why the decades‑old XSS attack remains a top web vulnerability, breaks down its architecture with a coding example, and proposes mitigation strategies.
- Session Hijacking and Malicious Injection Risks - The speaker explains how an attacker injecting code into a trusted website can hijack user sessions, steal credentials, deliver malware, and redirect victims to phishing sites, causing severe damage.
- Understanding and Mitigating XSS - The speaker explains how a cross‑site scripting payload executes in a user’s browser and advises validating and sanitizing all user input to prevent such attacks.
Full Transcript
# Cross‑Site Scripting: Old Yet Dangerous **Source:** [https://www.youtube.com/watch?v=z4LhLJnmoZ0](https://www.youtube.com/watch?v=z4LhLJnmoZ0) **Duration:** 00:09:17 ## Summary - XSS (cross‑site scripting) is a decades‑old injection attack that remains the top‑impact threat in recent IBM X‑Force Cloud reports and ranks among OWASP’s top web‑application vulnerabilities. - Attackers embed malicious JavaScript into benign sites (e.g., comment fields), which then executes in a victim’s browser under the trusted site’s context. - Because the malicious code runs as if it originated from the legitimate website, attackers can deface pages, inject misleading UI elements, or manipulate user actions. - The injected script can also steal session cookies or other credentials, effectively hijacking the user’s authenticated session. - Mitigation strategies focus on proper input sanitization, output encoding, and security best practices to eliminate XSS vectors and reduce its prevalence. ## Sections - [00:00:00](https://www.youtube.com/watch?v=z4LhLJnmoZ0&t=0s) **Cross‑Site Scripting Still Threatening Web** - The speaker outlines why the decades‑old XSS attack remains a top web vulnerability, breaks down its architecture with a coding example, and proposes mitigation strategies. - [00:03:06](https://www.youtube.com/watch?v=z4LhLJnmoZ0&t=186s) **Session Hijacking and Malicious Injection Risks** - The speaker explains how an attacker injecting code into a trusted website can hijack user sessions, steal credentials, deliver malware, and redirect victims to phishing sites, causing severe damage. - [00:06:13](https://www.youtube.com/watch?v=z4LhLJnmoZ0&t=373s) **Understanding and Mitigating XSS** - The speaker explains how a cross‑site scripting payload executes in a user’s browser and advises validating and sanitizing all user input to prevent such attacks. ## Full Transcript
X.S.S. three letters that the good guys don't want to see.
It stands for cross-site scripting.
It's a type of attack that has been around since 1999.
That's a quarter of a century.
So this is old news in one sense,
but at the same time, it's not.
The recent IBM X-Force Cloud security landscape report In fact, showed it to be the number one most impactful type of attack.
And the well-respected industry group OWASP,
the Open World Wide Application Security Project,
listed it as number three on their list of top ten Web Application Vulnerabilities.
So why is an attack that's been around this long still affecting us in a major way today?
We're going to take a look at this attack and try to understand the architecture,
the anatomy. We're going to peel it apart.
We're going to look at a coding example.
So you can see, in fact, how the attack works.
And then take a look at some recommendations,
some things that we can do that I hope will one day make it so that these numbers disappear when it comes to XSS cross-site scripting.
Okay. Let's take a look at the architecture of a cross-site scripting attack.
How does this thing lay out?
Here's our attacker. Here's our victim. okay.
The attacker finds a website, a regular website, trusted website.
Good guys, they're not really part of the attack,
but they're actually going to be unwitting part of the attack.
The attacker then basically crafts some code.
So he writes a JavaScript or something like that
and puts that in, let's say on this website, there's a comment section
where people can go in and add their own comments, free form text,
and he adds in his script.
Now this guy comes along, the good guy,
unsuspecting, and he visits that site
and either just hovers over it or he clicks on the link.
That then causes this to execute.
Now, the code that this guy has now injected, and that's the key word, this is an injection type of attack
similar to a SQL injection, but this is with different code,
and that is going to now run in this guy's browser,
But here's the trick,
It's running under the context of this website
which is a trusted website, even though this is untrusted code.
And that's where the bad guy is taking advantage.
What could happen now?
As a result, What could happen is the image that he gets back could be a defaced version of this website.
So this guy could actually manipulate what he sees.
That's one possibility is defacement.
And if he deface is that it? Depends on what he puts in,
but he could also add elements to the screen or things like that
and really throw this person off.
Make them do things that they shouldn't otherwise do.
Another really damaging part of this attack is that now this code is running on this guy's system,
and he could, in the script cause the cookies,
the things that are causing the context for this user to be transferred over to the bad guy.
The bad guy has essentially, at that point, hijacked his session.
A hijacking attack now means that let's say, for instance, this is his is bank's website.
Well, now this guy can essentially hijack that session,
begin in the middle and go into his bank account,
empty out his account, buy lots of stuff in his name.
If it's an e-commerce site, something like that.
So this guy now has complete control over the session that the good guy started.
What's another type of thing that could happen?
Well, he could inject through this.
He could inject malware, and that malware
now might escape the browser and run on his system natively.
That also would be a really big problem.
Another possibility, you can see there are a lot of them,
is in the code that he is injected,
maybe there is a redirection to another site,
maybe this is essentially a phishing campaign.
And now when this guy logs in or he's going to go to this site, it's going to ask him to log in.
He's going to put in information about himself, his credentials, and things like that.
And all of that stuff is of course, going to go to this guy.
So there's a lot of different types of scenarios that can happen here.
All very damaging and all doing it under the context of a trusted site.
Even though the code that's been injected is very untrustworthy.
Now, this guy, it's initiated by him inserting, injecting the code into the website, and then someone comes along and views it.
But this guy can be more proactive if he wants.
In fact, one of the things he could do is he could send an email over to this user and in that email, or it could be a text message, something like that,
and in that is the link that includes this code.
And then when he does that it's going to run under the context of that website.
And again give him all of these kinds of attack scenarios.
So you can see this guy takes control.
This guy now is a victim and really doesn't even know in many cases that, in fact, what he's doing is interacting with the bad guy.
Okay. Now we've taken a look at the architecture of a cross-site scripting attack.
Now let's take a look at a coding example.
Super simple.
This one would not do any harm, but you'll get the general idea.
So here is an example of the URL
that the attacker might insert into the comment section.
As an example, in my previous diagram.
Or that they could send in an email.
And so here we see this is the domain name.
So that should look familiar.
That's basically telling it what web server to go to in order to run this particular command, this particular script.
And in this particular script that's what it's going to run.
Now all of that's fine. Really. No damage.
Here's where all the damage comes.
This is the payload.
This is where the bad guy now has basically inserted into,
what would be an otherwise benign link, has inserted his own code.
And in case you don't know how to read what this does,
basically what it's going to do in this case is on the user's browser.
It's going to pop up a box that says that
cross-site scripting.
So that's all this one's going to do.
But you can see the fact is the attacker could take anything that they wanted to
and put that in this section and that now is going to run on the,
unsuspecting victims system
under the context of that website.
That's how they're able to do the magic.
This is a very simple coding example.
It could be worse.
Now we've taken a look at the coding example.
What can you do about this.
We understand the problem, what's the solution?
Well there are a number of things.
It begins with don't trust user input.
Whatever a user puts on your site is something you need to first of all validate.
You need to make sure that they have not inserted anything that you don't want on that page.
So if you've got a comment section, for instance,
the only thing that should be in there would be plain text. If they're putting anything else in there, then that would be a problem.
For instance, you want to look at everything, inspect and reject, inspect all of the input that comes in.
And that's text. That's fine.
That's text. That's fine.
Know, this is code. I'm not going to allow that.
I'm not going to allow, even though we're not talking about SQL injection, look for those commands as well.
And if I see that stuff in thereI'm going to throw that out.
That way I make sure the stuff that goes on the page is in fact plain text.
So inspect and reject.
Don't trust user generated input that comes to your site.
The next thing you can do to help with this is to encode
the output.
Encode any of the stuff that the user has put on your page.
And by that I mean, for instance, if we've got special characters
like these, then convert them into their plain text counterparts.
Now these are the things that the HTML, the browser, is actually going to take and turn into plain text.
If you allow these versions to go through.
Those are the kinds of things that could be inserted and allow a script to be in.
So you're going to validate inputs, encode outputs. Cover both the ends and the outs.
And those are just a couple of things you can do.
Those are the ones that will make the biggest difference on this.
There are actually a number of other things that you can do.
And so you have those recommendations.
One more set of recommendations I would refer you to,
I mentioned OWASP at the beginning of the video.
They have a really nice cheat sheet
And in that cheat sheet they will go through in detail
coding examples and give you even more ideas.
Other way you can avoid what has been a quarter of a century of attacks
using this very common mechanism that still is at the top of the charts.
It's called cross-site scripting. Let's get rid of it.