Web Application API Security

[META]

This is the dynamic analysis engineering department at Swordfish Security. In previous articles, we described the OWASP ZAP plugin , explained how to scan applications using Burp Suite Pro , and set up automatic authorization in the DAST scanner. Today, we'll discuss what to look for when checking web application API security. We'll approach this from the perspective of dynamic analysis, and in a separate article, we'll share the relevant tools. Let's get started!

Introduction​

During the security audit of a web application, there's a step where all possible points of interaction with it are collected. In addition to analyzing the frontend, it's worth checking how API communication is configured. Different products use this interface for different purposes:

• to connect the frontend with the backend
• for interaction between different applications of the same organization
• to provide access to the backend for third-party software, etc.

At the same time, the number of requests to application APIs is growing, and some of this traffic consists of requests from attackers.

The OWASP (Open Web Application Security Project) periodically releases a ranking of the top 10 categories of web application vulnerabilities. The first list was published in 2003, and the latest version was released in 2021. A similar report for APIs has been published since 2019. From the project description: "A fundamental element of innovation in today's app-driven world is the API." We recommend checking out this year's version if you want to stay up-to-date.

Where to start testing web application API security? Gathering information​

To begin, it's important to gather all the information about the APIs used, ideally having documentation for all interfaces. If there's a diagram for an external API, it's worth making sure there aren't any additional internal ones that the information security department wasn't initially aware of.

The protocol and data format used are particularly important for correctly constructing fuzz checks and API requests for critical data. Here's what to pay attention to:

• Is the REST approach used?
• In what format is the data transmitted?
• Is there an API with SOAP, GraphQL, or gRPC protocols?

It's also important to gather information about deprecated or unused APIs that may not have been disabled. It's also worth talking to the development team and obtaining older versions of the specifications. You can also try different API versions yourself. For example, given the URL /api/v1, you should look at the server's responses for v0, v2, v3, and later. It's also a good idea to brute-force endpoints using dictionaries of popular API keywords, paying attention to any non-standard responses.

Authorization check​

Several categories of major vulnerabilities from the OWASP API Security Top 10 list are related to improperly configured authentication. Therefore, it's important to implement standard checks to ensure secure protocol usage and generate random tokens of sufficient length. Ensure the backend verifies tokens in requests for all endpoints that should only be accessible after authentication.

In addition to checking the server side for the user's account, you need to figure out the following:

• What role model is used? It's important to ensure that the user doesn't gain excessive access to the application's objects and functions.
• Does the application rely on server data being filtered at the interface level? This could result in unnecessary data being returned in the API response.
• Is it possible to exceed the scope of your role? This can happen by changing the corresponding parameter in a request or performing undocumented functions on objects.
• Are there any unsafe direct object references?

API testing for attacks​

By performing the above checks, you can also collect a list of potential attack surfaces and further test the API for various injection vectors, such as SQL, NoSQL, LDAP, XML, or Stored XSS.

SSRF (Server-Side Request Forgery) deserves special mention: it appeared on the OWASP list of popular web application vulnerability categories in 2021 and was included in the API Risk Report this year. The vulnerability occurs when an API accesses a resource without validating the URL provided by the user. This allows an attacker to trick the application into sending a request through an unexpected path, including requests to localhost and other machines on the application's local network. SSRF also serves as a good entry point for other attacks.

It's important to monitor input data sanitization in general. Even if an attack vector isn't currently active but was stored in the server data in its original form, it may resurface later as the source code is updated. Below, we'll list and discuss other methods
for tracking API issues.

Fuzzing​

Allows you to test how the application responds to different formats of transmitted data, different data types in parameter values, and non-standard characters. This feature can also display the output of redundant values in case of errors: name, executed function, and full stack trace.

HTTP method enumeration​

Non-standard server responses can also be obtained by iterating through API requests using the HTTP method dictionary. This can result in a variety of errors with additional information, as well as correctly processed requests with HTTP methods that were not originally intended. This can lead to bypassing user role checks. Another example is the TRACE method, which is useful for debugging but returns unnecessary data in a production environment, such as the IP addresses of intermediate nodes. We recommend disabling methods unused in your application.

Lures​

One method for tracking attackers is to create honeypots. To do this, you can add an API endpoint that isn't used by the application and returns non-existent data. Then, you need to add monitoring for calls to this endpoint or for access to non-existent objects referenced in the honeypot's response.

Conclusion​

In this article, we covered the basics of web application API security, which can be a starting point for implementing your own checks. This is a crucial part of information security, but it's also essential to test all components of your product.

We'd like to point out that software security is an iterative process. The best results are achieved when an application is designed with security best practices in mind and then scanned as new versions are released.

If there's a long period between releases, it's also worth implementing scheduled scans to detect zero-day vulnerabilities as early as possible. When setting up a production server, add API request logging and set limits on the number of requests allowed within a certain time period. Anomaly monitoring will help identify malicious activity, so we recommend setting up alerts for rapid response. Systematic logging will also help you with incident investigations.

 

[gghllifhhhgg]

best

 

[tim6605]

best