This week, we have an excellent write-up on a case study of API vulnerabilities, an API vulnerability in Riverbed’s SteelCentral AppInternals software, an article on how even the most “perfect” APIs can be abused, and a guide on the safer handling of JSON web tokens (JWTs).
Vulnerability: A case study of API vulnerabilities
This week, a popular article has been the write-up on a series of related API vulnerabilities discovered during a recent assignment by the Irish security researcher @pmofcats. The article is a real eye-opener for API defenders and developers alike to realize how easily their APIs can be compromised by a talented and determined attacker. As the old adage goes: a chain is only as strong as its weakest link, and this write-up shows how easily a system can be compromised totally by relatively minor weaknesses.
The researcher describes a system with three related entities (objects): the grandparent, parent, and child. Using a variety of attack techniques (some directly on the APIs, others by reverse engineering or repositories), the researcher was able to:
- Get parent UUIDs leak within API requests.
- Reassign roles (such as admin) to a parent if their UUID was known, due to Broken object-level authorization.
- Access API keys, administrator details, and so forth because of Broken function-level authorization.
- Achieve full account takeover by modifying the child ID within the JWT because of weak JWT validation.
- Create arbitrary grandparent entities due to weak policy enforcement.
- Leak grandparent IDs both in the commit history in GitHub repository and within JavaScript files in the application.
- Access API keys and critical PII exposed through an endpoint that did not validate a parent ID value and used a default production value.
- Reuse a web UI cookie on an API endpoint to access high-privilege actions.
Thanks to the researcher for sharing, this article shows quite how easily a skilled attacker can use multiple attack vectors on a target.
Vulnerability: Injection attack in API of the Riverbed software
This week, The Register has reported on vulnerabilities in the API of the SteelCentral AppInternals software by Riverbed. The vulnerabilities were disclosed by cyber security specialist Kang Hao Leng, who made the discovery in November 2021.
The vulnerabilities related to directory traversal in a URL path on API endpoints. A lack of sufficient input validation allowed an attacker to submit deliberately malformed URLs to traverse the target file system — a form of injection attack.
The four critical vulnerabilities are tracked as CVE-2021-42786, CVE-2021-42787, CVE-2021-42853, and CVE-2021-42854. No details on remediation or mitigation for these vulnerabilities were available at the time of writing.
Article: Even “perfect” APIs can be abused
Dark Reading has featured thoughts on the abuse of “perfect” APIs — even an API that is perfectly secure (or at least does not exhibit obvious vulnerabilities) can still be open to abuse. These so-called abuse attacks can be notoriously hard to detect since they “hide in plain sight”, resembling ordinary API usage although with a nefarious purpose.
Two main patterns are associated with API abuse:
- Using APIs in unintended ways: Using the API as designed, but for the wrong reason. A typical example is data scraping.
- Discovery of vulnerabilities in application logic: APIs can be automatically abused to detect complex (and hard to spot) vulnerabilities in application logic.
The most commonly abused APIs are frequently those of partner APIs — a great example is the Facebook and Cambridge Analytica scandal in 2018. Cambridge Analytica was able to take advantage of a Facebook API and gain access to user information for the purposes of demographic profiling. This was not a vulnerability in the Facebook APIs, but rather the abuse of an API by a bad actor. Not only was this hard to detect, it also proved costly to Facebook, and drew the attention of government regulators.
The article concludes that there is no simple solution to addressing abuse cases, but it recommends beginning with the OWASP API Security Top 10 to eliminate vulnerabilities and then using an attack framework (such as MITRE ATT&CK) to map abuse cases and methods.
Article: Safer handling of JWTs
This week’s final article is courtesy of Alex Savage, with his thoughts on the safe handling of JWTs in API backends. The article is a great and quick read for developers tasked with the validation of JWTs: although a seemingly simple task, it is fraught with dangers, and weak JWT is often a source of API vulnerability (as seen in the first vulnerability case this week).
The good news is that relatively simple checklists can be applied to JWT validation. For instance, we recently featured a guide on common pitfalls, and this article from Savage suggests the following key points:
- Pick one (and only one!) algorithm. Typically, RS256 or HS256 are advised.
- Use a standard library for decoding and verification, avoid writing your own.
- Do not use the token claims until the token is fully verified.
- Have a policy for key rotation in place.
Definitely an article worth bookmarking for future reference.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
