Hey API! What you Token?

Technology is always evolving with some of it widely adopted, while others never get implemented. In some cases, the technology adopted for the sake of the latest and greatest is implemented incorrectly, resulting in security flaws. This latest [insecure] technology adoption trend we are seeing is data buried in API requests utilizing JSON Web Tokens (JWTs), but not protected properly. Let’s look at JWTs and how they can be used in API transactions.

Originally designed for machine-to-machine information transfer, APIs are now the underlying data transfer for most all public-facing applications. Threat actors can easily discover API endpoints by watching transactions in an intercept proxy or taking the mobile application apart or finding the APIs in GitHub. As always, protecting data in transit is a priority, but organizations that have used, but may no longer trust a single SSL/TLS certificate to do the job now have an alternative in JSON Web Tokens.

JWTs are funny-looking transactions that start with “eyJ”, which is a bracket ({) in base64 encoding. They are powerful additions to APIs that allow data to be transferred as part of the Query String and can contain secure data – analogous to port 80 GETs with secure data in them. JWTs are not quite as insecure as HTTP but, they are getting used more and more as GET query parameters. For example, GET www.example.com/user/?eyJ where once “bigstring” was decomposed we would find {User:bob Admin:No submitted at X time}, as highlighted in the image below.

I know that you are thinking, “this is mind-blowing stuff, carrying data in a simple string”, why isn’t it used everywhere? Just slow down a bit and we can talk about security here. If in this transaction, it wouldn’t matter that the username was known or the role, as in, if you weren’t hiding this data anyway. Perhaps in a search for a public object, then we are all good. We CAN make this more secure but using the default on a random website isn’t going to necessarily be the best thing for us. JWTs don’t ensure security and they shouldn’t be considered secure without a few more pieces in place. JWTs, like all new technology, need to be designed and implemented with security in mind.

To ensure the use of JWTs is secure, we first need to understand implementation. This is data that contains a signature to ensure it is valid, but nothing is protecting the data in flight, no encryption had occurred. Threat actors can attack this by simply manipulating the signature declaration and claiming the data is unsigned. Requiring a signature means it needs to be configured as such, placing an added trusted signature requirement on the client (as trusted as client-side data should be).

Another consideration is Cross Sight Request Forgery. Yep, you read that right. No longer on the OWASP Web Application Security Top 10, CSRF is back. CSRF is possible because the web server is no longer issuing tokens because the validation of the user profile is done by the JWT. And all the other OWASP concerns are still valid. Enabling JSON Web Tokens does not automatically bring additional security. They are however a better way to validate client-side data in transit, nothing more, this isn’t an XSS filter or Authorization standard. This carries tokens to validate the data. When implemented correctly, JWTs introduce some very powerful authentication enhancements – federated identity, managing session tokens, and resetting a session at any time – which in turn allows for finer control of active users and on-demand authentication refresh.

JWTs also introduce some very powerful encryption options, deciding what kind and how to implement encryption will require knowledge of the data and what it can access. JWTs are a great way to utilize ephemeral data and utilize encryption of the data in transfer. Brute-forcing the transaction could still be possible but the concept of ephemeral data allows for this time period. The type of encryption needed, and the key management are obviously going to matter, the consideration for the data shouldn’t. If handling certificates, for instance, the management of the certs, how to retire them, how to implement a different type of cert, revocation, etc. is a discussion that shouldn’t include whether the data is worth it. Loss of data in transit should be the higher priority.

So, if you are implementing JSON Web Tokens as an alternative to SSL/TLS or as a means of shortening the validation of client-side data, or to transport sensitive data in a more encrypted and validated way, while saving in processing and transport time, good for you. If you are looking for a more encrypted solution for web application traffic due to privacy concerns, JWTs are a great place to start.

No matter what your goal is, make sure you follow secure API and JWT coding best practices like those outlined by OWASP here so that your implementation cannot be changed by an attacker and maintains the desired integrity, confidentiality, and availability.

In the meantime, check out how API Sentinel can help you discover, analyze and protect your APIs: