Welcome back. In our previous lesson,
we started with a screencast of me showing you how
I went about finding vulnerable components.
In this lesson, we're going to finish up with me
showing you how I found and how I fix those flaws.
After this lesson, you'll be able to find
vulnerable libraries inside your codebase
using a tool like dependency checker.
You'll be able to research a flaw and
the final suitable library replacement.
In this screencast, I noted
the most recent version of XStream,
if that's changed by the time you are taking this course,
just update to whatever is
the latest version and use that.
This will be our last demo screencasts.
So let's do it. All right.
Hopefully, you had a chance to play
around with this vulnerability,
and maybe you have some questions about how it works,
but it's pretty easy to fix.
So all we need to do is
use the most recent version of XStream,
and going through the dependency checker
opening these x-stream.github.io/change logs.
You can actually look to see what is
the most recent update to XStream,
and it's version 1.4.11.21.
So we need to update to that version.
If we come back to this, we can
obviously see this is the vulnerable code here,
and we will simply go to
the pom_xml file and update to the most recent version.
So you can see that we're using an XStream 1.4.7,
and we want to be using XStream 1.4.11.21.
Let's get that version,
and it'll take a second for
your system to update to that.
I want to caution sometimes,
whenever you're modifying packages inside here,
technically speaking, Maven is supposed to
take precedence of the closses package to the project.
However, depending on how
your compiler and you're Maven is configured,
it may not use that.
So I know from experience that this XStream is
actually referenced and brought into as
a dependency twice within the lessons.
So the other place that it's brought in,
so we already changed it under vulnerable components.
But we need to also change it
underneath the WebGoat lessons parent,
and you can see that the same version of
XStream is actually used there as well.
We want to get that version. All right.
So I'm going to stop this,
and I want to also put in
a test case to make sure my package actually got updated.
Because sometimes depending on your IDE,
if you simply replace something,
it may not actually update that package.
So you don't have to do this
if you're confident that you are
Maven clean actually cleaned and you rebuilt,
but I'm not confident.
I'm going to do a system.out.printline
and the XStream that we have.
We're going to get the class at runtime,
and we're going to get the package for it,
and we're going to get the implementation version.
So hopefully, that prints out whatever the 1.4.11.1,
and I'll even leave myself a to-do,
take this line out after we made sure.
I'll go ahead and hit "Play".
All right. Let's give it a try.
Going to login, vulnerable components,
and I'm going to just take this payload from before,
paste it in here,
and I'll even bring up
the terminal where I'm running the Python HTTP Server.
I'm going to clear out the terminal
just so it's easy to see.
Going to hit "Go",
and nothing comes up here,
but I also didn't see a response here.
So it sounds like something may have broken,
and if we look at what gets returned is an exception.
DOCTYPE is not allowed for this feature.
So there's another exception up
here where for the serverlet,
and there's a disallowed DOCTYPE.
But at minimum, we know that we're
using the right version of the library.
So if we go through
the code to see where the exception was thrown,
and it looks like it was when we were parsing in the XML.
Now, let's go ahead and try it real.
This should work, this is an example
of something that should be allowed,
and let's see what we get there.
I'm going to clear out the console of my IDE.
We get security framework of XStream not initialized,
XStream isn't probably vulnerable.
Okay. So what does that mean?
Well, XStream at least is nice enough to
give us a warning when this is the case,
but if we actually read the documentation
just using the most up-to-date version of XStream,
does not protect us.
So we need to do a couple of other things.
I'm going to take this line out
since we know it works properly.
But we need to ask XStream
to set up default security on our instance of XStream.
So this XStream is our instance.
Now, if you can go ahead and run this,
this is in their documentation,
and it asks you to do this for security reasons.
But if even if you ran this,
you would have another error.
So to prevent that error,
we need to tell XStream what items,
what objects we're going to allow for it to pass.
So we're going to ask our instance of XStream.
Remember, on this line,
I'm actually using a capital X,
XStream on this line.
I'm doing a lowercase xstream.
We're going to tell it that the allowed types that it
can use are the following classes.
I'm going to create an array of classes,
and I'm going to feed it my contact.class.
So essentially, any other class other than
contact.class will not be allowed.
So when it comes down to here,
we should only see contacts be the thing that gets
allowed and everything else disallowed.
Now there's a conversion exception that this class is
watching for and it's looking
for the word integer in the class.
I'm actually going to catch
all other exceptions just so
we can see what comes out of here.
I can actually use the same return line as above,
and then I'll just strayed catching.
Actually we can give the feedback of ex.getMessage.
So the feedback we get on a failure is
going to be the message
that the exception was created with.
So I'm going to recompile.
All right. Now that we have started,
I'm going to go back to WebGoat.
I'll do a refresh just so I get a new page.
So the thought here
is that this should work perfectly fine.
We hit "Go", and we don't see any errors.
So obviously, this has no feedback,
but we just don't see any errors which is good.
We'll try our bad payload.
I'll bring up my terminal so that we can see,
and you can see that it
fails to do anything bad with that.
You will see a bunch of errors in your IDE,
and the errors are coming from
the fact that this EX doesn't have
the right messaging that it wants for
the feedback to append to it.
It's not a big deal, we can obviously just
do catch exception, track feedback,
and just give the same message that is
returned that the web designer behind this used,
and that'll be sufficient.
It's a little bit misleading,
but we can go with it.
If we just recompile,
our web code session comes up.
Okay. Looks like it's up.
Just refresh that page to make sure we get a new.
I going to clear out my console,
get our bad payload,
put it in here hit "Go",
and we don't get a large exception,
we just get fatal error.
DOCTYPE is not allowed when the feature is used,
and this is something that gets enabled
when you are using set default security.
I hope you enjoyed this and we'll see you next time.
So that concludes our last demo screencast of me
showing you how I went about patching this vulnerability.
Now that you've seen how I did it,
it's time for you to give it a try.
Also remember, there's a discussion thread where
your fellow learners are discussing what they're doing,
asking questions, and you can share what you've learned,
and you can learn from the others.
Have fun patching and help your peers.