PTAAS EXCHANGE
If you missed the PtaaS Exchange in person, join us virtually to learn how to improve your security program in 2023.

API Security Best Practices

Technology can be summarized as all the solutions produced to meet any need. As the devices providing Internet access increase daily, the traditional Monolith architecture has been replaced by the Microservice architecture due to the advantages such as scalability, faster deployment, ease of management, and many more. Core Pentester Orhan Yildirim shares his best practices for API Security.

Technology can be summarized as all the solutions produced to meet any need. As the devices providing Internet access increase daily, the traditional Monolith architecture has been replaced by the Microservice architecture due to the advantages such as scalability, faster deployment, ease of management, and much more.

The monolith and microservice architecture are summarized in the screenshot below.

A new thing that has been noticed with the introduction of microservice architecture is that applications on different platforms can now talk to each other. Creating a standard format such as GraphQL makes it possible for the frontend application prepared for a web or mobile device to talk to the same standard backend. Likewise, even a 3rd party application can use these applications.

According to the report published by AKAMAI in 2018, 83 percent of internet traffic consists of only API requests and responses.

Along with the convenience brought by API endpoints, a management obligation emerged. The fact that works such as AuthN/AuthZ, logging can be performed by API Gateway is very good for managing API endpoints.

So, why and how can API endpoints be affected by cyber-attacks?

The screenshot below shows the "/user" API with the "UserController" class name configured to respond to the "GET" and "PUT" requests.

Likewise, the "/order" API with the "OrderController" class name appears to be configured to respond to the "GET" request.

In this application, where "order" and "user" APIs are defined, the APIs that implement the WebSecurity framework are indicated in the screenshot below. 

As seen in the screenshot, all endpoints under the user API are defined as "/user/**," and it is ensured to be called Authenticated. However, there is also the "/order" API in practice.

We can see from the screenshot above that the developer forgot to use AuthN for the "/order" API and all endpoints. All unauthenticated users can call this API endpoint and take action on it, making this a vulnerable API.

A properly configured Web Security configuration for the sample application is given in the screenshot below.

In the above screenshot, the developer has properly implemented AuthN for all routes, including “/user/*” and “/order/*.” This security check prevents any unauthorized attack.

 

Insecure Direct Object Reference (IDOR) - Source Code Review 

Insecure Direct Object Reference (IDOR) occurs when an application exposes a reference to an internal implementation object. This way, the application reveals the real identifier and format/pattern used of the element in the backend application. 

The most common example (although not limited to this) is a record identifier in a storage system (database, filesystem, and so on). 

Learn more: Insecure Direct Object Reference Prevention Cheat Sheet

To prevent IDOR vulnerability in the application, the currently active user information (id, email, etc., specific and unique), where specific data belonging to the user is returned, should be added to the query/process.

In Spring Security, using the Principal object, the active user information is obtained, the query/processing is given, and the answer is returned.

To understand IDOR in more detail, let’s learn about  IDOR vulnerability using crAPI (vulnerable API application by OWASP).

Note: Check the README.md for installation steps for crAPI and visit http://localhost:8888 to access the lab.

The application shows the location of the vehicles belonging to the users in the application on the below-mentioned endpoint.

/identity/api/v2/vehicle/{uuid}/location

When we send a request to this endpoint and capture the request using Burp Suite (proxy application), the response is returned as follows.

When we go to a page called "Community" in the UI, we can see that the information of the users who commented is included in the response. Let’s capture this request in Burp Suite to check the response.

In the returned response, we can find the vehicle location of the target user by using the UUID values of the vehicles belonging to different users in the previous endpoint, making this endpoint vulnerable to IDOR Threat actors exploiting these types of issues to access sensitive information.

 

Conclusion

APIs are becoming a growing security risk to businesses. With the increase in connected devices, mobile apps, and the Internet of Things (IoT), businesses like yours are exposed to security risks that could potentially cripple your business. Implementing API security best practices to secure your APIs and protect your business is a good idea.

Back to Blog
About Orhan Yildirim
Orhan has been a member of the Cobalt Core since December 2021. As a cyber security expert, he has worked on more than 400 projects so far. He likes to automate the penetration testing work with bash, python, PowerShell, and python are the programming languages. More By Orhan Yildirim