Issue 144: JustDial API vulnerability re-emerges, API key checker, the state of OAuth

JustDial had a regression as they accidentally reintroduced the API vulnerability that they had fixed (and we reported) back in 2019. Ironically, it was found and resubmitted to the vendor by the same reporter as last time, Rajshekhar Rajaharia.

The vulnerable endpoint got re-introduced at some point in 2020 and had been leaking user data — such as names, email addresses, mobile numbers, addresses, gender, dates of birth, photos, occupation, and company names — for months. It is unclear whether anyone has taken advantage of the vulnerability.

As we mentioned when originally reporting the issue, even back in 2019 this was actually not an API used by JustDial apps. Rather, this was some sort of unused old API that was accidentally left behind and that provided unprotected access to the production database.

Lessons learned:

• This can serve as an example of OWASP API9 — Improper Assets Management. Make sure that things you no longer need are properly retired.
• Like any bug, security issues can come back unless you have automated testing processes to prevent this from happening. Use the DevSecOps approach and tooling to set up the process also for API security.
• Ensure that only production APIs can access your production database: use mutual TLS authentication, IP allowlisting, and so on.
• Ensure that all your APIs have proper authentication and authorization in place.

Leaked API keys remain one of the primary vectors of API breaches. Because of this, penetration testers often automate the search for API keys.

To make the discovery effective, it makes sense to also automate validating the found API keys: verify that the keys are indeed valid, still functional, and give access to the target system.

Muhammad Daffa has created an open source project called Key-Checker that validates the API keys that you find across 37 different systems, including Facebook, GitHub, MailGun, SendGrid, Stripe, Twilio, to name but a few. So if you are looking to make your pentester life slightly easier, do check this one out.

The conference apidays has published the recorded session “The State of OAuth” by Aaron Parecki.

Parecki is one of the creators of the OAuth standard and deeply involved in its maintenance and evolution. OAuth 2.0 — along with OpenID Connect that is based on OAuth — is the foundation of modern API authentication and delegated access. Yet, it can be quite confusing because of all the standards, technologies, and implementation options around it.

In his session, Parecki covers the origins and goals of the OAuth 1.0, OAuth 2.0, and OAuth 2.1 standards (RFCs) that define OAuth, adjacent technologies, tokens and their security, upcoming standards and extensions, and the upcoming Grant Negotiation and Authorization Protocol (GNAP). Worth watching if you are interested in how OAuth got where it is and what’s next.

Another great recording this week is Dolev Farhi’s “Damn GraphQL – Defending and Attacking APIs” from BSides Vancouver.

Farhi is the creator of the Damn Vulnerable GraphQL Application (DVGA) that we covered in our issue 121 so he definitely knows a lot about GraphQL security.

In the video, Farhi explains the attack surface of GraphQL, the measures that API providers need to take to prevent exploits, his DVGA GraphQL vulnerability sandbox. To demonstrate the dangers of GraphQL vulnerabilities he even demos a simple GraphQL request that brings down a WordPress server that has a GraphQL plugin deployed.