[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
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.