API Security (Part 2)

In my first article on API security, I explained about the APIs and about the security threats of APIs. In this article, I will explain how to mitigate the API vulnerabilities mentioned in that article.

1.Broken Object Level Authorization

Broken object-level authorization vulnerability occurs because of two reasons. First one is enumerable identifiers and the second one is lack of checking of access rights on the requests. If we provide solutions for these two issues, we can mitigate this vulnerability. Some solutions for these issues are,

• Implement authorization checks with user policies and hierarchy.
• Verifying whether the user has permissions to access the objects, every time access is attempted.
• Using random IDs instead of auto-increment IDs.
• Using an ID that is stored in the session object rather than using an ID sent by the user. 

2.Broken  Authentication

Broken authentication is a threat that can be prevented easily by implementing some changes. We can use multi-factor authentication or two-factor authentication for all logins to prevent brute force, credential stuffing, and stolen credential attacks. Increasing the complexity of user passwords is another good way to reduce this vulnerability. Few more steps that can be used to prevent broken authentication are,

• Rate-limiting the login attempts.
• Blacklisting IPs.
• Developing strong session management controls.

3.Excessive Data Exposure

Prevention of this vulnerability should start from the API design phase. Since we cannot rely on the client side to filter the data, it is important to review all the API use cases and the response payloads, to check whether a response carries other than the required information. We should carefully define schemas for all the API responses and error responses.

4.Lack of Resources & Rate Limiting

Defing throttle rates at the application level and API level can mitigate this vulnerability. This includes execution timeouts, maximum allowable memory, the number of records per page that can be returned to a user, or the number of processes permitted within a defined timeframe.

5.Broken Function Level Authorization

Broken functional level authorization issue is related to access control at functionality level and involve authentication authorization modules as protection mechanisms. To mitigate this vulnerability, it is required to create an appropriate authentication and authorization module that is invoked from all the business functions and it should deny all access by default, requiring explicit grants to specific roles for access to every function. Furthermore, we should only allow operations to users belonging to the appropriate group or role and review API endpoints against function level authorization flaws according to the groups hierarchy and business logic.

6.Mass Assigment

This vulnerability have several alternative names depending on the backend framework:

• Mass Assignment: Ruby on Rails, NodeJS.
• Autobinding: Spring MVC, ASP NET MVC.
• Object injection: PHP

And these backend frameworks and some programming languages provide specific solutions for this vulnerability. Whitelist the bindable, non-sensitive fields and Blacklist the non-bindable, sensitive fields are the solutions provided by most of them. This tutorial will give you some idea on how to deal with mass assignment issue with Ruby on Rails. In addition to the solutions provided by these technologies we can use Data Transfer Objects (DTOs) to avoid binding inputs directly to domain objects and handle this issue.

7.Security Misconfiguration

To prevent this vulnerability, efforts from multiple parties are required. For example, suppose that the developer implements a secure code, but it is still up to the integration team to properly integrate the application into production, and the responsibility of the system administrator to actively patch and update the system. The best way to prevent this is educating and the staff on current security trends. Some recommendations for security misconfiguration are:

• Keeping software up to date
• Encrypting data
• Enforcing strong access controlls
• Removing unnecessary features, libraries, functions from the web app
• Running automated scans and doing audits periodically

8.Injection

By using techniques like query parameterization, stored procedures and ORM tools can give some protection for the injections. By using them, it is ensured that the attacker cannot change the intent of a query, even if commands are inserted by the attacker. Whitelisting, validating and encoding inputs are some other processes we can use to mitigate injections. 

9.Improper Assets Management

we can do things like taking the inventory of all of our APIs and API hosts to ensure clear separation between production , development and other environments. Furthermore by, limiting the public access to the APIs, avoiding accessing of production data sources from non-production environments and using API firewalls can mitigate this vulnerability.

10.Insufficient Logging & Monitoring

Inorder to find a vulnerability of an application, an attacker should spend a lot of time with the application. If there is no sufficient logging and monitoring, attackers can easily exploits the vulnerabilities. Therefore, maintaining a detailed and secure logs of all access attempts is important to prevent this issue and improve the security of the application. Logs should be treated like sensitive information and they should include enough detail to identify the attacker. Finally we can integrate with SIEMs and other monitoring systems to continuously monitor logs and the APIs.

References

• https://www.enterprisenetworkingplanet.com/netsecur/article.php/3866756/10-Ways-to-Prevent-or-Mitigate-SQL-Injection-Attacks.htm
• https://github.com/OWASP/API-Security