This week, we have news of two critical vulnerabilities in the Fortinet FortiSIEM product. We also have articles on making public APIs private and building an API security strategy. Dana Epp offers his thoughts on the difference between endpoints and routes, and we have two developer-focused tutorials, one on securing gRPC and the other on Django API security best practices.
Vulnerability: Two critical flaws in Fortinet FortiSIEM product
This week’s main news is the further coverage of the two critical issues reported in the Fortinet FortiSIEM product courtesy of The Register. The two vulnerabilities (tracked as CVE-2024-23108 and CVE-2024-23109) were rated as critical with a CVSS score of 10, indicating that the exploits can be carried out remotely by unauthenticated attackers and are low in complexity.
According to The Register, there was some confusion about whether these were two new vulnerabilities or whether they referred to previously identified vulnerabilities. Current consensus suggests that these are two new vulnerabilities that have yet to be patched or remediated by Fortinet. The guidance from Fortinet is to upgrade to version 7.1.2 immediately, as this version is not believed to be vulnerable. Fortunately, there do not appear to be any available exploits in the public domain.
The advisory suggests that the vulnerability is related to an API endpoint susceptible to specially crafted payloads manifesting in OS command injections (CWE-78). Although no longer in the OWASP API Security Top 10, injection attacks are still highly prominent and often lead to high-severity vulnerabilities (such as this example.)
Article: How to make public APIs private
DevOps.com featured a very interesting article on how to make public APIs private, which will pique readers’ interest. The author highlights a problem we are only well too aware of — APIs are by their nature most commonly publicly accessible, making them easy to attack. Coupled with this are the generally poor levels of protection offered by so-called ‘Day 2’ solutions such as WAFs, IDS, etc. These are usually not suited to zero attacks leveraged against APIs.
The author proposes a novel solution using a zero-trust overlay network. The concept is simple and comprises three components:
- The existing API clients are redirected to the overlay network rather than directly to the API
- A zero-trust overlay network
- API servers on a private network segment
The overlay network provides several core security features, namely:
- Eliminating public access: clients connect to the overlay network rather than directly to the API servers.
- Identity, authentication, authorization, and mutual TLS: the overlay network becomes the enforcement point for critical security primitives. Developers only have to add a few lines of code to access the overlay network securely.
- Outbound-only: The API server does not accept input connections but instead makes outbound connections to the overlay network to accept requests.
- Ease of management: the overlay network is a software-only solution allowing central management.
The article describes the proof of concept using the Open Ziti zero-trust networking solution, which looks like a very interesting project in its own right.
The approach described contains some promising ideas, particularly the reduction of API servers’ attack surface and the integration of many core API security-critical components (authentication, authorization, mTLS) into the fabric.
Article: Developing an API security strategy
HelpNet Security is next with its views on the importance of an API security strategy. The author cites the recent Cloudflare report, which suggested that 57% of internet traffic is now API-related. More concerning is that 60% of organizations have experienced at least one breach in the last two years.
The author suggests that an API strategy is essential for countering the threats posed to APIs, including DDoS, brute force, code injection, and man-in-the-middle attacks. They recommend starting with the OWASP API Security Top 10 to understand the threats and then adopting something like the NIST Cybersecurity Framework to identify a strategy.
Their recommendations include focusing on the following:
- Hardening authentication and authorization implementations
- Using SSL/TLS everywhere
- Implementing zero-trust access controls
- Perform regular security tests and assessments
- Frequent updates and patching of vulnerabilities
- Continuous monitoring and alerting
- Using API gateways
- Using a WAF or API protection solution
To this, I emphasize the importance of a shift-left approach to API security, which focuses on a developer-led approach to secure API development.
Guide: Endpoints versus routes
Dana Epp returns to the newsletter this week with his thoughts on the difference between an endpoint and a route. From my perspective, these terms are used somewhat interchangeably in our industry, yet—as Dana points out—there are quite distinct differences that are worth exploring.
An endpoint is a specific URL/URI that a client application can access. It is a unique location in the network namespace. For example,
and are two distinct endpoints.
An API route further distinguishes itself from the endpoint by introducing the HTTP operation in question (such as GET, POST, PUT, DELETE). For example, a single endpoint can have a route that responds to the GET operation (reading a value) and the POST operation (writing a value).
This distinction is important because the code implementation in the backend might be distinct for different routes and behave quite differently. It is essential that all routes are tested individually and that one does not rely on only one endpoint test. A common anti-pattern is that routes are implemented slightly differently. A good case in point is a DELETE operation that does not validate if the caller has permission to actually delete the object.
Or, more simply put in meme form:
Guide: Django API security best practices
Finally, we have a guide on how to secure Django-based API implementations. Django is a popular Python framework used for web applications and API servers. Fortunately, Django is considered a secure framework with sensible, secure defaults and built-in security primitives.
The guide features a range of popular third-party libraries providing support for the following:
- User registration, authentication, and password management
- Content Security Policy (CSP) to counter XSS attacks
- Rate-limiting protections
- Fine-grained access controls to data
- Transparent encryption
The guide gives guidance on advanced topics, including:
- Authentication, including MFA and social media authentication
- Authorization, including RBAC and group-based authorization
- Input validation and output encoding
- Secure configuration
Django is a good choice for Python-based APIs, and this guide is a great place to start when it comes to securing them.
API Security Workshop: Austin Mar 11, 2024
Join 42Crunch next week at the Austin API Summit for a dedicated API Security workshop.
Workshop Leaders
Topics covered include:
- The context for API security (the need, the differences, the opportunities)
- Understanding the OWASP API Security Top 10 vulnerabilities
- Overview of several recent high-profile API breaches
- Building secure APIs by design
- Developing secure APIs
- Protecting APIs
25% Discount Code: 42crunchworkshop
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
