This week, we have a detailed write-up on finding credit card numbers leaking from a GraphQL API, a lab walkthrough on hacking JSON web tokens (JWT) through SQL injection, and HackerOne’s new Capture The Flag (CFT) API Security challenge. On the resource side, we have another good mind map, this time on XML attack vectors with APIs.
Case study: Cracking encrypted credit card numbers exposed by an API
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.
Lab walkthrough: Hacking JWTs with Blind SQLi
JWTs are one of the most frequently used methods to pass caller information in authentication tokens of REST API calls. When
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.
Capture the Flag: API security
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.
Mind map: XML attacks
APIs that accept XML payloads can be exposed to various XML-related attacks if they do not properly define and validate these payloads.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy