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.