[MUSIC] Hey, welcome back. In our previous lesson, we covered
cross-site scripting attacks and we tried to identify cross-site
scripting in WebGoat activity. Remember, even though these practice
activities are ungraded initially, they make up a part of
your final project and they're an essential part of your
learning plan, so please don't skip them. In this lesson, I'm going to show you
how I approached the previous activity. If you had a different
approach than me that worked, be sure to share it in
the discussion area. After this lesson, we'll be able to explain how to protect
again cross-site scripting injections and those types of attacks, and
practice part of your final project. Finally, you'll have a chance to
patch that vulnerability in WebGoat. So let's get started. So hopefully you had a chance
to play around with this. And the question we really want to
ask ourself is, what user controlled information here is being redisplayed
to the page without any modifications? So I'm I'm just going to hit Purchase and
just examine the page. And after a few seconds, you notice that
the credit card number is being displayed. So we can test that theory. We can just put in some gibberish text and
notice that it comes up. Okay, so we know that no input
validation is being done on this. And we'll talk about the various methods
that you can go about to protect against cross-site scripting in a second. They specifically want us
to use their own payload, so we'll just copy that,
paste it in here, purchase. we notice that their payload comes up and,
well done, but alerts aren't very impressive, are they? So what just happened here was some user controlled content got
presented to this page. Now, of course, you can't see anything
because JavaScript is not displayed, it's executed on. And then we saw the alert box. Now, this looks like I just attacked
myself, so the question becomes, was that a Self XSS or a Reflected XSS? The issue here is that WebGoat has
created a container where their lessons are being contained in. So the URL on your browser is not actually
representative of the URL itself. Truly what's happening is a link is
being called where all these parameters are being sent as URL parameters to the
page, and it's simply being executed on. So we can look at the code in a second and
just see what that looks like. But essentially the problem is that
the WebGoat framework doesn't allow for you to see this, this request
is being made in the background. Now, if you open this in a new tab, you'll
notice that you just get a gibberish text back and not really something
that is being executed on. And that's because this is a JSON message
that the WebGoat framework does get back. I know I already showed this example, but if we go back to my
page on selfxss.php, this is a page that's simply saying Hello. And I can add to it a variable name, let's
say James, and it'll say, Hello James. Alternatively, I can put in <script>document.cookies. I don't think my page makes any cookies,
but obviously this won't work in Chrome
because XSS auditor is turned on. Like I mentioned in a previous video, I have a version of Chromium
that has all of that disabled. And if we simply submit that,
it actually did execute it for us, but there's no cookies in here. So let's see what else we can do. Maybe I can do alert(1). [INAUDIBLE] type,
I may have a typo here, 123. And there it goes. So what do we do? The idea here is that this URL
can be sent to a victim and have this execute on their browser. So I'm going to go to about page six and
we can discuss that. So once we've identified the XSS flaw, now we know what information we control
on this page, it's the credit card field. And we know that the credit card field
is being appended to the URL, and it's essentially going to execute
in the user's browser for us. We can send that link to a victim and
have the victim click on it, and it will essentially execute all
of that from the user's browser. Now, the danger here is, what if
this website was a banking website? What if part of my request was to transfer
money from one account to another? This is problematic for the user,
and we want to defend against it. So WebGoat is going to start on page 9,
10, 11 and so on, talking about stored
cross-site scripting. I'm just going to fast forward to page
14 and talk about some of the defenses. So hopefully at this point you know
that this is something that's dangerous. And if a user's logged in,
it can cause tons of problems for the user that visits a page that has a
cross-site scripting vulnerability on it. So the question becomes,
how do you protect against it? And the answer is pretty simple. We want to basically
encode that information so that the browser can differentiate between
data that the user is providing and code that a developer has written. This becomes really interesting
because our browser speaks many different languages, and depending
on where we're putting the payload, we want to encode specifically for
that portion of it. To kind of give you an example,
our browsers have HTML bodies and they have HTML attributes. And the way you encode JavaScript,
for instance, for these different types is different. In fact, you could have the user's payload
go directly inside of a JavaScript body. In which case, we want to take some other precautions
to encode that data appropriately. There's a lot of ways to go about this,
and a red herring is thinking that we
could just blacklist scripts, we can say something to the extent of, we don't
want to allow scripts in our payload. That's not necessarily going to
be successful because, again, depending on where the content
is being displayed, we need to make sure that we're defending
against it specifically for that use case. So let's look at the code. Now, I'll talk about how
we found the code for a second before we talk about how
we go about defending against this. So I simply went to WebGoat lesson
plans and found cross-site scripting, because that's what we're
working on right now. And once you drill down,
there's a bunch different files. And if you open up each of the files, you
can kind of read the language that's on it and try to cross-reference it
with the page itself to find it. I'll make it a point to write out
each individual path to the files that we're going to be modifying
throughout the module. So it looks like our field
is simply being displayed. So whatever the user is
putting in field one, and I'm assuming at that point it's the credit
card number because we can see the similar language of we have charge
the credit card number. And if we go back to our browser, you'll
notice we have charge the credit card number and
whatever you put there is being displayed. So we can test this,
we can say field one, and then we can maybe add something to it, credit card number. And if we recompile that, All right, I'll refresh this page. If I hit Purchase, you'll notice that our arrow that we
added in there is working in here. So we have the right file. The question is,
how do we go about modifying this so that the payload is not displayed in here? So go ahead and take some time, and maybe
Google around on the OWAPS web page, and see what you need to do to prevent from
this payload from being displayed. On page 15, there's many
resources that you can look at. And one of those is the General XSS
prevention Cheat Sheet. And there's a lot of resources in here. So maybe give that a read and see if
you can come up with a way to prevent this cross-site scripting vulnerability.