This week, we have a timely article on the five best practices for ensuring the security of 3rd party APIs, a deep-dive guide into the OAuth2 step-up authentication protocol, and two separate articles on the danger of hidden APIs, namely shadow and zombie APIs. We conclude with not one but two excellent guides from Dana Epp on SSRF and the Gron tool.
Article: Five best practices for 3rd party API security
One of the new entries into the OWASP API Security Top 10 in 2023 is API10:2023 Unsafe Consumption of APIs, which addresses the risks associated with consuming 3rd party APIs. This topic receives surprisingly little coverage, and it was good to see this excellent article in CSO Online covering five best practices to ensure the security of 3rd party APIs.
Just like developers are sometimes inclined to blindly trust user input (to their peril), so many organizations are inclined to trust their upstream 3rd party API providers. Unfortunately, these APIs may have vulnerabilities (such as data leakage or injection vulnerabilities) that can adversely impact the consumer application. The old adage of a chain only being as strong as the weakest link applies well to a system composed of APIs — if your system is consuming a vulnerable API, then your own system is exposed to this same vulnerability.
The article gives some strong and actionable recommendations for protecting the security of your third-party APIs. The first recommendation is one of visibility and recommends maintaining an API inventory that includes your 3rd party APIs. This inventory should be kept up to date and track changes to APIs as they occur to identify shadow APIs.
The next recommendation is to address your API vendors directly. Before onboarding a new 3rd party API, ensure you conduct due diligence on the provider, including understanding their development process and what controls they implement to secure their APIs. This may include touch points such as their change management process and an active vulnerability management process. Do not assume that their API is secure regardless, and introduce active monitoring and alerting on the API to identify any vulnerabilities.
If you really want to ensure the security of a 3rd party API, then you should consider actively testing it yourself for vulnerabilities. If you find any, then insist on remediation by the vendor before continuing to use the API.
Finally, since 3rd party APIs may frequently be the target of interception or impersonation, it is advisable to rotate API keys to prevent the likelihood of machine-in-the-middle attacks.
Article: OAuth2 step-up protocol deep-dive
The next article is a deep dive into the OAuth2 step-up protocol from Authlete, which will be useful for anyone wanting to bolster their API security. One of the leading causes of API compromise is broken authentication; in fact, OWASP rates this as the second most significant API security risk.
One of the most robust ways of improving the authentication process is to put an additional layer around sensitive operations and issue a so-called step-up challenge to the client to provide an additional level of authentication, usually in the form of a multi-factor authentication token or hardware key. This is shown in a sequence diagram below:
The server will respond to an authentication attempt with an Authentication Context Class Reference (ACR), which specifies the types of authentication that can be used to proceed.
The topic is a complex one, and API developers should make sure they are considering using step-up authentication to protect their most sensitive endpoints. This article focuses on the details of the specification; for a more practical discussion, this article from Scott Brady is worth reading.
Article: Preventing zombie APIs
Next, we have the first two articles focusing on the challenges of API inventory. In an article for DevOps.com, the redoubtable Bill Doerfield discusses the security risks of zombie APIs and how to address them. Zombie APIs are usually considered APIs that are no longer in active use and, most importantly, no longer being maintained or monitored for security events. Zombie APIs typically occur when an organization releases a new version of an API but leaves the old version in place while the cutover to the new API takes place. Unfortunately, in many cases, the old API is left running and discoverable by attackers.
In the article, Bill gives the following tips on how to minimize the occurrence of zombie APIs, namely:
- Keep an Active Inventory of APIs: The first article already stressed the importance of keeping an up-to-date inventory, which is critical for addressing zombie APIs. Ensure that your infrastructure is scanned for the presence of APIs and that all instances are tracked and accounted for in an inventory that is reviewed frequently for deprecated instances.
- Use Proper Versioning and Life Cycle Strategies: By ensuring the APIs are versioned, organizations can proactively manage the lifecycle of APIs and gracefully retire older versions rather than leaving them active but unmanaged.
- Share Knowledge of Internal and Third-Party Services: The most obvious way to avoid zombie APIs is by injecting governance into the development process and ensuring that teams and product owners have visibility into the APIs available in the organization. Typically, this can be achieved by using an API developer portal, or API management platform, or even a set of Posman collections.
Unfortunately, this is not an easy problem to address and is only likely to become more of a concern as the number of APIs (and the versions thereof) continues to grow.
Article: The danger of shadow APIs
In the second article on the challenges relating to API inventory, we have an article from The Hacker News on the danger of shadow APIs. Shadow APIs are often conflated with zombie APIs, but their origin differs greatly. Shadow APIs are considered to be APIs that have been published via a non-standard process on non-standard (and, of course, non-governed or managed) infrastructure. Typically, this occurs when a business unit needs to release a new product or feature and does not have time to navigate the formal process and uses covert means to deploy an API (the canonical example is to use a credit card to purchase cloud compute resources and deploy directly there outside of the standard IT systems).
Shadow APIs are plagued by many of the same security challenges associated with zombie APIs, but in many ways, the threat is even more significant. These APIs may have access to internal APIs exposing sensitive data or may simply store this data locally in a totally ungoverned manner. Zombie APIs pose significant governance and compliance challenges.
The biggest challenge associated with shadow APIs is that while zombie APIs can be discovered by IT security teams, it is significantly harder to find shadow APIs that might be on entirely separate IP address ranges and not even hosted on corporately approved cloud platforms.
The recommendation is a mixture of carrot and stick. First, ensure that your corporate IT security and governance are not so strict that it inhibits legitimate business activities, forcing product teams to go underground. However, ensure that your IT security teams are monitoring for any indicators of shadow IT to eliminate unnecessary risk and exposure.
Guide: Exploiting SSRF in an API
In the first of two guides from Dana Epp this week, he takes a deep dive into exploiting Server Side Request Forgery (SSRF) vulnerabilities. While this vulnerability (and its counterpart Cross Site Request Forgery (CSRF)) has existed for decades, it has only recently been included in the OWASP API Security Top 10 as API7:2023 Server Side Request Forgery.
Conceptually speaking, SSRF vulnerability is really simple to understand. An attacker can make a request to a vulnerable server and trick that server into making a request to a third-party server under the control of the attacker. Typically, this is done by forging or manipulating request parameters that cause the server to redirect to a server outside of its remit.
As usual, Dana’s focus is on the offensive side of the vulnerability, and in this guide, you will learn everything you need to be able to exploit CSRF vulnerabilities. The first step is to find an endpoint that may be vulnerable, and for this, he suggests the following tips:
- Check if the API uses any of a common list of common vulnerable parameter names such as uri, path, callback.
- Check if the API accepts a webhook (since this is vulnerable to accepting a forged target).
- Check if the AP imports files (since the path can likely be manipulated to load a different resource).
- If the server generates a PDF file, then it’s possible that the attacker can embed resources into the file and launch a file-based XSS attack.
Once you have found a potentially vulnerable API, there are several types of attacks that you can mount against the endpoint, namely:
- Local/Remote port scanning
- Local file read
- Interacting with internal services
- Interacting with internal services
- Accessing cloud metadata
Finally, Dana outlines common methods to evade SSRF protections, such as:
- Use exotic URL schemas
- Using hostname instead of IP
- Non-standard IP notation
- Open redirects
Note that many of the bypasses rely on being able to trick the logic of a block list, which highlights the futility of attempting to block known bad. Use an allow list to explicitly pass redirections according to an approved list.
A great article from Dana and a reminder never to let him near your computer network 🙂
Guide: Grepping API payloads with Gron
Finally, in this marathon edition, we have another guide from Dana Epp on using the gron tool to parse and process JSON payloads at speed and scale.
The easiest way to understand what gron does is to think of it as what grep does for text but for JSON data. Executing gron against a JSON file gives an output as shown below:
colind@mbm1air: ~ # gron file.json
json = {};
json.bpi = {};
json.bpi.EUR = {};
json.bpi.EUR.code = "EUR";
json.bpi.EUR.description = "Euro";
json.bpi.EUR.rate = "25,154.3878";
json.bpi.EUR.rate_float = 25154.3878;
json.bpi.EUR.symbol = "€";
json.bpi.GBP = {};
json.bpi.GBP.code = "GBP";
json.bpi.GBP.description = "British Pound Sterling";
json.bpi.GBP.rate = "21,576.6478";
json.bpi.GBP.rate_float = 21576.6478;
json.bpi.GBP.symbol = "£";Now that the file has been flattened, you can apply the stand grep, sed, awk techniques to extract data. For instance, to get the Euro rate, execute the following command on the flattened data:
gron file.json | grep EUR.rate_float | cut -d ' ' -f 3 | tr -d ';'
25154.3878Thanks again to Dana for bringing us the best in offensive tooling and techniques.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
