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.