[MUSIC] Hey, everyone. Hopefully you had an opportunity to
try to patch this vulnerability. And the trick to it was understanding
what the parse method is actually doing. The parse JWT simply
tries to parse an access token into a JWT or JWS,
whichever fits best. So it doesn't necessarily know,
when it's parsing, that it needs to validate the signatures. And if it doesn't see that in its
header it has an algorithm to find and a signature provided, it will fail to, it will never verify and
validate the signature. So we know that based on their
documentation, they told us so in multiple places here. And the way we know what to do is
through this hints that we got. The JWT tokens by themselves
don't need to have a signature. So in order for a token to be valid,
it doesn't require a signature, it's not part of the specification. So a JWS is what we want. So from that,
we simply change parse to parseClaimsJws, we're specifically asking for
them to validate our signature for us. Now, there's a jwsException and
it's catching all the exceptions. I'm going to get a signature
exception as well, just because it's the right thing to do. Let's see, We are catching that, and I can ask for
a signature exception to be caught. Of course, this needs to be further
up in order for it to work, so I'm just going to cut this and
put it right here. And we still fail, but we're going to
provide a different type of message. And we're going to call our message
jwt-invalid-token, Signature Failed. So that'll be the feedback,
and then it'll output and it'll append the actual vulnerability to
this, or I'm sorry, the exception to this. So let's try that out. I'm going to hit play here and
let it compile for me. Now, while that's compiling, I want to
remind everyone that we did go in here and manually assign the Tom user
the admin privileges so that we can test both the functionality of this that
we didn't break it for the good users. And that we're going to keep
everyone else as admin false, making sure that, yeah,
it does fail when they're not admins. Another thing was, when we went through
the exercise of actually exploiting this vulnerability, the user that I pulled out
and I have in my repeater was Sylvester. So this token that I have created for
Sylvester is the token we're going to use to attack this so that we don't have
to do all these steps all over again. Finally, in my repeater, I have the same token that we created,
and you saw right here. However, this JSESSIONID is something
that belongs to WebGoat in general, not something that's relevant to
any particular lesson at least, at least not the JWT lesson. So sending this payload may not work
simply because I'm using a old JSESSIONID, and we can replace this and
not have to mess around with much else. One other thing I want to mention is if
you chose a different user other than Tom to be your admin. Make sure when you're testing in Burp, you're not testing with a token that
we modified for this now admin users, since that could be an edge case
that gives us a false positive. So with that said, this is compiled, and it's running, and
I'm going to relaunch it. I'm just going to click WebGoat >
Authentication Flaws > JWT token, and we're going to test some functionalities
just to make sure everything works. So if we vote as a guest, it doesn't work. If we vote as Jerry, it works just fine. However, Jerry cannot delete,
only admins can do this. If we go to Tom, Tom can vote and Tom can delete because Tom is an admin and
we've allowed that. And lastly, if we go to Sylvester, Sylvester cannot
delete because Sylvester is not an admin. Going back to Burp,
I'm going to go to my proxy and go towards the very bottom, this is
the request we just sent for Sylvester. Now, I don't want to redo this access
token, we already redid it once and it should be sufficient. I'm going to copy this new JSESSIONID
since that belongs to WebGoat and not necessarily this lesson. And I'm going to go to my repeater, I'm just going to simply replace
the old session ID with a new one. So previously when we tried this,
we got a true, that worked for us. If we hit Go now, we'll get a false, and we'll get, that's not a valid JWT session,
please try again. So we have successfully
patched this vulnerability. Now, there's a couple other ones in here. This was for the reset, however,
the same thing happens for the delete, which is final endpoint. And we want to make sure that we're
doing exactly the same thing here. So we don't want to be parsing, we want to be parsing the JWS claims and
passing that token. So that's how we verify this. There's other ways of going about this, you may have used
the auth0 verifier class. In fact, if you were on this page,
you probably, the next thing you did after looking at
this resource was Google JWT verifier. And there is an instance of it by auth0,
and you could have used this verifier to
verify this, this was a lot easier. If you were going to go this route
to go verify using the JWT verifier, you would've had to
modify the Maven file and included that package both
in the lesson for JWT, as well as the lesson's parent class so
that it was included. So that when we're building the entire
project, it would be included and verified. I hope you enjoyed that, and
we'll see you next time.