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.
