This week, we have news of a vulnerability in Argo CD that allowed leaking application secrets, a survey of the state of API security across three regions, a quick read on how to use Postman and OWASP Zap for API security testing, and finally views on how to distribute authorization services in a microservice architecture.
Vulnerability: Argo CD path-traversal vulnerability enables leaking data
This week’s major news has been the vulnerability discovered in Argo CD, aย popular continuous delivery platform.
The vulnerability (CVE-2022-24348, CVSS score of 7.7) was discovered by researchers at Apiiro, and allowed attackers to exploit a path traversal vulnerability in the platform to gain access to other application instances. Researchers believe this could have led to leaking passwords, API keys, and tokens. According to the researchers, attackers could exploit it by loading a malicious Helm Chart YAML file into affected Argo CD systems.
The root cause of the vulnerability was an implementation error in the method ParseRequestURI which validated the root directories of paths loaded from external sources. If the input path received appeared to be a URL, further checks were skipped. This meant that attackers could use a URL path to bypass the anti-path-traversal checks. By specifying the arbitrary path in a Helm Chart allowed attackers to access any file or directory on the server filesystem.
The researchers advise Argo CD users to patch their systems as soon as possible.
Survey: The state of API security
Dutch cybersecurity company Cybersprint has released a report into the state of API security across the EU, North American, and APAC regions. The report examines differences in API security between the regions to understand if API security is a global issue or not.
The research methodology involved the analyzing exposed API definitions (seemingly limited to OpenAPI Specification v2 (aka Swagger) only) to identify common misconfigurations and confidential data exposed.ย Over 40,000 API definitions were analyzed across the three regions .
The results of the assessment are perhaps not a major surprise to readers of this newsletter โ typical issues identified included:
- No authentication: Insufficient or no authentication in many APIs, allowing fully unauthenticated access to them.
- Hard-coded API keys: Hard-coded API keys used in many API definitions, effectively allowing open access.
- Data leaks: Excessive data exposure in many APIs, leading to exposing customer data.
- Critical PII issues: In addition to other data leaks, several APIs were also leaking sensitive PII data (such as healthcare records).
Along with using a holistic approach to API security by following best practices, the report also highlights the importance of monitoring and reducing the attack surfaces in organizations.
Article: API security testing with OWASP Zap and Postman
The Test Therapist has put together a great guide on using Postman and OWASP Zap for security testing of APIs.
As the author rightly indicates, security testing of APIs is often neglected or left too late in their life cycle. Using two popular open-source tools this guide describes the steps for this approach to security testing (here in a nutshell):
- Set up OWASP Zap to act as a local proxy (using a known port).
- Set up Postman to use the Zap proxy for all connections.
- Using Postman, navigate to all known API endpoints and use their functions.
- In Zap, verify that all API endpoints are shown on the site list.
- In Zap, use the Attack feature to run a suite of common security tests against the API.
A great write-up of a very simple technique that may be of use when a full API specification is not available.
Article: Patterns of authorization for microservices
Finally this week, we have a technical article on patterns of authorization for microservices by OSOHq.
The article addresses emerging patterns for authorization policy and practices in distributed applications. Previously, architects have been able to deploy a single database to determine authorization policy. However, things no longer are so simple in a modern world of microservices and distributed architectures.
The author describes three fundamental approaches to solving the problem within a distributed environment:
- Keep the data where it is: This is the simplest approach and works well for small designs but lacks the ability to scale. Essentially, the authorization data is decomposed and stored in proximity to its associated services which access it directly.
- Use a request gateway: This approach uses a request gateway to attach all users’ authorization data to each request made in the system. Although a robust solution, this can lead to an explosion of data in systems with large numbers of roles.
- Centralize the authorization data: Using the principle of separation of concerns, this approach involves creating a central authorization service that acts as the single source of truth. This approach poses challenges for high availability and low latency.
The parting advice is to try and keep things simple and “build authorization around the application, not the other way around”.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
