OWASP TOP 10 API
Introduction
Injection vulnerabilities have plagued web applications for over two decades. They take place when an attacker is able to send commands that are executed by the systems that support the web application. The most common forms of injection attacks are SQL injection, Cross-site scripting (XSS), and operating system command injection. APIs are yet another attack vector for these critical attacks to be communicated from an attacker to the supporting databases and systems.
"Attackers will feed the API with malicious data through whatever injection vectors are available (e.g., direct input, parameters, integrated services, etc.), expecting it to be sent to an interpreter."
"Injection flaws are very common and are often found in SQL, LDAP, or NoSQL queries, OS commands, XML parsers, and ORM. These flaws are easy to discover when reviewing the source code. Attackers can use scanners and fuzzers."
"Injection can lead to information disclosure and data loss. It may also lead to DoS, or complete host takeover."
Summary
Injection flaws exist when a request is passed to the API’s supporting infrastructure and the API provider doesn’t filter the input to remove unwanted characters (a process known as input sanitization). As a result, the infrastructure might treat data from the request as code and run it. When this sort of flaw is present, an attacker will be able to conduct injection attacks like SQL injection, NoSQL injection, and system command injection.
In each of these injection attacks, the API delivers an unsanitized payload directly to the operating system running the application or its database. As a result, if an attacker sends 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.
Verbose error messaging, HTTP response codes, and unexpected API behavior can all be clues to an attacker and will be an indication that they have discovered an injection flaw. Say, for example, an attacker were to send OR 1=0-- as an address in an account registration process. The API may pass that payload directly to the backend SQL database, where the OR 1=0 statement would fail (as 1 does not equal 0), causing some SQL error:
POST /api/v1/register HTTP 1.1
Host: example.com
--snip--
{
“Fname”: “hAPI”,
“Lname”: “Hacker”,
“Address”: “' OR 1=0--”,
}
An error in the backend database could show up as a response to the consumer. In this case, the attacker might receive a response like “Error: You have an error in your SQL syntax…”, but any response directly from databases or the supporting system will serve as a clear indicator that there is likely an injection vulnerability.
Injection vulnerabilities are often complemented by other weaknesses like poor input sanitization. Injection flaws can have serious impacts by providing an attacker with the ability to manipulate an API’s supporting system or database.
Finding injection flaws requires diligently testing API endpoints and paying attention to how the API responds, then crafting requests that attempt to manipulate the backend systems. Injection attacks have been around for decades, so there are many standard security controls that can be used to protect API providers from them.
Preventing injection requires keeping data separate from commands and queries.
Perform data validation using a single, trustworthy, and actively maintained library.
Validate, filter, and sanitize all client-provided data, or other data coming from integrated systems.
Special characters should be escaped using the specific syntax for the target interpreter.
Prefer a safe API that provides a parameterized interface.
Always limit the number of returned records to prevent mass disclosure in case of injection.
Validate incoming data using sufficient filters to only allow valid values for each input parameter.
Define data types and strict patterns for all string parameters.
Additional Resources
Insufficient Logging and Monitoring
Intro
Logging and monitoring are necessary and important layer of API security. In order to detect an attack against an API an organization must have monitoring in place. Without sufficient logging and monitoring an API provider is operating in the dark and API attacks are guaranteed to go unnoticed until it is far too late.
Attackers take advantage of lack of logging and monitoring to abuse systems without being noticed.
Without logging and monitoring, or with insufficient logging and monitoring, it is almost impossible to track suspicious activities and respond to them in a timely fashion.
Without visibility over ongoing malicious activities, attackers have plenty of time to fully compromise systems.
Summary
Logs can reveal patterns in API usage and can be used as evidence to understand how an API is abused. Logging and monitoring provide an audit trail of activities and are often required for compliance purposes. An important part of logging is to ensure that the logs have integrity and cannot be altered by an attacker. Monitoring an API will help providers detect suspicious activities and anomalous user behavior. This helps providers be able to take action to thwart attacks. Logging and monitoring are essential for improving API performance and security.
Log all failed authentication attempts, denied access, and input validation errors.
Logs should be written using a format suited to be consumed by a log management solution and should include enough detail to identify the malicious actor.
Logs should be handled as sensitive data, and their integrity should be guaranteed at rest and transit.
Configure a monitoring system to continuously monitor the infrastructure, network, and API functioning.
Use a Security Information and Event Management (SIEM) system to aggregate and manage logs from all components of the API stack and hosts.
Configure custom dashboards and alerts, enabling suspicious activities to be detected and responded to earlier.
Additional Resources
Business Logic Flaws
Intro
Business logic vulnerabilities are weaknesses within applications that are unique to the policies and features of a given API provider. The exploitation of business logic takes place when an attacker leverages misplaced trust or features of an application against the API. Identifying business logic vulnerabilities can be challenging due to the unique nature of each business. The impact of these vulnerabilities can range based on the severity of the vulnerable policy or feature.
Attack Vector Description
Business logic vulnerabilities are unique to each application and exploit the normal intended functioning of an application's business processes. They often require specific knowledge of the application's functionality and the flow of transactions or data. Since these vulnerabilities are specific to the business logic of each application, there's no one-size-fits-all approach to identifying them.
Security Weakness Description
Business logic vulnerabilities arise when the assumptions and constraints of a given business process aren't properly enforced in the application's control structures. This allows users to manipulate the application's functionality to achieve outcomes that are detrimental to the business. These weaknesses typically occur when developers fail to anticipate the various ways that an application's features can be misused or when they don't consider the wider context of the business rules. This is often due to a lack of comprehensive understanding of the application's business logic, a lack of input validation, or incomplete function-level authorization checks.
Impacts Description
Business logic vulnerabilities can cause a variety of technical impacts, depending on the specific flaw and the systems involved. These impacts can range from unauthorized access to data or functionality to a total bypass of system controls.
Summary
Business logic vulnerabilities (also known as business logic flaws, or BLF) are intended features of an application that attackers can use maliciously. For example, if an API has an upload feature that instructs users to only upload certain encoded payloads, but doesn’t validate the encoded payloads, a user could upload any file as long as it was encoded. This would allow end users to upload and potentially execute arbitrary code, including malicious payloads.
The Experian partner API leak, in early 2021, was a great example of an API trust failure. A certain Experian partner was authorized to use Experian’s API to perform credit checks, but the partner added the API’s credit check functionality to their web application and inadvertently exposed all partner-level requests to users. This request could be intercepted when using the partner’s web application, and if it included a name and address, the Experian API would respond with the individual’s credit score and credit risk factors. One of the leading causes of this business logic vulnerability was that Experian trusted the partner to not expose the API.
Another problem with trust is that credentials, like API keys, tokens, and passwords, are constantly being stolen and leaked. When a trusted consumer’s credentials are stolen, the consumer can become a wolf in sheep’s clothing and wreak havoc. Without strong technical controls in place, business logic vulnerabilities can often have the most significant impact, leading to exploitation and compromise.
Examine an API's documentation for telltale signs of business logic vulnerabilities. Statements like the following should be indications of potential business logic flaws:
“Only use feature X to perform function Y.”
“Do not do X with endpoint Y.”
“Only admins should perform request X.”
These statements may indicate that the API provider is trusting that you won’t do any of the discouraged actions, as instructed. An attacker will easily disobey such requests to test for the presence of technical security controls.
Another business logic vulnerability comes about when developers assume that consumers will exclusively use a browser to interact with the web application and won’t capture API requests that take place behind the scenes. All it takes to exploit this sort of weakness is for an attacker to intercept requests and alter the API request before it is sent to the provider. This would allow the attacker to capture shared API keys or use parameters that could negatively impact the security of the application.
As an example, consider a web application authentication portal that a user would normally employ to authenticate to their account. Say the web application issued the following API request:
POST /api/v1/login HTTP 1.1
Host: example.com
--snip--
UserId=hapihacker&password=arealpassword!&MFA=true
There is a chance that an attacker could bypass multifactor authentication by simply altering the parameter MFA to false.
Testing for business logic flaws can be challenging because each business is unique. Automated scanners will have a difficult time detecting these issues, as the flaws are part of the API’s intended use. You must understand how the business and API operate and then consider how an attacker could use these features to their advantage. One method of testing for business logic flaws is to study the application’s business logic with an adversarial mindset and try breaking any assumptions that have been made.
Preventative Measures
Use a Threat Modeling Approach: Understand the business processes and workflows your API supports. Identifying the potential threats, weaknesses, and risks during the design phase can help to uncover and mitigate business logic vulnerabilities.
Reduce or remove trust relationships with users, systems, or components. Business logic vulnerabilities can be used to exploit these trust relationships, leading to broader impacts.
Regular training can help developers to understand and avoid business logic vulnerabilities. Training should cover secure coding practices, common vulnerabilities, and how to identify potential issues during the design and coding phases.
Implement a bug bounty program, third-party penetration testing, or a responsible disclosure policy. This allows security researchers, who are a step removed from the design and delivery of an application, to disclose vulnerabilities they discover in APIs.
Additional Resources
Last updated