Before trying out this exercise it’s important to follow its instructions and go read this bug bounty write-up article https://emtunc.org/blog/11/2017/jwt-refresh-token-manipulation/
What we want to do here is to order books as Tom, let’s see what happens if we just press “Checkout”
As of now, there is no JWT token present in the request and the webapp responds accordingly by telling that there is no valid JWT token in the request
By going through Burp HTTP History you may notice that when loading the lesson page, some interesting information appears
This is a weird behavior but I think this challenge has been engineered this way so that by going through the request/response list the user is able to obtain a JWT token
By having an access token and a refresh token it is possible to try and see what happens if we request the checkout page with alg: “None” and substituting user: “Jerry” with “Tom” and no signature
But first, let’s see what happens if this token is used without changes in the POST for the checkout
The user is identified as “Jerry”, let’s try again by tampering with the JWT token -> alg: “None” and user: “Tom”
I am not sure the lesson should give me this response when I change user “Jerry” in the JWT token to “Tom” and doing a alg: “None” attack
As far as I understand by reading other people discussions on the web about this lesson, what we are supposed to do here is to ask for an access token renewal using “Tom” access token present in the given log and “Jerry” refresh token obtained by loading the lesson page
So let’s reset the lesson and complete it the way it is supposed to be done
From WebGoat source code on GitHub (you can call this cheating), this lesson is https://github.com/WebGoat/WebGoat/blob/develop/webgoat-lessons/jwt/src/main/java/org/owasp/webgoat/jwt/JWTRefreshEndpoint.java
Here we can see the endpoints for this lesson:
- /JWT/refresh/login -> follow() function
- /JWT/refresh/checkout -> checkout() function
- /JWT/refresh/newToken -> newToken() function
In newToken() the webapp checks for an “Authorization” POST header with a JWT token and a JSON HashMap in the data section
If these are present, the function parses them from the JWT token and checks for their validity, if all goes well the function returns a new user token via the createNewTokens()
In constructing the request for a new Tom JWT token, it’s important to notice that, from the WebGoat newToken endpoint function source, the function will be called when
- it receives a POST request -> @PostMapping
- the request contains an Authorization header, here highlighted you can see Tom’s access token from the given log entries
- the request Content-Type header is set to application/json (otherwise the request would simply be rejected)
- the request contains data in JSON format having access and refresh tokens, here highlighted you can see Jerry’s tokens copied straight from the /login endpoint response in Burp History
Perfect, the webapp gives a new pair of access and refresh tokens
By putting Tom’s new access token in the Authorization header for the /checkout endpoint request, the lesson is completed
I find important to notice is that, if I try to send the same request for a new token again, I am not authorized to do so, this is because Tom’s token from the log is not valid anymore, while before requesting a new token it was just expired but still valid, now it has been replaced with the one I obtained and used for the checkout, so I get a 401 unauthorized response
This concludes WebGoat JWT token 7
I hope you liked it.
PVXs — https://twitter.com/pivixih
