SBN

API9:2019 Improper Assets Management

Description

Maintaining a complete, up to date API inventory with accurate documentation is critical to understanding potential exposure and risk. An outdated or incomplete inventory results in unknown gaps in the API attack surface and makes it difficult to identify older versions of APIs that should be decommissioned. Similarly, inaccurate documentation results in risk such as unknown exposure of sensitive data and also makes it difficult to identify vulnerabilities that need to be remediated.

Unknown APIs, referred to as shadow APIs, and forgotten APIs, referred to as zombie APIs, are typically not monitored or protected by security tools. Even known API endpoints may have unknown or undocumented  functionality, referred to as shadow parameters. As a result, these APIs and the infrastructure that serve them are often unpatched and vulnerable to attacks.

Potential Impact

Attackers may gain unauthorized access to sensitive data, or even gain full server access through old, unpatched or vulnerable versions of APIs.

Example

Research conducted by Salt Security shows a common gap of up to 40% between manually created API documentation (or schema definitions) in the form of Open API Specification (OAS) vs. what is actually deployed in production APIs. These gaps fall into the following three categories:

  1. Shadow API Endpoints – API endpoints that are missing from the OAS or have no OAS at all. In the following example, Salt Security research found an additional 54 endpoints that were not included in the Swager or OAS documentation, and 12 of those undocumented endpoints were exposing sensitive PII data.

  1. Shadow Parameters – API endpoints known to exist but whose API documentation is missing many parameters. As a result, the API documentation does not cover the majority of the attack surface – in this research, API schema definitions  listed just three parameters, but the Salt Security platform identified 102 parameters for the single API endpoint. 

  1. Parameter Definition Discrepancies – in addition to many missing parameters, data types that lack needed details such as “String” instead of “UUID” or “DateTime” will leave APIs vulnerable. Message filters used by traditional security controls will allow any input through the API to be processed by the backend. These controls rely on a positive security approach and explicitly written rules and policies when enforcing requests against API schema definitions.

Why Existing Tools Fail to Protect You

Traditional security controls like WAFs and API gateways lack capabilities to continuously discover APIs at a granular level and monitor them for changes.  These security controls only know what they are configured for, requiring API schema definitions to be imported in order to gain a view of the API environment.  If documentation is missing or inaccurate, as is often the case for many security teams, these traditional security controls will have an inaccurate view of the API environment.

How to Protect Against Improper Asset Management Vulnerabilities

API security solutions must be able to analyze all API traffic and continuously discover APIs.  Discovery must include the ability to identify all host addresses, API endpoints, HTTP methods, API parameters, and their data types including the identification and classification of sensitive data.  These solutions must provide discovery on an ongoing basis to maintain an up-to-date catalog of the API environment and accurate API documentation even as new APIs are introduced and updates are made to existing APIs.

Previous Posts:

OWASP API Security Top 10 Explained

API1:2019 Broken Object Level Authorization

‍API2:2019Broken User Authentication

API3:2019Excessive Data Exposure

API4:2019Lack of Resources & Rate Limiting

API5:2019Broken Function Level Authorization

API6:2019 MassAssignment

API7:2019 Security Misconfiguration

API8:2019 Injection

Next Post:

API10:2019 Insufficient Logging & Monitoring

*** This is a Security Bloggers Network syndicated blog from Salt Security blog authored by Michael Isbitski. Read the original post at: https://salt.security/blog/api9-2019-improper-assets-management