This week, we have news of a critical flaw with a popular API portal. We also have guides on securing GraphQL APIs and building bulletproof APIs and news of a new deliberately vulnerable API application. We also have an article on why fraud detection and API security must converge. Dana Epp wraps things up with views on Bruno as a Postman alternative.
Vulnerability: Critical flaw in API portal allows SSRF attacks
This week, we have news of a critical vulnerability in the Perforce Akana Community Manager Developer and API portal. The flaw could enable malicious actors to perform server-side request forgery (SSRF) attacks.
Community Manager is a sophisticated tool that helps enterprises build an API portal to attract, manage, and support developers who create applications using their APIs. Organizations commonly employ it to develop and maintain developer portals for their APIs.
Server-side request Forgery (SSRF) is a vulnerability that allows an attacker to induce a server-side application to make HTTP requests to an arbitrary domain chosen by the attacker. In an SSRF attack, the attacker abuses functionality on the server to read or update internal resources.
The attacker can request internal services within the organization’s infrastructure that are not intended to be publicly exposed. This can lead to unauthorized access to sensitive data, performing actions on behalf of the server, or even enabling the attacker to execute arbitrary commands.
This critical severity vulnerability (tracked as CVE-2024-2796) has a CVSS base score of 9.3 and was disclosed by Jakob Antonsson. It affects versions 2022.1.3 and earlier.
It is recommended that organizations using the Akana Community Manager Developer Portal update to one of the patched versions immediately.
Article: How to secure GraphQL
While REST APIs still dominate as the primary API architectural style used in modern digital platforms, GraphQL is becoming increasingly popular due to its query-based approach. This approach allows clients to request specific data through a single endpoint using a flexible query language. GraphQL can be more efficient in data retrieval but may have a steeper learning curve compared to REST. GraphQL also presents some unique security challenges, and our next article covers many of these challenges and the best practices for overcoming them.
GraphQL can be more challenging to secure compared to REST APIs for several reasons:
- Complex queries: GraphQL allows clients to construct complex queries, potentially leading to resource-intensive server operations. Malicious actors might craft queries that cause performance issues or even bring down the server.
- Lack of built-in security: Unlike REST, which can leverage standard HTTP security mechanisms like authentication and authorization on a per-endpoint basis, GraphQL does not have built-in security features.
- Overfetching and resource exposure: GraphQL’s flexibility allows clients to request any combination of fields, including sensitive data. If not properly secured, clients might be able to access data they shouldn’t have access to, leading to data leaks or unauthorized access.
- Query depth and complexity: GraphQL queries can be deeply nested and complex. Without proper validation and limits, clients might send too deep or complex queries, causing performance issues or even crashing the server.
- Batched queries: GraphQL supports batching multiple queries into a single request. If not handled carefully, this can be exploited to bypass rate limiting or perform denial-of-service attacks.
- Schema introspection: GraphQL allows clients to introspect the schema, which can expose sensitive information about the API’s structure and available data types.
The authors recommend the following best practices for security engineers:
- Build an inventory of APIs to understand the full attack surface.
- Perform GraphQL API threat modeling.
- Talk with developers to understand their implementations.
- Implement best practices throughout the API lifecycle, including API gateways, secret scanning, testing every API release, and proper security monitoring.
For developers, they recommend the following:
- Limit access using authentication and authorization.
- Input validation.
- Rate limiting to block brute force attacks.
- Depth limiting to avoid DoS-style attacks.
- Schema whitelisting
- Limit the cost of GraphQL queries.
For further reading, we have covered GrahpQL in this newsletter here, here, and here.
Live Broadcast: Navigating the Depths of API Security Testing
On the back of their API Security partnership announcement last year, experts from 42Crunch and Microsoft take a dive deep into the underbelly of APIs and explore the vulnerabilities in your codebase. Join them in person in Seattle or online at Microsoft Build where they explore scanning OpenAPI specs to dynamic testing, to equip you with practical strategies to harden your APIs against attacks.
Article: Building bulletproof APIs
The next article is a well-articulated guide to building bulletproof APIs. By bulletproof, the author means meeting a broader range of non-functional requirements (NFRs) that go beyond pure security to encompass smooth operation, security, and scalability.
The author suggests four core principles for scalable systems, namely:
- Focusing on Resources: Simplify your API design by treating data as resources with unique identifiers rather than relying on complex methods.
- Self-Discoverable APIs: Enable clients to explore and discover available actions and resources within your API by incorporating HATEOAS principles. Include links in API responses that guide clients to related resources and actions.
- Managing API Evolution: Implement a well-defined versioning strategy to plan for future changes and enhancements to your API and ensure that updates don’t break existing integrations.
- Self-Contained Requests: Design your API in a stateless manner, where each request contains all the necessary information for processing. This means the server doesn’t need to retain any session state between requests.
To optimize performance and scalability, implement the following:
- Pagination and Filtering: For large result sets, use pagination to allow clients to retrieve data in smaller blocks and use filtering to limit data returned.
- Caching: Use caching mechanisms to store common data on the server side. This significantly reduces backend load and improves client performance.
To ensure reliability and security, implement the following:
- Error Handling and Response Codes: Design a consistent and accurate error-handling approach using standard HTTP response codes.
- Rate Limiting and Throttling: Implement safeguards to limit the rate of API calls to prevent abuse and being overwhelmed by excessive traffic.
Finally, the author identifies the following vital NFRs that should be addressed in robust systems:
- Performance
- Scalability
- Security
- Reliability
- Usability
The article emphasizes that considering NFRs alongside core design principles is crucial for building exceptional APIs. By adhering to these principles, developers can create robust, scalable, and secure APIs that deliver a seamless user experience and provide a solid foundation for future growth.
Guide: Damn Vulnerable RESTaurant
I am always pleased to see new tools in the API security space, and this week, I am happy to cover a new deliberately vulnerable API application entitled Damn Vulnerable RESTaurant. The project is the brainchild of Krzysztof Pranczk, who describes the goals as follows:
“I wanted to create a generic playground for ethical hackers, developers, and security engineers where they could identify, exploit, or fix vulnerabilities. Furthermore, security engineers could implement new vulns and test their detection tools because the Python FastAPI framework allows quick development,”
The vulnerable API service is designed specifically for educational and training purposes, catering to developers, ethical hackers, and security engineers. The project aims to create an environment that can be easily expanded with new vulnerable endpoints and mechanisms, facilitating hands-on training in detecting and exploiting identified vulnerabilities.
This training playground offers unique opportunities for various professionals:
- Developers: Engage in a dedicated game where you can interactively identify and fix vulnerabilities, enhancing your skills in secure coding practices.
- Ethical Hackers: Put your skills to the test by exploiting vulnerabilities manually or using automated tools. Approach it as a Capture the Flag (CTF) challenge, starting as a low-privileged API user and escalating to a root user. There is one path to achieve this goal, and API documentation is provided to guide your hacking adventure.
- Security Engineers: Utilize a range of security automation tools, such as Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Infrastructure as Code (IaC), to assess and refine vulnerability detection mechanisms.
The project can be found on GitHub and be easily deployed in Docker or directly into GitHub Codespaces.
Thanks to Krzysztof for the exciting project; I look forward to experimenting shortly.
Article: API security and fraud detection must converge
The next article explains why API security and fraud detection should converge to provide optimal protection against emerging threats. These two disciplines have traditionally been treated as separate entities, but the evolving threat landscape demands a more integrated approach.
Bots have revolutionized the fraud landscape, with APIs becoming their primary target. These automated tools enable fraudsters to carry out account takeovers, credential stuffing, and fake account creation by exploiting vulnerabilities in API systems. The article highlights real-world examples of API-centric fraud, such as inventory manipulation and scalping, loyalty and reward program API abuse, and gift card balance fraud.
The article advocates for a converged approach to API security and fraud detection to combat these threats effectively. This involves sharing data and insights between security and fraud teams to gain a more comprehensive understanding of risks. Behavioral bot detection systems that analyze API interactions and device fingerprinting are crucial in unmasking sophisticated bots mimicking legitimate users.
Silos between fraud and security teams create dangerous blind spots, leaving businesses vulnerable to API-based attacks. Fraud detection often lacks visibility into API-level attacks, while API security tools may overlook fraudulent behavior disguised as legitimate traffic. By integrating fraud detection, API security, and advanced bot protection, organizations can create a more adaptive defense capable of swiftly responding to threats and mitigating vulnerabilities.
In conclusion, a holistic strategy that combines fraud detection and API security is essential for safeguarding data, customers, and reputations in today’s API-centric world.
Article: Using Bruno as an alternative to Postman
Finally, we have news of another potentially exciting tool for API developers and their security teams. Bruno is a new open-source API client with the following goal:
“Bruno is a Fast and Git-Friendly Opensource API client, aimed at revolutionizing the status quo represented by Postman, Insomnia and similar tools out there.”
As one would expect, Dana gives this new tool a thorough walkthrough. In his in-depth review, he highlights several issues he encountered and offers his views on Bruno’s future. In meme form, here’s his conclusion:
Likewise, I am ready for a new API client and will soon take Bruno for a test drive and buy a license to support the project.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
