Strengthening API Security: Addressing Vulnerabilities and Emerging Threats

Introduction

In today’s interconnected world, APIs (Application Programming Interfaces) have become the backbone of digital communication, enabling different software systems to interact with one another. From mobile applications to cloud services, APIs facilitate the exchange of data and services seamlessly. However, as APIs grow in importance, so do the risks associated with them. The increasing prevalence of API-related security breaches highlights the need for robust security measures.

What is an API?

APIs allow different software components to communicate with each other, acting as a bridge between various systems. They enable the creation of complex applications by providing a set of protocols and tools for building software and applications. APIs are essential for the functioning of web services, mobile apps, IoT devices, and more. However, their widespread use also makes them prime targets for attackers.

Top API Vulnerabilities

API vulnerabilities are diverse and can lead to severe breaches if not addressed properly. According to the OWASP API Security Top 10, the most common API vulnerabilities include:

1. Broken Object Level Authorization (BOLA) - Occurs when an API does not properly enforce access controls, allowing attackers to access or modify data they shouldn't have access to.

2. Broken Authentication - This occurs when authentication mechanisms are weak, leading to unauthorized access.

3. Excessive Data Exposure - APIs often expose more data than necessary, making sensitive information accessible.

4. Security Misconfigurations - Default, incomplete, or improper configurations that expose the API to attacks.

5. Injection Attacks - Malicious data is sent to an API, leading to SQL injections, command injections, or other forms of exploitation.

6. Server-Side Request Forgery (SSRF) - This occurs when an attacker is able to manipulate the API and trigger the server hosting it to make requests to unintended destinations.

In-Depth Look: BOLA and BFLA Vulnerabilities

1. Broken Object Level Authorization (BOLA)

BOLA is one of the most critical vulnerabilities in the API security space. It occurs when an API fails to properly check user permissions, allowing attackers to access or manipulate data that they shouldn’t have access to. For example, if a user can access another user’s data by simply changing an ID in the API request, it indicates a BOLA vulnerability.

2. Broken Function Level Authorization (BFLA)

BFLA occurs when an API incorrectly assigns user permissions for accessing certain functions. Unlike BOLA, which deals with object-level access, BFLA is concerned with higher-level functionality. This vulnerability allows unauthorized users to perform restricted operations, potentially causing significant damage.

API References and Definitions

When developing and securing APIs, understanding the tools and standards used to define, document, and interact with them is crucial. However, leaving an API documentation exposed is risky, as we will see in our case study.

Here are some of the known specifications and tools, which can be used to automatically generate an API documentation:

● Swagger

Swagger is a framework for designing, building, and documenting RESTful APIs. It allows developers to define their APIs using a standardized format, making it easier to generate interactive API documentation and client libraries. Swagger's user-friendly interface simplifies testing and interaction with APIs.

● OpenAPI

The OpenAPI Specification (OAS) is a standard for defining RESTful APIs. It provides a structured way to describe your API, including endpoints, request/response formats, and authentication methods. OpenAPI builds on Swagger and has become the industry standard for API documentation, ensuring consistency and clarity across different APIs.

● WSDL (Web Services Description Language)

WSDL is an XML-based language used for describing web services, particularly SOAP-based services. It defines the operations that the service offers, the messages it accepts and returns, and the binding details needed for communication. Although more commonly associated with older SOAP services, WSDL remains relevant for certain enterprise environments.

● ASP.NET Web API Help Page

ASP.NET Web API Help Page is a built-in feature in ASP.NET that automatically generates help documentation for your API. It provides detailed information about your API endpoints, including parameter descriptions and sample responses, making it easier for developers to understand and use the API.

● GraphQL Introspection

GraphQL Introspection is a powerful feature that allows clients to query a GraphQL API for its schema. This means that developers can retrieve detailed information about available types, fields, and operations directly from the API, enabling dynamic querying and a better understanding of the API's capabilities.

Exposed API Documentation is Risky

While API documentation is essential for developers, leaving it publicly accessible without proper controls can expose your system to significant risks, starting from Information Disclosure to Unauthorized Access, Injections, and more.

Case Study: Vulnerabilities Automatically Detected by ULTRA RED

● CVE-2023-39375: This vulnerability is related to BOLA, where improper authorization checks allowed unauthenticated attackers to create a new user admin.

● CVE-2023-39376: A BOLA vulnerability which allowed unauthenticated attackers to disable security measures applied by the application.

● CVE-2024-41702: An SQL Injection vulnerability in an API login endpoint, where JSON object injection led to unsanitized values being passed to an SQL query.

● Personal Identifiable Information (PII) Exposure: A BFLA vulnerability which allowed an attacker to access other user resources, specifically employees of a large company, and expose highly sensitive PII, including Protected Health Information (PHI).

● Vector Type - Server Side Request Forgery (SSRF)

Summary: SSRF could be critical, especially when it is reflected. In our case, we could use SSRF to fetch cloud metadata and get initial access to the client’s cloud environment.

Detection: The system is programmed to automatically parse the API Definitions that we mentioned earlier and scan the endpoints for vulnerabilities. Unfortunately for the client, there was one API request that laid bare a critical vulnerability.

The vulnerability allowed an attacker to send email messages to other users, originating from the API vendor’s trusted mail server!

We tested the parameter for SSRF, and got a successful callback.

But there is more - the attacker could attach files to each email message by supplying a list of URLs.

In the image below, we see that the request is sent to the /api/Email/Send Email endpoint, which includes parameters such as Address, Emails, CCs, and BCCs. For this example, we've populated these fields with placeholder email addresses using a domain generated by Interactsh.

We tried a few common and interesting endpoints for SSRF, such as the AWS metadata endpoint - we filled in the AWS metadata URL http://169.254.169.254/latest/meta-data as a file attachment:

Ok, so the request has been successful because we got the ‘isSuccess’ parameter as true.

I used Interactsh to check if the file is sent, but a temporary mail can also be used:

We can see we got the SMTPinteraction. A second-order SSRF was found!In verbose mode we can see the base64 encoded content:

We can now take the encoded data, decode it and see that we could successfully access the instance metadata endpoint:

Securing Your APIs

To mitigate these vulnerabilities, here are some best practices:

● Implement strong authentication and authorization mechanisms.

● Follow the principle of least privilege to restrict access.

● Validate and sanitize all inputs to prevent injection attacks.

● Use rate limiting and monitoring to detect unusual activity.

● Regularly update and patch APIs to address known vulnerabilities.

● Introduce scanning tools (such as ULTRA RED) to automatically detect known and unknown vulnerabilities.

Conclusion

As APIs continue to expand, securing them becomes paramount. By understanding common OWASP API top 10 vulnerabilities, and implementing robust security measures, organizations can protect their digital assets and ensure that their APIs remain secure.

‍