API’s Security 101 (2022 edition): Part 1
This post is the first one out of a series of two. The second post will describe a hands-on attempt of penetration testing on an API that we can do in our local machine.
Why a New Post About API Security? A Global Pandemic Was Not Enough?
API Security has been too many times considered as one of the most boring topics in the history of software development. However, it is not at all! It’s funny, it’s exciting and most importantly, it can make we lose our job! This is the reason I wanted to write a not-so-serious post about this topic, focused on making this topic easier to bite as well as having a look to some hands on experience later on. Security can be a complex area and we, people with some experience in the sacred field of coding software and bringing it to production, have made mistakes sometimes as big as gothic cathedrals. Learning from past errors are invaluable learnt lessons.
So, relax, grab a mug with your favorite beverage and be ready to be assaulted with a brilliant writing adorned with stupid and inconvenient memes and quotes completely out of context.
Let’s start with a glimpse about the subject in three simple rounds.
First Round: There are More and More APIs
What can we say? APIs are growing in number. APIs are everywhere. Especially REST and REST-like APIs, for now. The bigger importance of APIs in the integration area makes them a bigger target for attackers.
They are hosted mainly in AWS: EC2, EKS, etc. AWS is certainly the most popular and used cloud provider and probably this factor does not necessarily mean AWS is more vulnerable than the rest of providers. However, the more used is a platform, the more attention is payed by attackers. We saw something similar with Microsoft Windows. It is thought the most attacked platforms will invest more in security but this is a harsh race and it’s difficult to know who’s winning at any specific time.
Second Round: More APIs, More Traffic, and Apparently, More Bad Guys
Well, it doesn’t look good. Although security companies are trying to sell their products, it looks like bad guys are having a good time and they have attacked commercial APIs, in an increasing way in the last year. The bigger are the figures in traffic volume the bigger are the number of attacks. It is a logical effect. APIs have become into one of the most important ways of exposing services and are essential to e-commerce applications everywhere:
- API calls currently account for 83% of all Internet traffic according to Akamai.
- Around 40% of organizations reported that more than one-half of their applications are exposed to the internet or 3rd party services via APIs.
So, the vulnerability surface has grown and most likely, attacks are more and more frequent. Also, security companies release the results of some surveys:
- Nearly 66% of enterprises don’t have a proper security measure for their APIs.
- Attacks targeting APIs are increasing at an alarming rate — up 681% in 2021, reported by Salt Labs.
Third Round: APIs are Attacked in Many Ways
So, it is clear that we can expect security concerns will keep on growing in 2022. Let’s have a look at the more frequent types of attacks to APIs.
The results of the The State of API Security assessment are not a major surprise between security specialists. This is the list about the most commonly found errors:
- 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 (Personal Identifiable Information) issues: In addition to other data leaks, several APIs were also leaking sensitive personal information (such as healthcare records, but also anything that would allow to identify an individual with no mistake).
The question is, are these figures representing real attackers or are they mostly bots in reconnaissance tasks?
Reconnaissance is the first phase where the attacker tries to collect information about the target. It may include identifying the target, finding out the target’s IP Address Range, Network, DNS records, etc.
This could explain the huge increase of attacks to APIs in the last year. A bot attack usually happens abruptly and stops in the same way.
We should trust on security companies. Some times provided figures are probably too high if we think of these attacks as manual actions by humans. Bots are everywhere and they are extensively used to detect vulnerabilities in APIs as well:
- Attackers use automated tools to make bots attack nonstop.
- Attackers own countless credential information to support bot attacks that involve identity verification.
- Attackers gain access to hundreds and thousands of mobile devices via one group/cloud control platform to help bots bypass device detection.
Either way, we should fear a human attacker fixes his/her attention to our API. Depending on the skills and used tools our API can be in danger if we have not adopted standard security measures.
Main Types of Attacks to APIs
They are quite common to regular HTTP attacks but including some specific logic for APIs. We assume REST, REST-like, RPC API styles are more attacked because they are the most of APIs. GraphQL and gRPC APIs are also vulnerable and mitigations should be applied on these API styles as well.
The infamous OWASP Top Ten API Vulnerabilities are still the most frequent types of attacks to APIs. Please, have a look to the cheatsheet describing them.
You can also watch this video about the same topic..
Services like Web Application Firewalls (WAF) are supposed to protect web apps and APIs against most common attacks using for instance SQL Injection and cross-site scripting , in cases where an underlying application is still vulnerable. Akamai, Google Cloud and AWS offer this type of service. But it is not perfect and it still shows some vulnerabilities as we can see in the post below:
It’s obvious there is not a silver bullet in the world of API security. So, we should design and plan a defense in depth, with multiple lines covering all the areas we can imagine.
What we cannot do..
Take Wrong Assumptions
My API is not going to be attacked because they never could get anything meaningful. This is usually true and therefore I’ll trust on the good intentions an benevolence of API attackers.
Ignore the Network
My app is running OK and I don;t care about the network or the network topology. I don’t care if it is internal or external. nothing to do with my business.
Blind Trust/Defense in One Line
I always apply security to my API I use API Keys (or Basic Authentication). It’s more than enough!
Mismanagement
I’ve seen things you people wouldn’t believe. API keys and secrets sent in an email with 20 people in CC. I watched API architects glitter in the dark saying they don’t need any security at all or returning the content directly from the database, with no filtering. All those poor APIs will be lost in time, like tears in rain. Time to die.
An Anonymous API Security Architect
Sending secrets, passwords, etc, clear text without any obfuscation is not unusual in 2022. API designers that don’t consider ANY security measure neither in the API contract nor during the implementation are frequent cases. Lack of segregation of roles is also one of the most common issues.
What Tools Do We Have?
API Gateway
The API Gateway is an essential component in the Security plan. It makes much cheaper to apply security measures at this level because… it doesn’t require any implementation!. Also, the API Gateway will be key to integrate your APIs with the ID provider with no modifications in your code.
Authentication + Authorization: Trust the Identity Provider
The Enterprise Identity Provider (IDP or EIDP) is the common tool for federation of identities in an organization, allowing to set groups, roles, permissions, etc. It is the base for Role-Based Access Control (RBAC).
It is strongly recommended to integrate the access to your APIs with the IDP. Preferably, by using an authentication and authorization protocol like Open ID Connect (OIDC). You could wonder? Why OIDC instead of OAuth2? Well, OIDC actually extends the OAuth 2.0 authorization protocol for use as an authentication protocol, so that you can do single sign-on (SSO) using OAuth2. Also, OIDC introduces the concept of an ID token, which is a security token that allows the client to verify the identity of the user. The ID token also gets basic profile information about the user. It also introduces the UserInfo endpoint, an API that returns information about the user.
In the end, the goal is to pull out any authentication/authorization from the API or the API Gateway to the tool that has been designed and placed to manage identities (which is, the IDP). OIDC was built on the top of OAuth2. Choose the right flow (for instance, Authorization Code for your external users or Client Credentials for service-to-service communications) and the APIs will be more protected from non-authorized access.
WAAP
For externally accessible APIs, Web Application Firewall, Bot and API protection (WAAP) services should be mandatory. These services also allows the configuration of burst limits to incoming requests per IP and can detect some attacks. Akamai is a good example of providers of this type of service, for instance.
Security Plan
All these tools are useful to architects to make the Security Plan as an implicit part of the architectural design. The Sec Plan is a good place to design the layout of our defense in depth. It should include also the CI/CD pipeline to include automatic penetration tests as part of the quality score so that the version is not released if the penetration test is not passed.
To summarize, just pay attention to Security, you API owners and architects, or some guy from the Cybersecurity Department could get angrier than usual..
Adopt a Security Strategy for your API
Let’s have a look at some options we can adopt regarding the security of our APIs:
Strategy 1: Do Nothing and React Lately to Security Reports
This strategy consists on not worrying about security at all and wait for the security report failure. It is based on reacting to found security flaws, then analyze, fix, release and wait for the next failure.
Definitely, not recommended.
It sounds terrible but it is actually what I ‘ve found in many software projects in the past and it is probably still happening right now. It is not about the quality of standard security analysis and penetration test. They can offer a coverage of most of the common cases. The problem with this approach is, it is slow, it is based on a culture that reacts to problems, not trying to foresee the potential issues of the product and anticipate to whatever is going to happen.
Strategy 2: Be Paranoid
Well, this is more an attitude rather than a real strategy. Nevertheless, it’s the best advice in the world of Cybersecurity. As a famous hacker said once, this is about who’s the most paranoid guy in the game. We are going to be attacked and we have to verify everything all the time. Zero Trust policies will drive us through the right way. Let’s enthusiastically adopt this point of view! Besides, it’s the right way to move to the strategy number 3. The only real strategy here :P
Strategy 3: Red Team or DIY
We have to understand API attackers by putting ourselves in their shoes. I cannot imagine a healthier way of designing the measures of our API Security than adopting the role of our potential enemies and start thinking about how to penetrate our security so that we can exploit the exposed data.
Let’s sidebar for a moment. In my experience, attackers make the best defenders. This is not to suggest you recruit your InfoSec staff from PLA
Unit 61398 or Lazarus Group. My definition of an attacker is someone with an offense-oriented mindset and expertise — a “breaker.” Breakers have a much better grasp on the art of the possible.Chris Eng Chief Research Officer, Veracode
The Red Team strategy is more proactive, involves the whole team and it is extremely beneficial:
- It encourage teams to learn more about security.
- They are more aware about risks.
- It’s always stimulating to be challenged by our colleagues to find new ways to fix the vulnerabilities of our software and systems.
Please, have a look to this amazing post by Victor Ratón about Chaos Engineering. A similar approach can be taken in the Security area.
Now, repeat..
This is about including automated Penetration Tests in the CI/CD pipelines of the services implementing our APIs. To do this we need to deploy out API in a test environment, get some test data and infrastructure to achieve a production-like scenario. The result of the automatic Penetration Test has to be part of the Quality Gate. We cannot release a new version if the Penetration Test is not passed.
Is the Red-Team approach too much for your API? Well, if you assume a Zero-Trust environment and you are exposed to the Internet, I’d recommend Red-Teaming as good practice. Automated penetration tests will be useful for more common vulnerability detection by bots. But if you API deserves the special attention of a human hacker, you’ll be thankful of this practice that made possible the early detection of vulnerabilities in your API.
Go and Hack Yourself
The very purpose of the Red Team Strategy is, the team (or at least a part of it) is challenged to hack the product they have created to find unexpected vulnerabilities and subsequently, exploit the breach. They know the details of the software, the implemented functionalities and they should be aware of its weaknesses and the real surface of attack.
I want to show this methodology and the structure of a common attack in a simple way with a basic example and tools. However and even it is a basic example (just to get some familiarity with API Security stuff), it takes a lot of space for one post. That’s why I prefer to publish a second part with the description of our API Security experiment.
So, see you soon in part 2 with the hands-on practice!
We’re gonna need some reading for the meantime. Firstly, subscribe to the apisecurity.io Newsletter. I’ll also recommend The Daily Swig, an excellent journal about the many topics in Cybersecurity. Have a look, it’s pretty up to date!
