This issue is a catch-all for a wide range of security misconfigurations that often negatively impact API security as a whole and introduce vulnerabilities inadvertently. Some examples of security misconfigurations include insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, overly permissive Cross-Origin resource sharing (CORS), and verbose error messages.
Attackers can exploit security misconfigurations to gain knowledge of the application and API components during their reconnaissance phase. Detailed errors such as stack trace errors can expose sensitive user data and system details that can aid an attacker during their reconnaissance phase to find exploitable technology including outdated or misconfigured web and application servers. Attackers also exploit misconfigurations to pivot their attacks against APIs, such as in the case of an authentication bypass resulting from misconfigured access control mechanisms.
Many automated tools are available to detect and exploit common or known misconfigurations such as unnecessary services or legacy options, though where you detect them in the technology stack varies greatly. Commonly used vulnerability scanners may only scan a running server for known vulnerabilities and misconfigurations in published software, usually in the form of CVE IDs. However, they don’t provide the complete picture, since misconfigurations can exist in underlying code, in third party dependencies, or in integrations with other enterprise architecture . As a result, organizations will often employ a barrage of security testing tooling in build pipelines to catch as much as possible prior to production deployment. There are certainly cases where security misconfiguration can be the result of something basic like a missing patch, but some misconfigurations are far stealthier and obscured by complex architectures.
In the example above, the attacker modified the connectionId parameter of the GET request to an API, causing the application server to respond with a detailed exception error with stack trace information. These errors can include information about the application environment such as software vendor names, software packages used, software versions, and lines of code within the backend server-side code that the error resulted. All of this information is invaluable to an attacker who is performing reconnaissance in order to gain an understanding of infrastructure that serves the applications and APIs as well as the application code itself in order to discover other potentially exploitable vulnerabilities.
The Capital One breach in 2019 was a chained attack, that was the result of a few issues, the primary vector being a misconfigured WAF. Through other sources, we know that ModSecurity, an open-source WAF, was likely used to protect certain Capital One web applications and APIs. The WAF was not appropriately configured or tuned for Capital One’s AWS environment and was overly permissive. As a result, an attacker was able to bypass the WAF’s content inspection and message filtering using a well crafted injection that targeted the backend AWS cloud metadata service. Harvesting metadata typically only available to running workloads, the attacker was able to pivot their attack and compromise other systems within the AWS cloud environment, commonly referred to as server-side request forgery attack.
Traditional security controls like WAFs and API gateways are not able to identify the modification to the connectionId parameter in the example above since it does not match a pattern of a typical attack. These tools also lack the context to know that the modified connectionId parameter does not match typical usage for this parameter or that it would result in an application server error, and therefore would miss this attack. These tools would also not alert on the excessive data sent in the API response since these traditional security controls lack context about this information to know that it is potentially sensitive and should not be returned in error messages. It’s also not uncommon for traditional security controls to only check client requests to APIs, or inbound traffic, and not the server response back to the client, or outbound traffic.
An API security solution must be able to identify misconfigurations and security gaps for a given API and its serving infrastructure. It must suggest remediation when manipulation attempts are made, and the application server itself is not configured to reject the request or mask sensitive data in the response. An API security solution must be able to analyze all API activity and establish a baseline of typical API activity so that it can help identify excessive data and sensitive data sent in error messages. These solutions also help to identify the early activity of an attacker who is performing reconnaissance in order to look for security misconfigurations and learn more about the API structure and logic. Early detection defines the difference between a security incident, where you catch attacker behavior early in their methodology and stop it, as opposed to a breach, where an attacker is able to successfully exfiltrate data or compromise systems.
Salt Security's Michelle McLean speaks with the team at Xolv about how Xolv has deployed Salt to protect the APIs at the heart of its healthcare applications.
As part of our continuing mission here at Salt to educate the broader industry, our technical evangelist, Michael Isbitski, provides a comprehensive overview of the challenges and best practices in API security.