The trouble with JWT

Jun 22nd, 2016

Comments: 0
Category: Uncategorized

The trouble with JWT

I ran across a test using JWT (JSON Web Tokens) for authentication/authorisation recently.  This was the first time I had seen a site using this, and it was quite interesting to compare it to oAuth (it is certainly a bit simpler).

There is a good site for decoding these here:- https://jwt.io/ but basically they are made up of three sections, a header, the payload and a signature.

On the site I tested, the username and password were submitted in an HTTP POST to the server which set a session cookie in the browser.  This was then presented to the authorisation service which created the JWT token which was then passed to the server in an authorisation header with every non-public request.  The slight twist to this compared to other token based systems I have tested, was that the token was invalidated after a single use, so after each request the browser had to resubmit its cookie in order to get a new token.

There were a couple of consequences.  Firstly it made it quite hard to test in any kind of automated way, because the scanner needed to get a new token for each request and insert it in the head; this isn’t something Burp is able to do at the moment by default.  Luckily I know a good Ruby developer and he fired up a solution for this as documented here – https://raesene.github.io/blog/2016/06/19/Burp-Plugin-JWT-Tokens/.  Plugged into a Burp Macro this did the job brilliantly.

The second one was a security flaw in the system as implemented on this particular site.  The original cookie which was created on receipt of the login details had not been treated with the respect that it deserved, presumably because it wasn’t directly used in the authorisation process.  What no one had noticed was that it could itself be used to generate an unlimited number of JWT tokens, it had had its expiry date set to a whole month in the future, and it didn’t have either the Secure or the HTTPOnly flag set on it.  This effectively broke the logout mechanism for the site and meant that the cookie was lying about in a valid state in the browser for the next month, ready and able to create the tokens for authorising requests.

 

Add a comment

Your email address will not be shared or published. Required fields are marked *