The worst API ever?

As we approach the end of the year, it's often the case that we look back and chat with colleagues about the highs and lows of the last twelve months. One such friend recently shared a story with us about the worst API they found in the wild during 2023. Could this be the worst API ever?

We all know that APIs should have a concrete and carefully planned design that meets certain usability and, most importantly, security criteria. The foundation of API development is a carefully structured design with specifications and proper documentation that offers clarity to the developers. We all know that right?

Well, this is a story of how the most basic security holes and design flaws can expose an API to massive vulnerabilities. And how such simple errors can have dire consequences.

The API in question was an internal API, used for aggregating medical documents from customers. It includes medical bills and exam results, which also means an enormous amount of PII. Each employee of the organization has an account with which they can access the web application that utilizes this API for managing the customer documents.

With more than 36,000 individual customers, we are talking about a lot of sensitive medical  information.

For this, or any organization, managing customers’ PII and sensitive data is critical, not only because of regulatory requirements but also for ensuring customers' trust and avoiding the reputational damage associated with leaking sensitive medical data.

Flawed login design

At the crux of this vulnerability, which was fortunately discovered during a periodic pen test by outside contractors, was a flawed login design.

The API handled the login process of the web application. The web application front-end prompted the user to input their credentials, i.e. a username and a password, to login. A common username/password pair that web application developers use is admin:admin. It is a common mistake for developers to leave default and/or easy passwords on important application accounts, so that they don't lose access if someone forgets the password.

Submitting the username/password pair would allow any user to login with the admin:admin credentials. But is this a case of default/weak credentials? Looking at the raw HTTP request to the API revealed that:

POST /api/v1/login

{"user":"ADMIN"}

The API server was only validating the existence of the username. Thus, any attacker who knew any username could gain access to that account without the needing a password.

This issue was the product of bad design and bad development team communication. Applications that offer password fields often foster a false sense of total security. Keeping updated documentation and communicating the development status between the engineers would probably have prevented such a mistake.

Internal APIs are just as important as Internet-facing APIs. Although the risk of exploiting a vulnerable API on the internet is great, there are equally devastating risks within a corporate network, such as compromised machines, and insider threats.

Unlimited access through unauthenticated SQL injection

The previous vulnerability required the attacker to know an application username. Even though they could access the ADMIN account, there were other accounts worth exploring, such as accounts with "SUPERADMIN" rights.

The login endpoint was vulnerable to a simple SQL injection.

POST /api/v1/login

{"user":"' or '1'='1';#"}

This not only allows the attacker to authenticate as the first user in the database but also for the application to return all usernames registered in the database, along with their access rights. Among them were also "SUPERADMIN" users. The combination of the two findings would allow an attacker to gain unlimited access to any account in the application and disclose any PII found there.

SQL injection is part of the 2019 OWASP API Top 10, but not the 2023 API Top 10. Perhaps injection should have remained on the list, as it is encountered often on production APIs. Following coding security best practices, input filtering and validation, and utilizing API protection tools can protect your organization from injection and malicious input issues.

Mitigation and recommendations

Organizations that are building modern, API-backed web applications need to assume that attackers can and will find the API backends. Organizations should also assume that the attackers will use increasingly sophisticated and automated tools to launch attacks - from credential stuffing to injection to unauthenticated abuse - against the API.

With this in mind, organizations need to maintain continuous visibility over all the APIs in production and in use, as well as constantly testing the security design of the APIs for common risks like these. 

If you want to get on top of your API security to avoid catastrophes like this, make sure to schedule your free demo with FireTail here. See how FIreTail can help you take charge of your security posture and stay on top of it for 2024.