Mitigating OWASP Top 10 API Security Threats with an API Gateway — Part 4
Injection, Improper Access Management and Insufficient Logging and Monitoring
This article is the 4th and final part of a series aimed at bringing awareness to OWASP Top 10 Security Threats and how they can easily be mitigated using a good API Gateway.
Read Part 1, Part 2 and Part 3 if you missed it.
This article will focus on the final 3 threats from the list: Injection, Improper Access Management, and Insufficient Logging and Monitoring.
8 — Injection
Injection attacks occur when untrusted data is passed on to an interpreter via a data submission method such as a form that the API or backend blindly executes. This can have harmful consequences on the application and its data.
Interpreters that are targeted by attackers may include:
- SQL
- NoSQL
- LDAP
- OS commands
- ORM (Object-Relational Mapping)
- XML Parsers
For example, let’s assume there was an SQL statement such as the following:
"SELECT * FROM users WHERE id='1012'"This would successfully return the details of the user with id 1012 (see Figure 2).
An attacker could easily perform an SQL injection attack by just altering the inputs that are submitted.
By just filling the password field with the text “password’ OR 1=1” the SQL statement will be transformed as shown below.
"SELECT * FROM users WHERE id=' or '1'=1"The OR 1=1 statement causes the WHERE clause to return the first id from the users table no matter what the username and password are. As the very first user id of a database is most likely the administrator, the attacker can bypass authentication and possibly gain administrator privileges, which will be devastating based on what the attacker’s intentions are.
In this case, Allan Trousdale alters the GET request query parameter id to ' or '1'=1. Since the backend directly converts the API call into the SQL statement, this altered parameter is appended to the SQL statement and executed, which will return all records in the database table users .
Further control of the database can also be taken by commenting out the rest of the SQL statement. Query Parameterization is the first step to prevent SQL injection attacks but is not without its drawbacks.
How can this be mitigated?
An API Gateway will act as the secure interface to the API and also identify for and reject API calls that contain malicious data in:
- HTTP headers
- Query parameters
- URI paths
- Request payloads.
In this case, with an API Gateway in place, Allan Trousdale will not be able to exploit an SQL injection attack and will receive an error message instead.
Many modern API Gateway solutions go a step further in providing additional protection against different types of injection related attacks, such as Regular Expression Threat Protection and Message Mediation both of which allows for maximum customization of how an API Gateway should react in the event of such an attack.
9 — Improper Assets Management
Older versions of APIs are extremely vulnerable since they are often not patched and leaving them unattended could mean that an attacker could easily compromise the system without having to worry about complex security mechanisms to bypass.
In addition, outdated documentation makes it even more difficult to identify and fix vulnerabilities. An inadequate retirement plan for each API version is also another major cause of this vulnerability.
An example of this type of vulnerability is when major changes have been made after a redesign of an application including some security enhancements, a new version of the API has been created at /v2/customer-info (see Figure 5) to fix issues that allowed the former version of the API to expose too much data while the old API at /v1/customer-info is still kept running, unattended.
However, if an attacker finds that version 1 of the API address is still active and exploits the vulnerabilities of the old API (i.e. exposing sensitive information like credit card numbers and social security numbers), which is still connected to the same database as the new API, it could result in a major data breach or data loss.
How can this be mitigated?
API Gateways can easily thwart this type of vulnerability by allowing to manage the life-cycle of APIs efficiently. For example, an API Gateway can be configured to automatically deprecate the older version of an API once a new one becomes available. In this case, since version 1 of the API is replaced by version 2, version 1 will be deprecated. This will allow existing legacy applications using API version 1 to continue using that version but will not allow any new applications to subscribe and use it (shown in Figure 6).
When there is no requirement to allow access to an API, even existing legacy applications that use that API, an API Gateway will allow retiring the old API version, which will completely remove it from the API Gateway, thereby making sure that no applications will be able to access it anymore (shown in Figure 7).
10 — Insufficient Logging and Monitoring
The best-case scenario for an attacker is if attacks on an application can go unnoticed as this would give the confidence to carry out consecutive attacks on the same application which could provide enough time for the attacker to fully compromise the system. This would be possible if an application has insufficient logging and monitoring of suspicious activities and fails to alert the necessary parties on time.
An example of the exploitation of this type of vulnerability could include an application that has been attacked using a large-scale credential stuffing attack and millions of user credentials have leaked. Since there was little logging in the application, the administrators did not receive alerts of any suspicious activity, nor were they able to track down exactly what records have been a victim to the attack.
Another example would be a scenario where an access token with administrative privileges has been stolen and has been used to perform potentially harmful activities by an attacker (see Figure 8).
The owner of the access token, who finds out that the client has been breached suspects that access token might have been stolen and alerts the system administrator who immediately revokes the compromised token and issues the owner a new one.
However, it is now necessary to identify what activities have been carried out during the time the breach was not reported since the extent of the damage done to the system must be approximated. This would not be possible in this scenario since there has not been proper logging and monitoring mechanisms in place.
How can this be mitigated?
When API traffic is exposed via an API Gateway, API requests and response meta-data can be logged centrally and can be investigated to review any suspicious activity from the stolen access token which reveals the extent of damage and data altered by the attacker (shown in Figure 9).
Real-time monitoring is also possible when exposing API traffic using an API Gateway. For example, in this case, Kate lives in the UK and the API Gateway is able to identify that primarily traffic from Kate usually comes from the UK based on the IP address of the device that is being used to run the application. Thereby allowing the API Gateway to recognize any anomalies by monitoring the changes in access patterns.
Assuming an attacker residing in Russia was able to steal the access token used by Kate and invokes the API, the API Gateway will instantly identify the change in the access pattern and flags the API request coming from Russia as suspicious activity, block that request and inform an administrator to take the appropriate action (to continue blocking calls from that IP address or to allow it if the IP address is validated to be from a legitimate user).
The best API Gateway solutions also offer Bot Detection functionality and detailed logging and monitoring mechanisms, which further enhances protection against this type of vulnerability. Thereby emphasizing the importance of the role played by API Gateway solutions to overcome many modern day vulnerabilities and pro-actively protect your applications from them.
Conclusion
This article covered the OWASP Top 10 Threats, showed the magnitude of impact that each of those threats can have on modern API-based applications and how these threats can easily be mitigated with existing technology, specifically taking WSO2 API Manager as an example, in order to enforce better security measures for vulnerable APIs.
If you enjoyed this article series feel free to leave some claps, explore more articles from fellow writers in API Integration Essentials publication, follow me here on Medium and provide any suggestions in the comments down below on what content you would like to be covered in the future.
