Hey there, welcome back.
Hopefully you took the opportunity to
read the cross-site scripting
cheat sheet and play around
with our prior practice challenge.
In our previous lesson,
we practiced protecting against
reflected cross-site scripting attacks.
In this lesson, I will show you my solution.
But before I go into my solution,
I want to talk about some of
the missteps and mistakes developers
often make after understanding the basics of a problem.
I will also introduce you to an open source tool called
CyberChef that gives you an easy way to look at text.
Then at the end,
I'll give you another round to try the challenge.
So let's get into it. Let's start by looking
at CyberChef which is a tool that's
open source and it gives you an easy way to look at
texts and basically do various manipulations against it.
So on the top, I have in
my inputs script alert one script.
There are series of,
they're called recipes in here,
where you can actually modify it.
I'm going to make this a HTML entity.
You notice what the outcome is,
is the less than sign is no longer a less than
sign but it's an HTML code and LT for less than sign.
The word script remained a script.
But then the greater than sign became at GT and so on.
So a lot of developers what they get,
this is interesting, their site,
their page is actually
vulnerable to cross-site scripting.
What a lot of developers get on their first time
is that they start doing these manipulations by hand.
So simply in the code they do field1.replace,
and then the less than sign with and
LT. You could do
this and for this example, this will work.
But this is not a good way to go about it.
The idea behind this is
there's a lot of different ways to do
encoding and there libraries
have been written to do this for us,
a much better way.
So I'm going to close this and go
back to our cross-site scripting page.
One of the pointers that cheat sheet
shows you is you need a security encoding library.
So OWASP has the Java encoder project.
If you click on that,
it'll take you to the homepage of that.
If you click on the Java encoder at GitHub,
it'll take you to the source code of
that and all the fun stuff with it.
What I'm really interested in is A, how do I use it?
So there's an example of it being used.
B, how do I get it? So this is a Maven import statement.
But what I'm really interested
here is how do I get to this?
So org.owasp.encoder seems to be
the package name where the encoder resides.
So going to our code, I'm going to
simply modify what is coming out.
So I'm just going to create a string,
and I'm going to say
clean string or maybe encode a string.
I don't know what I'm going to put in there yet,
so I'm just going to leave it empty.
I am going to replace our field one that's
being sent back to
the user with the modified encoded string.
So now it's empty.
So that's not going to work for us.
But having looked at the package name,
there seems to be a package
called org.owasp.encoder.Encode.
I can do for HTML since
we're putting this inside of an HTML body,
I can do for HTML.
If it was an attribute,
you could do it as an attribute
but I'm just going to do it for HTML
and field one was our problem child.
So it looks like that should work.
I'm going to simply refresh this and that's
going to cause the rebuild of my project for me.
Now, if you're using Docker,
you can absolutely go back to the command and
rerun the command which will build a Docker.
I'm just going to do it from the command
or from my IDE for this instance.
Let's go back to our WebGoat,
close some of these tabs.
So if we go to WebGoat and we go to
cross-site scripting and we go to number seven.
Now, this is the interesting part.
So I shouldn't be able to put
in a payload here that comes back to us.
So if I hit purchase now,
you'll notice it'll say "Try again,
we don't see the specific JavaScript."
You can actually see my payload is
now being displayed where wasn't being displayed before.
That's because it's being appropriately
encoded and when the browser
sees it instead of interpreting
it as code and running it,
it's interpreting it as data and displaying it.
Now, if I tried their payload,
you'll notice they'll say "Well done."
But again, no pop-up came
up and it's being displayed here.
That's because the test that they're
doing to verify that you put in
the appropriate payload is
obviously just doing a string match and it's
a false positive that well done, you actually executed.
You actually did not
because it's being appropriately encoded for this.
At this point, we have successfully patched
this code and this page is no
longer vulnerable to cross-site scripting.
You're going to want to do that same exact approach for
the stored cross-site scripting
and you're going to want to
document per our guidelines how you went about doing it.
I hope you enjoyed this. See you next time.