This week, we have views from the Google Cloud team on their four pillars of API security and a great article from the NewStack on using Cerbos to add permissions to your APIs. Dana Epp shares his thoughts on attacking predictable GUIDs when hacking APIs and, finally, a quick read on the developer’s need for integrated tooling.
Article: Google Cloud’s four pillars of API security
First up this week is an article from Google Cloud where they share their four pillars for API security. The article highlights the findings from Google’s own Apigee platform and their 2022 report on API security insights and trends (featured here in issue 210). From Apigee comes the finding that API traffic increased by 46% between 2019 and 2020. In 2021, more than half of organizations experienced a security threat related to APIs.
Google used its own research to identify the five top threats to APIs, namely:
- Data scraping: exfiltrating excessive amounts of data via APIs by abusing pagination or enumeration schemes.
- Denial of service (DoS): attacking APIs (via volumetric attacks or distributed bots) to prevent legitimate access from users.
- Injections or malware: using APIs as a point of inject for either malware (for example, a file upload) or injection of malicious code.
- Account takeover (ATO): abusing password reset mechanism provided via APIs in order to take over accounts.
- Scalping and bots: bots can be automated to purchase limited availability goods or commodities for resale at elevated prices.
The most telling findings from Google was that over 60% of organizations need to improve their API security strategy if they even have such a strategy in the first instance. According to Google, the two main challenges organizations face when building an API security strategy is a lack of resource (primarily human) and a lack of expertise.
Their four pillars of API security are:
- Basic API security controls and protections are enforced for all APIs through a central API management platform โ a uniform baseline policy is applied to all APIs under governance without exception. This policy includes the basics such as transport security, rate-limiting, and bot defenses.
- Protection against DDoS and exploits โ leverage modern cloud protection suites that include WAFs, DDoS protection, and a threat intelligence capability.
- Anti-bot protection โ to keep APIs and exposed resources safe from fraudulent activity, spam, and abuse.
- Use safe API coding principles โ create a shift-left security culture where developers understand the importance of producing APIs that are secure by design.
This is sound basic advice from Google โ use defense in depth and ensure good coverage with good defaults, and build from there.
Guide: Add access permissions to your API with Cerbos
Poorly implemented API authorization leads to two of the most prominent classes of API security vulnerability: API1:2019 โ Broken object-level authorization and API5:2019 โ Broken function-level authorization. As readers of this newsletter will know, the most frequent cause of this class of vulnerability is poorly implemented back-end permission controls. In this guide from the New Stack, the author discusses the benefits of using a standard authorization (or permissions) framework to ensure that access control is applied in a uniform and consistent manner.
The author highlights the most important benefit of an authorization framework โ namely, that developers can focus on implementing functionality and rely on a central enforcement point to ensure that access policy is applied correctly. In this article, the author focuses on Cerbos, one of a number of open-source authorization frameworks using a basic Python Flask application.
There are three basic steps in setting up Cerbos, namely:
- Deploy and run Cerbos
- Define your policies
- Check permissions
Policies are defined in an easily read markup language shown below:
---
apiVersion: "api.cerbos.dev/v1"
derived_roles:
name: todo_derived_roles
definitions:
- name: admin
parentRoles: ["admin"]
- name: user_that_owns_the_record
parentRoles: ["user"]
condition:
match:
expr: request.resource.attr.user == request.principal.id
- name: any_user
parentRoles: ["user"]In the client code, the developer only needs to make a call to the central Cerbos server with the current user and target resource in order to determine if the user is allowed to access the resource. The decision logic is decoupled from the enforcement point, allowing for a more flexible and scalable solution overall.
There is no shortage of excellent authorization frameworks โ make sure your developers are using these rather than re-inventing the wheel.
Article: Attacking predictable GUIDs when hacking APIs
One of the hallmarks of modern digital systems is the redoubtable globally unique identifiers (GUIDs) (also known as universal unique identifiers (UUIDs) ) which act as a unique identifier to underlying data or information. Think of a GUID as a pointer to information on a server โ when a client access a resource, it is given a GUID to identify the resource (to point to it) in future transactions. If an attacker is able to guess a valid GUID they can quite easily launch attacks against a target system.
In one of his most recent articles, the equally redoubtable Dana Epp provides a fascinating overview of how it is possible to attack systems using v1 GUIDs by predicting a range of valid GUIDs based on their predictability within a time window. Epp has even provided a Python script to generate candidate GUIDs, and perform time drift calculations to account for time differences between client and server.
As Epp concludes:
If you ever find a target API that is using v1 GUIDs in an endpoint, and that endpoint is relying on the GUID as part of its business logic, you have an opportunity to predict it, and pwn it.
Article: API security needs integrated tooling for developers
Toward the end of 2022, the API World event was held in San Jose, bringing many of the luminaries of the industry to share their views on the future of the API industry. Needless to say, API security was front and center of the discussion, and 42Crunch was represented by our co-founder and field CTO Isabelle Mauny.
In her keynote address at the conference, she stressed the importance of a balanced view between a shift-left and, simultaneously, a shift-right approach to API security.ย Developers play a vital role in ensuring API security, and API security has never been more important. Experts believe developers need security tools integrated into workflows now.
According to Mauny:
“Empowering developers means that you’re going to give them specific tools made for them, not for security people,”
Event: 42Crunch at DeveloperWeek in SF Bay area, 15th – 17th February
Next week I have the great privilege of presenting not once but twice at the Developer Week conference in the San Franciso Bay area from the 15th to the 17th of February.
The talks are as follows:
Are Your APIs Rugged? โย Thursday, February 16, 2:30 pm – 2:55 pm PST
Everything You Need to Know About API Security โ Friday, February 17 โข 1:00 pm – 1:50 pm PST
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
