In an era of increasing use of API, it’s important to stay up to date with proper implementation and be wary of the vulnerabilities that are being exploited in 2022. It’s being said that up to 83% of web traffic is made up of API requests. According to the Open Web Application Security Project (OWASP), there are vulnerabilities that you should be aware of when configuring an API.
Many organizations believe that scans done with Nessus, Burp Suite, and other vulnerability scanning tools are enough, but more than often, the weakness isn’t in the API itself, but rather its business configurations.
This blog post will cover the basics of API, the top vulnerabilities, and provide examples, mitigations, and some best practices for API configuration.
What is API
API stands for application programming interface and is defined as “a set of functions and procedures allowing the creation of applications that access the features or data of an operating system, application, or other services”.
For example, websites often have links such as “read more” or “view transactions” which provide more specific information than the webpage. When a link is clicked, a GET request is usually done by an API that carries our request to the server or database. A metaphor or real-life example of this is that the API is a waiter in a restaurant that takes our order and tells the kitchen what we want. We are the client, the waiter is the API, and the kitchen is the server or assets.
Most organizations use API nowadays for web applications or mobile applications that serve data or resources of some kind, but it is a few organizations that know how to configure their business logic properly and accordingly. From what we have experienced, it's often business logic flaws that are the problem. It is not only the small organizations but also everyone who either slacks on their configuration or simply lacks the knowledge for testing their APIs.
It is estimated that up to 83% of the web traffic is API traffic[1] and the number is only expected to increase in the near future!
A survey done by Salt Security estimates that out of 200 enterprises, 91% had experienced some form of an incident regarding API security. This could be a representation of the disregard many have towards configuring an API properly. A common misconception is that if you use a known and common API, it’s safe by default. This has never been the case and has led to many cases of data breaches such as the recent attack on one of the largest attacks in Australia on a telecommunication giant, Optus.
As Troy Hunt says[2], “the vulnerability has been described so trivial it’s entirely possible that it was exploited by other parties as well”. However, recent reports say that an API was misconfigured.
It was estimated in a press statement that the personal data of 9.8 million customers was exposed during the leak. In the following investigation, Optus also confirmed that a total of 2.1 million customers had valid or expired ID document numbers and 1,2 million of these had valid forms of identification, and 900,000 had expired ID numbers.
The attacker originally attempted to extort Optus for 1 million dollars with a ransom if the attacker wasn’t to leak or sell the data.
Later, the attacker leaked 10200 Australians’ IDs due to no ransom being paid.
This led to the investigation being escalated, causing the attacker to become paranoid and come out with an apology to both Optus and the compromised Australians.
Claims were that they would have reported the bug if there was a security mail, bug bounty, or any way to message. Like many other organizations, nobody wants to be on the losing side nor take the blame and admit to having made such a common misconfiguration.
While there isn’t much to find on the current leak, a vulnerability disclosed by OWASP is likely exploited, even more, possible that the vulnerability is on the top three due to the nature of this “trivial vulnerability”.
OWASP API top 10
While API is useful for enabling and facilitating communication between applications and is an essential part of the technology we use today, it is still important to know the vulnerabilities regarding API. OWASP (Open web application security project) has created a “cheat sheet” containing the top ten API vulnerabilities. [3]
The top three of them are:
A1, Broken Object Level Authorization
A2, Broken Authentication
A3, Excessive Data Exposure.
Broken object-level authorization
Broken Object Level Authorization attacks means that we can gain access to recourses and data we shouldn’t be due to wrongfully applied authorization. It is typically exploited by a user inputting information somewhere, whether it is a form or changing other values When talking about an object it can mean what resources it might contain, such as a blog post containing comments or likes.
An example of this is if we have a URL called https://importantdocs.com/docs/1234.
Now the document ID is in this case 1234. We know that because we can access the document currently assigned to us as a user. If we changed the message ID to 1235, we shouldn’t be able to access that, unless it of course is our assigned document. When the API makes the query while properly configured, it shouldn’t return anything. If the API isn’t configured properly, we can access some important documents that we never should have access to!
An example of this is not long ago when U.S. Postal Service got breached and an attacker got access to over 60 million users’ information.
To prevent this the API should check for the required access level for the requested data. Another mitigation could be to use dynamic application security testing (DAST) to not only find BOLA vulnerabilities but also other exploitable open-source vulnerabilities in the tested application.
Broken Authentication
The term Broken Authentication covers several vulnerabilities in the API that the attackers use to gain access or impersonate legitimate users. A vulnerability in the process of validating a person or entity. When this authentication mechanism is missing or lacking, an attacker can imitate another user either permanent or temporary.
Broken Authentication use cases are unprotected APIs that are considered internal, weak authentication not following industry best practices, and lack of access token validation.
Some people talk about broken authentication in two categories: bad session management and poor token management. A mitigation for this is to start by using industrial standard authentication mechanisms while there are plenty of open-source standards to use. Ensure that all functionalities and sensitive data are protected. Also making sure that the API tokens are random and unpredictable strings so they cannot be brute-forced.
Excessive Data Exposure
Excessive Data Exposure use cases are when APIs return full data objects as they are stored by the database. Client application shows only the data the user needs to see, however, an attacker can call the API directly and the API will return more data than it is supposed to.
Imagine asking a question to a person standing in front of you. You ask him how many degrees the weather is today. Not only will the person answer your question, but they will also tell you about all other information regarding the weather or maybe even something that’s not relevant to your question. To mitigate excessive data exposure for an API, a measure is to stop users or clients from data filtering. Also, be careful of the return messages to the user. Too much information may be a way for the attacker to gain further information about your systems and if using open-source software this can lead to a further and more specific attack on your system.
Best practices for API configurations
When configuring your API, there are some best practices you should keep in mind and try to achieve. Swagger has made a list containing some useful reminders:
Easy to work with: This should be easy to work with and understand. The developers should also be able to remember the names of the resources they’re working with continually.
Hard to misuse: Make sure to streamline the process of writing your API, so that incorrect code can be avoided. Furthermore, when it comes to error messages, there should be somewhat precise errors on the end-users side so they don’t have guidelines for the API.
Complete and concise: A complete and concise API makes it possible for other developers to make full applications against the data that you and the API exposes. Often, making a complete API and application is an over-time process. Don’t expect your API to contain and be precise as you want it the first time. Expect to continually expand and develop it.
Some might think that this doesn’t seem like a big deal, “My information is not critical or sensitive”. It is about data confidentiality. It is a matter of protecting data from and of individuals and organizations. The definition of confidential data is that it is not publicly available.
Why do we have to protect data in the first place?
“Different organizations have different requirements relating to when they must or wish to protect the privacy, security, and confidentiality of data so that people, households, and organizations can’t be identified without their permission.”[4]
When speaking of identifiable data, we refer to data that either directly or indirectly identifies individuals or organizations. It could be information such as names, addresses, or employees.
Sometimes it is also a requirement by law to keep data confidential. Not all data is required to be confidential, but when disclosing identifiable data, it can be breaking the law.
Best practices for protecting your data confidentiality
While and organizations have different ways to secure confidential data, there will always be some common or best practices when we want to safeguard the data.
Make data security a job
When handling confidential data, it doesn’t just automatically become secure, even if you want it to. Assign a responsible employee who knows how to handle data or hire someone externally to deal with these matters. This includes making a ruleset for employees and the organization to follow.
Know the regulations and legislation
By keeping up and knowing the legislation regarding confidential data, the organization can act accordingly and be more aware of the dos and don’ts when it comes to managing and handling confidential data.
Password protection and data encryption
If a breach should happen, we don’t want the bad guys to have an easy time reading your secrets or confidential data. Therefore, strong encryption should always be applied when it comes to confidential data. Password policies are also a must-have in every organization. Multiple studies reveal that users tend to slack when it comes to creating a strong password, so when making a password policy for your organization, be sure to follow a recommended guideline on how to do so.
Limit the access
We don’t need every employee to have access to confidential data. Make sure to think about the individuals who need access and blacklist everyone else.
Store physical documents safely
A paper can end up anywhere. Some old-school employees might prefer to have a hard copy of whatever document they might be working on. Consider the right way to handle printing out confidential documents, who has access to them, and be sure to lock important documents somewhere safe or destroy sensitive information that is no longer required or needed.
Conclusion
Misconfigurations of APIs are more common than we want to admit. It’s important to know the do’s and don’ts to ensure proper and secure API configuration in an organization.
While implementing and securing an API can be both complex and tedious, losing millions of records is even worse.
When using API, it is important too, always read the documentation thoroughly and make sure you follow best practices regarding securing your API.
Remember to use Unique identifiers, and add proper authentication on your objects making them non-accessible to unauthorized individuals. In general, be aware of the common API vulnerabilities and make sure to avoid them, it is around 80% of the web traffic after all.
[1] Issue 17: 83 percent of web traffic is API, and why query parameters are bad for secrets - API Security News
[2] Optus data breach: everything we know so far about what happened | Optus | The Guardian
[4] Data confidentiality principles and methods report - data.govt.nz