Hey, welcome back.
In our previous lessons,
we discussed injection attacks in general terms.
Now, we're going to focus on
one category of injection attacks,
and that is cross-site scripting,
often written as XSS.
Now, OWASP separates injection flaws
in WebGoat and the OWASP top 10.
This is simply because the target of
the attack is the backend
whereas in cross-site scripting,
this targets the user's browser.
As a result, OWASP splits them.
But the fundamental flaws are very similar.
We'll focus more on injection attacks that
target the backend later in the modules.
In this lesson, I will introduce
you cross-site scripting attacks.
I will distinguish between
three different types; reflected, stored,
and DOM-based, as well as describe what
JavaScript is and what it
does in the context of this topic.
After this lesson, you'll be able to
discuss cross-site scripting attacks.
You'll recall where to go to reference
more information on Owasp and webGoat.
You'll be able to distinguish
between the three different types of
cross-site scripting attacks and discuss what
JavaScript is. So let's get started.
You can see that in their language of
reflected cross-site scripting injection,
stored cross-site scripting injection,
or DOM-based cross-site scripting injection.
So those are the three types
of cross-site scripting vulnerabilities.
We're only going to focus on the
reflected and the stored.
The reason we're going to skip over the
DOM-based is because in our reality,
DOM-based cross-site scripting injections
are fundamentally the same as those that are reflected.
It's just that the reflection
point is a little bit different.
So we're not going to really get into that.
OWASP again has a great resource for explaining DOM-based
and WebGoat does take some measures in explaining that.
So let's get started really quickly.
So before we can really truly
talk about cross-site scripting vulnerabilities,
we need to talk about JavaScript and we need to have
an understanding of what JavaScript does and what it is.
Now, they have quick examples
where you can simply type in
JavaScript: alert XSS Test into your URL.
But that may not work for
all people and I'll show you that
it does not work for me.
I am currently running Chrome version 70,
and it does not work for me.
So if you copy and paste this into the URL bar,
it's going to automatically delete a JavaScript part,
that's just for security purposes.
But you notice that just simply typing in
JavaScript alert has stopped working in Chrome.
I also tried it in Firefox as well and it does
not work as of quantum.
So it's a little bit hard to do
this lesson and they haven't updated it yet.
So here's another way of doing this.
You can simply right-click on the page and hit Inspect,
and click the console button
and then specs that comes up.
Now, I'm using Chrome.
Yours may look a little bit different than mine.
I just hit that button to clean the console.
Here, it looks at the command prompt.
I can basically typing anything I
want and JavaScript will run it for me.
So if I type in 1 plus 2, I get 3.
If I say var a equals 1 plus 2,
I can type in a and I get three.
I can do something really interesting like b equals 4,
and then I can do a plus b, and I'll get 7.
So I can do basic arithmetic with it.
You also have access to JavaScript functions,
like I can open up an alert box saying hello,
and you'll see a pop-up come up.
You can do more interesting things with it,
like get the document.
That'll just return an object
with the various parts of the document in it.
I could do things like document.
So if we do something like document cookies in here,
we'll get that cookie.
If we open up the same URL on
a different tab and I type in document.cookies,
we see that this does in fact,
and it is the same as that one.
So to answer that question, we can say something like,
yes it does match and you get your congratulations,
you have successfully completed the assignment.
So what is behind this is simply were we able
to run some JavaScript.
So JavaScript can run
in our browser in various different contexts.
I mentioned contexts earlier because depending on
how you go about getting the cross-site scripting,
the payload is being injected in
different part of the HTML document,
which a browser interprets differently.
So we need to be very much
aware of where JavaScript's coming from,
so that we can defend against it
appropriately and the defenses for
those are different and
they're different for each scenario.
So some of the places that you might see
is in the field where we echo the string back.
We did this with our self XSS page on
my personal website earlier
and we looked at the PHP code for that.
Input fields, that's something
where maybe you do a search on
Google and you can actually put in
some characters that are getting returned back to you.
If Google doesn't do a good job validating
that input and escaping various things you put in there,
you may get that back.
Error messages is an interesting way of doing it.
Webpages can return error messages,
and sometimes a contents of those error messages are
returning the payload that the user provided.
For instance, it could be something like, "I'm sorry,
the name script hello
does not match any names that we have."
This is true and that's a good error.
But again, that script hello is being
returned back and if the browser sees it,
it could interpret it as such.
There may be hidden fields that are not even
visible to the user message boards,
forums, and even HTTP headers can all
have cross-site scripting payloads in them.
So we'll give a couple of
different examples of that and look
through them and see what it looks like.
Now, cross-site scripting attacks are important.
At first glance, it's difficult to explain
why they're important because truly speaking,
this is a vulnerability.
They really compromises a user's trust.
It's not something that directly impacts
our server or our website or our application.
The script is running in the user's browser
and it's really the user that's vulnerable by this.
But it also allows the attacker
to do a lot of nefarious things.
They could simply steal session cookies from the user.
Now, if an attacker is
able to steal a user session cookie,
they can essentially authenticate on behalf of that user,
and now take actions on our page on behalf of that user.
What if that user was an admin of my site?
Now, I'm allowing an attacker to
impersonate my admin because
I allowed a cross-site scripting.
They could also create false requests.
They could create false fields.
They could steal credentials,
and they can even launch other attacks from
the browser against my network.
So once a cross-site scripting vulnerability,
once a JavaScript is running in the user's browser,
that attacker can actually run any set of attacks
against that user on
behalf of that user against our network.
So they could simply scan for open ports on our network.
They could make requests to
other webpages that are only
available from within our network.
So it can get very devastating once
an attacker gets a good cross-site scripting
vulnerability in their hands.
So as we mentioned,
there's three different types of cross-site scripting.
There is the reflected,
stored or persistent type, and the DOM-based.
Technically, DOM-based is reflected.
So we're not going to get into it
just because of the overhead that it
requires of understanding of
different frameworks in the browser.
So for the reflected scenario,
it's always going to be a case where an attacker has
to somehow fish or get a malicious user to click a link,
and the threat model works like this.
The attacker identifies a flaw in an application.
The attacker crafts a URL and sends it to the victim.
The victim simply clicks or opens that URL.
That attack is run on behalf of the victim.
That attack is reflected back to
the victim and it executes in their browser.
The victim's browser could at
that point send information to the attacker,
but it doesn't necessarily have to.
It could make modifications to internal webpages,
could make calls on behalf of that user modifying
something especially in
the modern rest world environment.
The attacker could cause a victim's browser to call out
to various endpoints and ask for resources.
So let's go ahead and
play with our first reflected attack.
Go ahead and give this a try and see
what you didn't see coming up on the page.
What things are being reflected back to us,
and we'll restart on the next video.