return
As developers and/or responsible for the security of a company, application, information and a long etcetera, we must be able to define the limit of right and wrong when building and designing the security architecture of it, often happens that in the process we forget to take into account the most common mistakes made by other developers or that we also forget the main interests of the attackers. If we were to keep up to date on our own, it would be a titanic task since the vulnerabilities and the attackers' interests for new ones, have an exponential rate of variations.
This raises several questions when it comes to proposing a secure design of a web application, web service and/or mobile application; One could easily say that the most convenient thing to do would be to put together a list of the most known vulnerabilities based on personal experience, but there we would only be taking into account a single view of the situation, although it is desirable that companies have a history of previous vulnerabilities or failures to be able to apply them to continuous improvement, it is also true that this history will be based on a single type of architecture and/or a single type of application. In the short term, this may not have an impact at the enterprise level, but if the enterprise is constantly immersed in innovation processes, as it should be, it will always find itself in the dilemma of constantly changing the architecture and proposing improvements to the usual processes developed on a daily basis, leading it to implement new functionalities and new technologies that could be at risk under the perspective of this history (based on an obsolete architecture).
That is where we need to start from scratch, which will provide us with new points of view. Why invest efforts in gathering statistics and building history if there may be someone who has done the same thing before but not only referring to a particular architecture, but also to many situations that have occurred applied to different fields.
The case I mention is the case of OWASP, (Open Worldwide Application Security Project). A project that arose out of the need to highlight the most common interests of attackers based on the mistakes that developers make throughout the software development cycle, the OWASP community is made up of companies, educational organizations and individuals from all over the world. Together they form a computer security community that works to create articles, methodologies, documentation, tools and technologies that are freely-available and can be used by anyone. Updating the main trends, as a consequence of the existing improvements in secure development processes. This organization that was born focused on errors associated with web applications, today has several versions to its credit, typifying the most exploited vulnerabilities and grouping them according to the nature of the application. We currently have OWASP Web, OWASP Mobile, and OWASP API, which will be detailed in this article:
OWASP - API 2023
A fundamental element of innovation in today's application-driven world is the application programming interface (API). From banking, retail, transportation to IoT, autonomous vehicles and smart cities, APIs are a fundamental part of modern mobile, SaaS and web applications so as they are commonly encountered at the client level they are becoming a prime target for attackers, in the face of carelessness in implementing them.
While the concept of an API is simple, a service that is providing a resource and an interface on the other side consuming the various features, as shown in the image;
Most developers omit the process of securing them, perhaps because of a false sense of security that leads them to think that an attacker, unaware of how it works, will not target these services because they are outside the attack surface. When in fact the opposite is true.
The following are the 10 most frequent vulnerabilities in this area:
API1 - Broken Object Level Authorization
Object level authorization is an access control mechanism, usually implemented at the code level, in charge of validating that a user accesses only the objects he is allowed to access. Assuming the case that a user presents his credentials to the interface hosted on the phone and then he himself wants to access another resource provided by the service, as follows:
API2 - Broken Authentication
This flaw, also common in web applications, can manifest itself in several vulnerabilities because when we face an API endpoint, there is an initial challenge to be able to consume it and start exchanging resources.
There are several cases where this may occur:
API3 - Broken Object Property Level Authorization
This category of vulnerabilities, combines two vulnerabilities described in the 2019 revision associated with APIs, where we have Excessive Data Exposure and Mass Assignment, basically focused on the manipulation of sensitive information and the exposure of this type of information, referring to the properties of objects.
A simple example of this vulnerability could be the following ;
API4 - Unrestricted Resource Consumption
Some queries require resources such as bandwidth, CPU consumption, memory and storage and others have this processing capacity relegated to the service providers, since it is very likely that not all the APIs of an application are under the control of the company that develops the application. Many frameworks use third-party APIs and pay for each request, so these attacks are associated with damaging the maintenance costs of these APIs. perjudicar los costos de mantenimiento de esas APIs.
For example:
API5 - Broken Function Level Authorization
First of all, attackers look for a target that contains two or more types of accounts. It could be a common user in charge of the usual tasks worked on his profile and in another case it could be an administrator user, in charge of having an overview of the whole issue. By capturing several calls to the respective API the attacker finds a hidden parameter that refers to the account type, so he proceeds to change it, allowing access to a function of another user that does not correspond to his tasks.
In summary, within the authorization management, these vulnerable APIs do not correctly control access to functions that correspond to more advanced profiles.
API6 - Unrestricted Access to sensitive business flows
When creating an endpoint it is very important to understand which are the most important business flows, usually those that carry the most critical information of the company and operations, so protecting them becomes the main task of every programmer. If these flows are exposed, we could have a medium to critical impact on the operation of the application depending on the business flow that has been exposed through these failures.
Some of the most common examples of exposed business flows are in the following situations:
As we saw in these three cases, APIs present these vulnerabilities because authentication is not required to use these resources. So it allows a user to bypass the normal flow of the application and go to alternative flows that do not correspond to their natural flow of the application.
API7 - Server Side Request Forgery
This vulnerability occurs when an API allows server-side HTTP queries to an arbitrary domain chosen by the attacker.
This allows an attacker to connect to internal infrastructure services where the API is hosted and leak sensitive information.
The cases are varied, but let's look at how an attacker could steal a company's AWS keys.
API8 - Security Misconfiguration
As in web applications, there are bad security configurations in APIs. This occurs when the correct hardening of the platform is not applied or there are misconfigured permissions when deploying them. Among the issues to be reviewed, developers usually omit most security issues due to the lack of automation in the testing stage. Among the possible misconfigurations are the following:
API9 - Improper Inventory Management
APIs tend to expose more endpoints than traditional web applications, leading developers to create corresponding documentation of the operation of each of the corresponding APIs. The appropriate inventory must be relieved because if the documentation is lost or leaked, attackers could expand their attack surface by maximizing their knowledge of how to handle the exposed services.
This vulnerability, coupled with the lack of protection, becomes the main time bomb associated with these issues. We must always ask ourselves, for each API, if all current endpointsshould be available, in order to apply the principle of least privilege to the entire architecture configuration.
In an example case, let's suppose that we have additionally the following url:
⦁ < http://WEBSITE:5555/api/v2/res//all >
If we pay special attention to the construction of the url we realize that we are working with version 2 of it, an attacker who understands this type of operation could replace the v2 by a v1, to see what modules were available related to the previous version of the API. It often happens that developers restrict modules that they do not use in the new version, but neglect previous versions that could be active as a result of an incorrect survey when building the inventory.
API10- Unsafe Consumption of APIs
Developers tend to receive data from third-party APIs, often those consumptions that are under the orbit of the enterprise architecture do not have a security treatment adequate to the rest of the flows of the application that consumes these services.
Therefore, the neglect of these components generates an interesting attack surface for the cybercriminal's perspective since they can use these resources to damage the operation of the application.
As shown in the image, if we have our API endpoints and they are controlled, for example, by a third-party API Management, an attacker who finds a flaw in this third-party component will be able to breach the entire previously designed architecture. That is why developers have to be constantly aware of the flaws that may exist in the systems that are contracted and outsourced.
Recommendations
When thinking about how to protect ourselves against these issues, we would say that what we need to do is to increase our awareness of the IT assets we deploy when we build an application. It is important to follow the OWASP recommendations regarding each point in order to be able to execute a correct implementation of the APIs and not abuse the potential ignorance of the attackers. We invite you to visit the OWASP API security Project, for more specific solutions in each case. If you liked this post and want us to make one related to the recommendations, leave it in the comments.
Conclusion
The main mistake is first of all to believe that nobody will pay attention to a certain point of our architecture and added to that to believe that security by obscurity (Use of the secret design as a protection measure, security by ignorance) is the most effective mechanism to defend ourselves when in reality, in many occasions the attackers know more than us of our own application.
