API Security Fundamentals
Intro to API Security
API stands for Application Programming Interface and can be used both externally and internally. For example, booking a taxi ride through Google maps or sending money through a payment app, would represent the external use of APIs: they are shared across organizations. APIs also power our internal apps, the microservices. For instance, an authentication microservice can be exposed to third parties, to trusted partners and customers who may want to integrate with your platform.
The image below shows reasons of why API Security should be carefully considered:
In the schematic below, we have the backend app where all the data lives along with the app’s functionality. The latter gets exposed to the users through APIs. Thus, APIs represent a central choke point via which the data is flowing between the interfaces and the backend.
Unlike attacking a web app, an attacker can directly find and attack an API, and if successful, would be able to access sensitive data.
Anatomy of Real-World API Breaches
Below are some examples of real-world API breaches along with some brief details of their main causes.
Coinbase
In this case, the research intercepted the traffic between the web interface and the backend and identified the API calls. He was able to discover 4 transaction parameters that he was able to manipulate (image below):
He essentially overwrote the source_account_id with an acc that did not belong to him (API1:2023 Broken Object Level Authorization). This bug cause was a missing logic validation check: the app wasn’t confirming that the user submitting the transaction owned the accs related to the transaction.
Peloton
In this example, an API was active that the company did not expect anyone to use as it requested no authentication for calling it (API2:2023 Broken Authentication). In addition, a user can ignore the private marking of the acc via the API and gain full access to the entire database (API1:2023 Broken Object Level Authorization). A researcher reported this issues: the former issue was fixed by adding authentication, but the latter was not addressed at all.
Venmo
The app’s homepage had a feature that showed the more recent real-time transactions (without revealing any PII). A researched intercepted the traffic between the homepage and the backend and found the API that this feature was based on. He could call it directly without authentication (API2:2023 Broken Authentication). In addition, the API would return PII instead of stripped data (API3:2023 Broken Object Property Level Authorization). The cause of that was that the filtering was happening at the UI instead on the app level. Futhermore, the researcher was able to call the server up to 115k times per day and harvest 200 million transactions in full detail (API4:2023 Unrestricted Resource Consumption).
The app had an API linked for the password reset functionality. If a user tried to reset the password, the app would send an email to that user with a 6-digit code. It turned out that the 6-digit code could be supplied through an API back to the app’s server in order to reset the acc (API3:2023 Broken Object Property Level Authorization).
The attacker could request to reset the password of another user. The 6-digit code would go to the acc’s legimate owner, but the attacker was able to brute-force all 1 million combinations of that code. Instagram had some rate controls which limited the number of guesses to 200 per IP address, but they did not have any limitation on the number of guesses across multiple IP addressess for the same acc. The attacker simply rotated IP addresses after every 200 guesses, utilizing up to 5,000 different IPs to get through all 1 million combinations and take over a user’s acc (API2:2023 Broken Authentication).
Bumble
In this case, the API completely lacked authentication (API2:2023 Broken Authentication). In addition, it was using incremental IDs for its users, and not alphanumeric randomized IDs which cannot be easily predicted (API1:2023 Broken Object Level Authorization). What’s more, the data returned was very detailed and included the distance from the requested to the user being searched. The attacker was able to pinpoint a user’s location by creating 3 different accs (triangulation).Finally, the attacker had function-level access, such as UPDATE and DELETE, functions that should not be available to end users at all (API5:2023 Broken Function Level Authorization).
Experian
This case reveals the exposure risk that APIs can have from third parties (API9:2023 Improper Inventory Management). Experian created an API to provide to their financial partners, but one of them decided to expose it directly through their website. A researcher could call the API directly, and not through the website, without authentication (API1:2023 Broken Object Level Authorization). Furthermore, they could find a user’s credit score using just a name and address (the existing DOB field was just a placeholder and would accept any value).
Conclusion
Most of these breaches was caused by API1:2023 Broken Object Level Authorization and/or API2:2023 Broken Authentication, which it is odd in the sense that these should be first vulnerabilities to test against when developing/testing an API!
OWASP Top 10 API Security Risks – 2023
API1:2023 Broken Object Level Authorization
The most common and most damaging vulnerability. An authorization issue:
userAis properly authenticated, but instead of having access on just his own data, he has access inuserB’s data as well.API2:2023 Broken Authentication
Not just non-existent authentication, but also weak authentication practices.
API3:2023 Broken Object Property Level Authorization
The merge of mass assignment (ability to update object elements) and excessive data exposure (revealing unnecassary sensitive data).
API4:2023 Unrestricted Resource Consumption
Formerly known as Lack of Resources and Rate Limiting: abuse of APIs due to high volumes of API calls, large requests, etc.. Can lead to DoS attacks and mass data harvesting.
API5:2023 Broken Function Level Authorization
Abuse of API functionality to improperly modify objects (similar to mass assignment (API3)).
API6:2023 Unrestricted Access to Sensitive Business Flows
Abuse of a legitimate business workflow through excessive, automated use. Examples: mass automated ticket purchasing (buying all inventory as soon as it is published and locking other users out).
API7:2023 Server Side Request Forgery (SSRF)
API8:2023 Security Misconfiguration
API9:2023 Improper Inventory Management
You need to have a comprehensive and accurate view of your API environment - all the APIs that are running, all the endpoints, versions, older versions, who’s accessing them, etc.
API10:2023 Unsafe Consumption of APIs
Exposure via the use of third party APIs. Example: an attacker inserts malicious data on the third party API that you use and then submit a request via your API to specifically pull that data.
The 3 Pillars of API Security
First Pillar: Governance
Governace is about defining, establishing and enforcing the processes of developing APIs, testing APIs, and getting them into production in a consistent and secure way.
Documentation** should be mandatory and well-defined. OpenAPI Specification (OAS), aka Swagger, is the industry standard for documenting REST APIs. Below is a raw YAML/JSON file of a Swagger (left) and how it looks like in a visual interface (right).
Second Pillar: Testing
Testing is about ensuring that your APIs perform as expected and are free of flaws.
Best practice is to make API testing part of your overall testing program alongside unit testing, functionality, performance, etc. The “standard playbook” tests tends to look at things that are not so common in practice, such as XSS, buffer overflow attacks, injections, etc. The most common cause of real-world breaches comes from logic flaws in the app. API First-Testing changes what’s historically being done: app testing has focused on the UI layer itself, but attackers can simply ignore that and attack the APIs directly. It’s not really an abuse of the UI layer but an abuse of the API layer that causes breaches, such as lack of authentication, lack of authorization, etc.
Third Pillar: Monitoring
Monitoring is about checking if they are behaving as expected during runtime.
Monitoring appoaches can be:
- Proactive - Blocking: you can enforce policy.
- Reactive - Alerting: you might not have enough context to make judgements about the traffic’s nature. For instance, in the Coinbase breach, the HTTP request had nothing abnormal in it.
Cybersecurity Landscape
In the middle is where the biggest gap has existed in terms of security: API security testing. Web app scanners are designed to interact with web/mobile interfaces, but APIs don’t have any. So you need to implement comprehensive, effective security testing at the API level. And you want to accomplish this “left” of this dotted line.
Conclusion and Best Practices
