When developing APIs for fortune 500 companies, developers often forget measures that ensure that their APIs don’t expose their data or the architecture of their backend. This measures are so simple to enforce but when neglected it leads to massive breaches of their APIs. for example, forgetting to enforce a rate limiting of reset password functionality which requires a 4-Pin digit code to verify can cause the hacker to end up trying all possible combination of the pin which takes up to 10,000 request. Or allowing an authenticated user to access other user’s data and to perform actions that only an administrator to the website can lead to massive breaches.

In this blog, I’ll walk you through 8 of the OWASP TOP 10 vulnerabilities and how we can avoid them.

1. Broken Object Level Authorization Vulnerability

Occurs when an API provider allows an API consumer to access
resources they are not authorized to access. If an API endpoint
does not have object-level access controls, it won’t perform
checks to make sure users can only access their own resources.
When these controls are missing, User A will be able to
successfully request User B’s resources. APIs use some sort of
value, such as names or numbers, to identify various objects.
When we discover these object IDs, we should test to see if we
can interact with the resources of other users when
unauthenticated or authenticated as a different user. For
instance, imagine that we are authorized to access only the
user Cloud Strife. We would send an initial GET request to
https://mywebsite.com/api/users?id=100 and receive the following response

{

“id”: “100”,

“first_name”: “Jane”,

“last_name”: “Doe”,

}

But looking at the id, which is 100, Say we are able obtain information about another user by sending a request for https://mywebsite.com/api/users?id=101 and receiving the following response

{

“id”: “101”,

“first_name”: “John”,

“last_name”: “Doe”,

}

This vulnerability is also called an IDOR. We can avoid this type of vulnerability by changing the primary key of the user, for example, the id and generating random characters or that are unique identifiable to a specific user

2. Information Disclosure

When an API responds with sensitive information with unprivileged users, this is called information disclosure vulnerability. Sensitive data can include any information that attackers can leverage to their advantage. This sensitive data may include the users’ role. For instance, consider the following request:

{“id”:2,”name”:”Vincent Valentine”, “role”:”admin”}

Information may be disclosed in API responses or public sources such as code repositories, search results, news, social media, the target’s website, and public API directories.

Another common information disclosure issue involves verbose messaging. This might include Error messages. These messages can reveal sensitive information about resources, users, and the API’s underlying architecture (such as the version of the web server or database). For example, say you attempt to authenticate to an API and receive an error message such as “Invalid User ID” Next, say you try another email, the error message changes to “incorrect password.” This lets you know that you’ve provided a legitimate user ID for the API. The attacker can then conduct a phishing attack with the user email.

3. Excessive Data Exposure

Excessive data exposure is when an API endpoint responds with more information than is needed to fulfill a request. When a consumer requests specific information, the provider might respond with all sorts of information, assuming the consumer will then remove any data they don’t need from the response. This vulnerability is equivalent to asking someone for their name and having them respond with their name, date of birth, email address, phone number, and the identification of every other person they know. Consider the following response:

{

“id”: “100”

“first_name”: “John”

“last_name”: “Doe”,

“privilege”: “user”,

“representative”: [

“name”: “Don Corneo”,

“id”: “300”

“email”: “dcorn@gmail.com”,

“privilege”: “super-admin”

“admin”: true

“two_factor_auth”: false

]

}

Excessive data exposure is one of those awesome API vulnerabilities that bypasses every security control in place to protect sensitive information and hands it all to an attacker on a silver platter simply because they used the API. All you need to do to detect excessive data exposure is test your target API endpoints and review the information sent in response

4. Lack of Resources and Rate Limiting

Without limiting the number of requests consumers can make, an API provider’s infrastructure could be overwhelmed by the requests which could lead to a DOS attack. Too many requests without enough resources will lead to the provider’s systems crashing and becoming unavailable — a denial of service (DoS) state. Besides potentially DOS-ing an API, an attacker who bypasses rate limits can cause additional costs for the API provider. Many API providers monetize their APIs by limiting requests and allowing paid customers to request more information. Some API providers also have infrastructure that automatically scales with the quantity of requests. In these cases, an unlimited number of requests would lead to a significant and easily preventable increase in infrastructure costs.

An attacker can you bypass rate limiting by adding or removing a parameter, using a different client, or altering your IP address

5. Broken Function Level Authorization

Broken function level authorization (BFLA) is a vulnerability where a user of one role or group can access the API functionality of another role or group. In other words, BFLA can be a lateral move, where you use the functions of a similarly privileged group, or it could be a privilege escalation, where you are able to use the functions of a more privileged group. Particularly interesting API functions to access include those that deal with sensitive information, resources that belong to another group, and administrative functionality such as user account management.

BFLA is an authorization problem for performing actions. For example, consider a vulnerable banking API. If a BFLA vulnerability is present, you might be able to transfer money and update the account information. BFLA is about unauthorized actions. If an API has different privilege levels or roles, it may use different endpoints to perform privileged actions. For example, a bank may use the /{user}/account/balance endpoint for a user wishing to access their account information and the /admin/account/{user} endpoint for an administrator wishing to access user account information.

If the application does not have access controls implemented correctly, we’ll be able to perform administrative actions, such as seeing a user’s full account details, by simply making administrative requests.

Solving the problem by specifying in the user access token that defines the role of the users or user and restricting the HTTP methods a consumer can use, simply making an unauthorized request with a different method could indicate a BFLA vulnerability. These two methods can help prevent a BFLA vulnerability.

6. Broken User Authentication

These vulnerabilities occurs when an API does not have a strong authentication protection mechanism or the authentication mechanism is incorrectly configured. API authentication can be a complex system that includes several processes with a lot of room for failure. As developers, we often pass authorization tokens through HTTP headers of even request parameters and store then in the client side(browser) as cookies. An attacker can detect hardcoded tokens and once he finds the token, he can use it to gain access to previously hidden endpoints or to bypass detection.

The other authentication processes that could have their own set of vulnerabilities include aspects of the registration system, such as the password reset and multifactor authentication features. For example, Consider a password reset feature requires you to provide an email address and a 4-digit verification code to reset your password. Well, if the API allowed you to make as many requests as you wanted, you’d only have to make one million requests in order to guess the code and reset any user’s password. A four-digit code would require only 10,000 requests.

These however can be corrected by:

1. Rate limiting when authenticating

2. Avoid over exposure and verbose error messaging

3. Accessing resources after authenticated

For example, code committed to a GitHub repository could reveal a hardcoded admin API key:

“oauth_client”: [

{

“client_id”: “12345-abcd”,

“client_type”: “admin”,

“api_key”: “AIzaSyDrbTFCeb5k0yPSfL2heqdF-N19XoLxdw”

}

]

Due to the stateless nature of REST APIs, a publicly exposed API key is the equivalent of discovering a username and password. By using an exposed API key, you’ll assume the role associated with that key.

7. Injections

Injection flaws exist when a request is passed to the API and the API provider doesn’t do filter the input to remove unwanted characters. This flaw can cause SQL injection, NoSQL injection, and system command injection to your database and even backend infrastructure. If an send a payload containing SQL commands to a vulnerable API that uses a SQL database, the API will pass the commands to the database, which will process and perform the commands. The same will happen with vulnerable NoSQL databases and affected systems.

8. Improper Assets Management

Improper assets management takes place when an organization exposes APIs that are either retired or still in development. Improper assets management can lead to other vulnerabilities, such as excessive data exposure, information disclosure, mass assignment, improper rate limiting, and API injection. For attackers, this means discovering an improper assets management vulnerability is only the first step toward further exploitation of an API. An attacker can discover improper assets management by paying close attention to outdated API documentation, changelogs, and version history on repositories. Developers often include versioning information in their endpoint names to distinguish between older and newer versions, such as /v1/, /v2/, /v3/, and so on. APIs still in development often use paths such as /alpha/, /beta/, /test

References

Hacking APIs: Breaking Web Application Programming Interfaces by Corey Ball. https://nostarch.com/hacking-apis