Issue 218: Three Argo CD API exploits, distributed identity for modern API security

This week, we have news of three separate API vulnerabilities within the popular cloud-native continuous deployment platform. We also have a report covering the views of Gartner on the current state of API security and an article on distributed identity as a key element of modern API security. Finally, we have a guide on how to use the Burp Suite Scanner module to scan REST APIs.

Vulnerability: Three Argo CD API exploits within two weeks

First up is an excellent article courtesy of Security Boulevard covering three separate API exploits within the Argo CD continuous deployment platform.

The first vulnerability (tracked as CVE-2023-22736) is a high-severity flaw that allowed the caller to effectively “break out” of their configured permitted namespaces. The application controller API backend did not validate that the caller had access to the requested namespace — this is an example of API5:2019 — Broken function level authorization. Always remember to fully validate the caller’s permission to access an API method.

The second vulnerability (tracked as CVE-2023-22482) is a critical issue also caused by improper authorization. In this instance, the application controller API backend failed to validate the claim in the provided JWT tokens correctly. By failing to validate the audience claim, it would be possible to use tokens issued for other audiences (different applications) and then assign them higher privileges than they may be allowed. This vulnerability has been remediated by adding the allowedAudiences field in the OIDC configuration to specify only the audiences allowed. JWT token validation best practices and patterns should be employed to avoid this class of vulnerability.

The third vulnerability (tracked as CVE-2023-25163) is a medium-level severity that allows the leakage of repository access credentials in error messages. Although quite hard for an attacker to exploit, the persistence of sensitive credentials in log files is a significant issue due to the long-lived nature of logs. Ensure that sensitive log information is sanitized or masked before being written to logs.

Users of Argo CD are advised to upgrade to the latest version, where all three issues have been addressed.

Report: Gartner’s views on API security

Next, we have views from Mark O’Neill, VP analyst, and chief of research for software engineering at Gartner, on the recently released 4th annual State of the APIs Report collected insights from more than 850 global developers. O’Neill is likely well-known to readers of this newsletter and correctly predicted in 2021 that API breaches would become the number one threat vector for applications.

The first observation from O’Neill is that organizations are, by necessity deploying multiple API gateways (and multiple cloud providers) across their estate. This makes central management of API policy a complex problem as there is a lack of good federated management solutions for a distributed environment. For now, teams are stuck with having to manage multiple gateways independently.

The second observation from O’Neill is that API management and security are complicated by the sheer variety of API types in use — he cites the following as popular choices: REST, Webhooks, Websockets, SOAP, GraphQL, Kafka, AsyncAPIs, gRPCs. Of particular note from a security perspective is GraphQL, which allows very deep and wide queries across data, making it difficult to know what to secure. GraphQL is also stateless, so security teams must enforce authentication and authorization correctly.

O’Neill has the following recommendations for API security:

  • Ensure that you have an up-to-date inventory of the APIs within your organization. This includes both your upstream and downstream APIs and internal and external APIs.
  • Adopt APIs and API standards such as Open Banking Initiative to improve your overall security posture.

Finally, O’Neill predicts that API management tools will continue to address authentication and authorization challenges while API-specific tools will be used for scanning and discovery. He also suggests that security tools can provide runtime protections and microgateways can protect against API attacks.

Article: Distributed identity is key for modern API security

We frequently feature content from Curity in this newsletter, and today, we have another excellent article on the importance of identity distribution for modern API security. Previously identity was relatively simple in a monolith since a single controller handled the entire request from start to finish. However, with the advent of modern decomposed architectures, a request is passed via a load balancer to an API gateway and finally to a service, which in turn may call other services to handle the request. Identity distribution attempts to overcome many of these challenges by ensuring that any component of your API can verify identity continuously.

There are some challenges to identity distribution, namely:

  • Identity must be transferred securely — using signed tokens or certificates is preferred over plain values in request headers.
  • Also, it is not about authenticating the user but about the rights of the requesting service (such as an API gateway or load balancer) to make the specific call.
  • Simply distributing user credentials amongst all services breaks the principle of least privilege since all services with a user credential inherit the rights of that token.
  • Similarly, oversharing credentials can lead to information leakage of the user’s information.

The author recommends the following best practices for distributing identity:

  • Use Transport Layer Security (TLS) on all external and internal network segments since this provides the most fine-grained control over who can access services.
  • Lock down infrastructure using your service mesh’s facilities, such as mutual TLS, and frameworks like SPIFFE.
  • Use well-established standards such as OAuth and JSON Web Tokens, which have been well-tested and are robust when implemented properly.
  • Use claims-based authorization instead of relying on API keys or scopes.
  • Use opaque tokens to prevent the unnecessary leakage of information to the front end. The Phantom Token approach is recommended as an approach.
  • Use token-sharing techniques to ensure the minimum necessary amount of information is shared when passing tokens between services. Either embedded tokens or exchanged tokens can be used.

Authorization is the number one API security vulnerability, and this guide shows how important it is to control identity within modern API architectures.

Guide: Using Burp Suite Scanner to scan REST APIs for vulnerabilities

The team at Portswigger recently announced improved support for scanning JSON-based definitions of API endpoints for vulnerabilities in their popular BurpSuite vulnerability scanner. Burp uses the API definition as the seed for the scanning engine instead of attempting to dynamically determine the endpoints using a crawling technique as they do for web applications.

The current version requires that the API be defined in JSON-based OpenAPI Specification 3.x.x, and contains no external references.

From a review of the documentation, it appears the scanner performs a relatively limited range of operations to the endpoints under test. For example, it does not appear to perform any request body manipulation or interpretation of responses bodies. It performs parameter manipulation for GET and POST methods, including testing enumerated ranges and minimum and maximum values.

Several endpoints are not scannable with the current BurpSuite, and these include:

  • Authentication that is implemented at an endpoint level.
  • Server and path parameters that are not an enumerated type or where examples are not provided.
  • Various other conditions for complex endpoints.

Although somewhat limited at this stage BurpSuite users would be advised to test their APIs and web applications. Any testing is better than no testing, after all.

Webinar: Why API Security Cannot Wait Until Production

Analyst and research firm, Enterprise Management Associates (EMA), conducted a survey earlier this year of North American technology leaders. Results revealed that 32% of firms only implement API security standards in their production environment.

Join me with Christopher Steffen, VP Research – Information Security at EMA, on this webinar as we explore why business cannot afford for API Security to be an afterthought.


Get API Security news directly in your Inbox.

By clicking Subscribe you agree to our Data Policy