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.