Hey everyone? Hopefully, you were able to find the vulnerable code, and in this case logical flaw in this code. I'll walk through how I got there, and we'll talk about some of the issues with this code base. But we will go ahead and patch it even though it won't be the best patch that we can do. So the issue here is that, there is no back end to this. Obviously, this is just for a test case to demonstrate a very simple use case. So whether developers or Webgoat did this, they created a map. They're storing secret question zero, and secret question one inside of a map. Now, realistically you wouldn't be doing this in memory for thousands or millions of users, every time your application goes up or down, you can have to reset all those questions. You would probably have a persistent stores like a database that you would get this information from. So given that we're working within the confines of Webgoat, and how Webgoat was engineered to demonstrate a point to get that point across. We're going to fix this flaw, the logic of this flaw. Encode here. Now, realistically speaking, you would probably use a framework to do this. You wouldn't want to write this all from scratch yourself. But we'll walk through the flaw together and just see what we can find. So the verify account, the very first thing that it does, is checks to see if the result that they send is within the range of what they would expect, if not return false. That's a pretty sane thing to do. They would also check to see if security question zero was answered properly based on what they know security question zero's answer to be. Remember they put those in the map right up here. If the answer is" No" to any of those, they would return false. That's a fairly same thing to do as well, and then lastly, they do the same thing for question one, and if you answer those things falsely, it will return false. So within those three cases, you will not be able to log in. However, they fail open. Meaning. If the question that we submit is not question zero, or question one. Regardless of what the answer is, is that they return true. So what we want to do is, we want to change this, so that we returned false, unless they answered the questions properly. So how would you go about fixing this? So I'm going to comment this code out for now, just so that it's not in that way, and I'm going to say, I'm going to return false. Just to start with, this is going to be the very last thing that gets executed. I am not going to fail open. I'm going to fail close. So if for some reason even if my logic is broken, and I'm not appropriately qualifying questions, maybe I should be returning true. Maybe I didn't think of an edge case. That's okay. We can recover from that. We'll get a bug report. We can fix this. But I'm not going to fail open. I'm going to fail close. So the very first thing that they had was some code that essentially checks to make sure that the questions have been created properly, and validated, and all those things. I am going to leave that in there. The second part was to make sure if question zero, if a map contains a particular question, and it asked that the question was not answered properly. So I think we're going to want to return true for these, and we're going to turn that not into a positive. So I'm going to take this body. It's a very long one. So as long as we have the key, and they're doing this, so you don't get a NullPointerException, and the question zero was properly answered, we're going to return true. You got the right answer, and we're going to do the same thing for that. I'm just going to copy for question zero, and I'm going to modify this zero to a one. I did that with a shortcut, but essentially it's identical to checking for question zero, but now I'm checking here for question one, and I'm saying, make sure I have the key, and as long as I have the key, that means I have the answer. Check my answer against the answer I expect to have. Now, this is a little wonky, but just work with it because it has to work for Webgoat and how Webgoat was written. So let's think through our logic here. We know that we want to make sure our map is set up, and it's working properly. Realistically, wouldn't be working against a map. You could just pull, pull something like this from a database, but we're going to leave that in there, knowing that this is test code, and it's for educational purposes. We know that our answer zero needs to be answered correctly, and now we know our security question zero has, I'm sorry, security question one has to be answer correctly. So only in these two cases, will I return true, and if those two cases are not met for any reason, I'm just going to return false. So I'm going take this out, and let's give it a try. In fact, we can scroll up here, and we know what the answers are for security question zero and one. So after we test the cases that where we break it, we can actually test the cases where we don't break it. All right. Let's go ahead and open our Firefox. Going to open it up, in private browsing modes, so we don't hold any of the history of this authentication flaws, authentication bypass. So we were already successful in working through this. So I'm going to reset the lesson, and refresh the page. All right. So let's see if our burp is running, going to close some of these windows from yesterday, and then clear out some of this, perfect. So we are going through the proxy, and I'm going to turn on interception. I'm going to make sure that I'm only intercepting for posts. So I'm going to turn this off. Go in my interception, intercept does on, refresh the page, nothing should get in our accepted, because nothing was opposed by refreshing a page which we just did a simple get. I do test_1 and test_2 and we submit that, and that did get caught by our interceptor. We remember from exploiting this, we simply change security question zero to 22 or some other question, and 44. So the expectation here is that if I forward this, that it will not let me go and reset my password, and you notice that it says "Not quite, Please try again". Now, we want also to make sure that we didn't break the functionality. So I'm going to come and copy the actual answers to the questions from a code. Anybody Sherlock Holmes fans here, right, going to submit those, and it's caught by interceptor, so I'm just going to let it go through, and they caught it. They found out that we looked at the source code to get those answers. They know that we didn't actually break through this. So that's great. So we have now officially patch this. I want to close a video with saying that I know this seems a little wonky. This is Webgoat was meant to be a task. So some of the surrounding, construction, and engineering, and architecture around, how this problem is setup, is not normally how we would go about it. That's okay because we're again trying to fix a logical flaw, and the lesson here is to always fail close rather than failing open.