[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.