- [Instructor] Let's now turn our attention
to a variety of attacks focused on web applications.
Almost every business runs web applications these days,
and those applications often store, process,
and transmit sensitive information.
These web applications sometimes serve the public,
so firewalls and other security devices are configured
to allow access to them from the internet.
If web applications aren't written
with sound security practices in mind,
they can present a major vulnerability to the organization.
Let's take a look at one such vulnerability,
the cross-site scripting attack, often abbreviated as XSS.
In a cross-site scripting attack,
the attacker places a malicious script on a site
that contains instructions directing a web browser
to access a second site.
Then the attacker waits.
When a victim visits the site,
the victim's browser unknowingly downloads and runs the code
that attempts to access the second site.
If the victim is already logged in to the second site,
the attacker's code can perform actions
on the victim's behalf on that second site.
This is basically a numbers game.
If the victim isn't already logged in to the second site,
the attack will fail.
But if the victim is logged in to the other site,
it just might succeed.
Cross-site scripting, or XSS attacks,
work under two conditions.
First, the website must have reflected input.
That means that there must be an opportunity
where the attacker can provide text to the site
that will then be displayed to other users.
Second, that input must be unvalidated.
The attacker must be able to embed script commands
into the input that will execute
when the next user comes along and views that page.
Cross-site scripting works in many different scenarios.
Reflected input frequently occurs on message boards,
in user profiles, and other places
where users are asked to provide content.
The attacker can slip in the scripting tags
that separate code from content,
and then, when another user views that content,
the victim's browser runs the script.
The solution to cross-site scripting attacks
is input validation.
When a website has reflected input,
it must check that input
to make sure that the user only provides safe content
and doesn't try to use scripting tags.
Let's take a look at cross-site scripting in action.
The Open Web Application Security Project, or OWASP,
produces a package called WebGoat
that illustrates many common web security vulnerabilities.
I'm running WebGoat on my server,
and I'm going to show you how you can execute
a cross-site scripting attack against it.
You can see here that WebGoat
has a fake human resources application
belonging to Goat Hills Financial.
I'm now going to log in as a normal user, Tom Cat,
and I happen to know that the password here is Tom.
I go ahead and log in to the application,
and you can see I can only see information about myself
because I'm a standard employee.
I click on the View Profile button,
and I can see all of the information
that the company knows about me.
It also gives me an option to edit my profile,
which I'm going to do.
And I'm going to go up here and see where
my street address is currently 2211 HyperThread Road.
I'm going to add a little extra content to the end of this.
I'm going to put in a script tag,
and then I'm going to type in a JavaScript command,
called confirm, that pops up a dialog box.
And I'm going to tell it to pop up a dialog box
that says You have been attacked.
And then I'm just going to put the close script tag
and update my profile.
Now you can see a window popped up on my screen
that says You have been attacked.
That's because this application displays
my profile back to me after I make changes.
So, so far what we've seen is that
the JavaScript I entered in the Street field
successfully makes a popup window, at least for me.
Now what I'm going to do is verify that this works
for other users on the system.
I'm going to go ahead and log out,
and I'm going to log back in again as Jerry.
And you can see from the name here
that Jerry is a human resources employee.
And, when I log in, Jerry can see other records,
including Tom Cat's.
When I click View Profile on Tom Cat's page,
the popup that Tom left there appears,
You have been attacked.
In this demonstration,
you saw a very basic cross-site scripting attack.
Tom logged in to the website
and updated his profile to include script language.
When Jerry later visited Tom's profile,
his browser saw the script and interpreted it as JavaScript,
showing the popup window we created.
By itself, this attack isn't very dangerous.
Who cares about a popup window?
But it demonstrates a more serious vulnerability.
We can execute our own scripts on a victim's machine.
What if, instead of the popup window,
we instructed Jerry's browser to visit a bank's website
and transfer cash to Tom?
If Jerry wasn't a customer of that bank
or wasn't logged in to that site, the attack would fail.
But if he was logged in to the bank's website
in another tab, it might succeed.
Cross-site scripting attackers try this thousands of times,
waiting until they hit the jackpot once.
They don't care if they have 999 failures
before a single success.
As with many types of attack,
the attacker is playing a numbers game,
waiting for that one victim.