API Security Series Part 1: Authorization and Access Control issues in APIs
When we talk of modernization, SMAC (Social, Mobile, Analytics, and Cloud) comes to mind. All these individual technologies come together for Enterprises to transform themselves into digital businesses. Each of these technologies has a specific role to play and many times there is an overlap between them but there is a specific thread that binds all of these together and enables these technologies to act as the way they should. It is APIs and microservices. Without dissection of monoliths into small APIs sharing data, state, business logic, and applications it is hard to imagine SMAC or modern digital tech with the capability to change models and operations fast. The fact is that digital transformation is built on APIs.
APIs are an invaluable resource for your customers, employees, and partners. They help access the value you provide as a business in little pieces as and when needed. Your users can pick and choose what to take and what not to and hence they are engaged with your APIs a lot more than they were with yesteryear’s monoliths. The modern(Truly Modern!) application has brought all of these actors closer to your business. However, this has also brought the hackers and rogue insiders closer more than you would imagine.
There are vulnerabilities specific to APIs which can be understood with help of a comparative illustration between traditional and modern applications. At the first look, both seem the same but there are many small but important differences:
1. Data Processing: In the case of traditional applications the data processing happens at the server layer and the server sends a view to the client which is manifested by the browser. This makes the call between the client and server a single call and the role of the client is mainly to display the web page. While in the case of modern applications, with the increased processing power and faster network speeds the clients know better. Instead of making a single call to the server, the client asks for specific data it needs. This leads to increased traffic. This also leads to data filtering on the client side i.e. APIs exposing more data than is necessary. The API economy encourages developers to expose data in such a way that it can be used by many types of clients. So as a result we have a large number of APIs, increased traffic, and more data exposed than is necessary.
2. Communication: Traditional applications used XML, JSON, HTML for transferring data via APIs, and hence at every layer, there was supposed to be some code written to convert one form to another. In modern applications sometimes the server, client, and even the Database speak the same language: JSON. This makes it easy to implement the app without any abstraction as all layers may have the same models or have data stored in similar patterns. While this makes things easy for developers, it also makes it easy for the attackers to understand the underlying implementation of the app.
“by 2022, API abuses will move from an infrequent to the most-frequent attack vector, resulting in data breaches for enterprise web applications.”
*Source: Gartner, API Security: What You Need to Do to Protect Your APIs, Mark O’Neill, Dionisio Zumerle, et al., 28 August 2019.
The differences which we see, which are obvious, tend to have big ramifications as far as application security is concerned. The Web Page is less and less the attack vector of special concern, as this has shifted to direct attack on API requests. Apart from that, the types of vulnerabilities are significantly different from what we have tried to focus on in Application Security in the past. For Instance, the vulnerabilities such as SQLi have resolved automatically as there is increased usage of ORMs, the vulnerabilities such as XSS, Path Manipulation are either the responsibility on the client-side or a concern of the cloud infrastructure in modern apps which offers some respite. However, there is a different form of vulnerabilities which are conceptually not new but have become a major threat due to the nature of APIs. These vulnerabilities are broadly related to authorization and access control and while these two are also not new concepts but in the case of modern applications they have become too big and complex to manage.
The problem with authorization in modern applications is that it is ubiquitous. You can put authorization in code, in the gateway or you can have a specific authorization engine as a service. Hence, unless you have well-thought policies and a well-communicated plan for authorization in your systems there are bound to be APIs that leak some sensitive data. The illustration below shows this in a very simple manner:
The authorization here can be in the gateway, in the controller, or decision engine.
It does not end here, there are different types of authorizations as well. Function authorization, User Object Authorization, Data Object Authorization. This creates a complex web of rules to be implemented in a robust manner across the application code.
Another problem is of business context, which means authorization cannot have set patterns and rules that fit all applications. There is no possibility of having a syntax/semantics-based solution that can help solve the authorization problem for you. Just imagine the object authorization for a social media application like Facebook. Users can change settings like who can see what information for almost anything that you put on the web. Imagine the level of authorization checks and rules that the developer must keep in mind. For applications of such scale, there must be an org wide policy that governs the development. It cannot be solved with SAST tools or any other out-of-the-box solution available in the market.
With this, we come to the OWASP top 10. The OWASP top 10 are a mix of vulnerabilities which are from the 2017 OWASP Top 10 and new vulnerabilities related to access and authorization.
· API 1: Broken Object Level Authorization
· API 2: User Authentication
· API 3: Excessive Data Exposure
· API 4: Lack of Resources/Rate Limiting
· API 5: Broken Function Level Authorization
· API 6: Mass Assignment
· API 7: Security Misconfiguration
· API 8: Injection
· API 9: API Management
· API 10: Logging and Monitoring
There are surely some familiar faces in this list such as User Authentication, Rate Limiting, Security Misconfiguration, Injection and Logging, and Monitoring. These are the vulnerabilities that can be easily identified with help of a SAST solution. Our focus, however, is on vulnerabilities that are related to Access Control and Authorization such as API 1,3,5,6.
Why traditional SAST tools not capable of finding these vulnerabilities?
Well! SAST tools are based on ASTs at the code level. They try to find patterns in code that may lead to vulnerabilities. For example, usage of a poor or outdated encryption method is a big vulnerability but it is independent of how you design your application. It can be a vulnerability in a Monolith as well as a modern architecture. Then there are several vulnerabilities that are technology-dependent and based on the usage of programming language best practices. There is also data-flow for the identification of user-input security. What SAST misses is the application Context, and rightly so, as this can only be known to the architect, team leader, and member of the app. Without understanding the ‘system’ and ‘context’ it is hard to tell whether a particular API is in fact vulnerable or not. This system-level understanding of the application is important and with that understanding, you have to create rules based on the technology/framework you use and how various elements of your system interact with one another and which ones are sensitive or not, etc. Most SAST products today lack this capability.
What is the best approach for Authorization vulnerabilities?
1. Have robust policies related to authorization and access control
Unlike authentication, where if you follow the best practices and do it right your application can be protected against authentication vulnerabilities, authorization needs architecture and design level policies to be followed by developers. Such policies can improve the security of your applications significantly. Examples of some directives related to API security can be as follows:
- Always deny access at the controller level and enforce individual functions to provide access
- Always call authorization Engine when processing/sharing object data and IDs
- Always use authorization at the function level
- Use an application/platform level authorization class that is inherited by individual authorization artifacts
- Avoiding/Reviewing the use of functions that indicate Mass Assignment or Excessive data exposure
- Identifying sensitive data and reviewing APIs that expose such data
The list can go on and in fact, an initial level policy can be drafted based on recommendations provided by OWASP in their official API security knowledge base.
2. Have a tool/product that helps you check the adherence to the policies
The challenge is that in large applications/platforms where individual teams are owners of specific APIs it is hard to keep track of adherence? As I mentioned before that, semantics/syntax cannot solve the problem here as it is completely based on architecture choices and business context, teams need to bring in a system-level approach to solving this problem. An approach where checks can be made in the codebase that verifies each policy being followed or not. Another approach is to constantly review the APIs and their responses along with the calls being made to authorization functions. This can be part of a QA process where the Policies are checked against APIs and their design.
In the next part, we take on individual API vulnerabilities under focus and try to see with concrete examples how we can start to secure our APIs using CAST Architecture Studio to protect our API
