Issue 143: GraphQL API leaking credit cards, SQLi in JWT, XML attacks mind map 🗺️

Craig Hays has published a fascinating write-up from his recent pentesting in a private bug bounty program.

The company allowed their customer to store their credit cards for ease of use. Hays managed to retrieve and decode credit card numbers that the system stored for all their customers.

The application used a GraphQL API under the hood. Hays found the ‘about me’ call that was susceptible to Broken Object-Level Authorization (BOLA) attacks. He could call that endpoint to enumerate each user in the system and retrieve their profile information.

He found that the API exposed much too much data on each user and even returned stored credit cards on file. The credit card numbers were encrypted. However, Hays noticed that the encryption was 2-way and unsalted, meaning that supplying a specific credit card number to save would always return the same, specific encrypted version of the number.

Considering that the credit card numbers are not completely random but conform to an international standard, he could create a script to enumerate all possible credit card numbers and create a rainbow table of their encrypted counterparts in the system. With such a table, he could then decrypt each card number he got from the API to cleartext by simply finding it in the table.

As Hays notes in his write-up, the main lesson learned here is again to tightly lock down your API responses and avoid exposing any more data than strictly necessary. Other things to consider:

• As always with cases of BOLA, make sure that on top of authentication, the authorization checks are in place and enforced, so that users can only access data they are supposed to.
• Rate limiting can help prevent easy enumeration with a flood of calls. We discussed in our last week’s newsletter the quirks of rate-limiting with GraphQL APIs.
• If using encryption, make sure to use modern best practices: adding salt to randomize the results, and so on.

JWTs are one of the most frequently used methods to pass caller information in authentication tokens of REST API calls. When JWTs retrieve signing keys from a database using the keyID (kid) header, this itself can become a SQL injection attack vector.

If the API implementation blindly uses kid to retrieve the key from a database, attackers can pass a SQL injection such as “non-existent-index’ UNION SELECT ‘ATTACKER’; --“. Unsanitized SQL request like this will produce “ATTACKER” as the retrieved value. Thus, API would now be verifying JWT signature with the value that the attacker supplied – making it possible for the attacker to forge any tokens they like.

Shivlam Bathla from Pentester Academy has put together a great lab “Hacking JWT Tokens: Blind SQLi” for hands-on experience.

For those too busy to try this themselves, there is a step-by-step walkthrough on how the lab and the attack progresses, but you can also just read the intro for the task description and try to figure it out yourself with the lab.

If you need an overview of JWT and possible JWT attacks, see the recording from my JWT security talk at AppSec California 2020. Isabelle Mauny and I also did a webinar on the approach to externalize JWT security checks.

CTF challenges are fun security quests and a great way to test your penetration testing skills in action.

HackerOne has just released a new “RTFM”-level CTF by Adam Langley, specifically dedicated to API security. If you are looking for a fun way to hone your skills, check it out.

APIs that accept XML payloads can be exposed to various XML-related attacks if they do not properly define and validate these payloads.

Harsh Bothra has put together a mind map of possible XML attack vectors, both as an XMind map and a PDF. Many of the attack vectors also provide reference links to further reading.