Mitigating OWASP API Security Top 10 risks using F5 NGINX App Protect
This 2019 API Security article covers the summary of OWASP API Security Top 10 – 2019 categories and newly published 2023 API security article covered introductory part of newest edition of OWASP API Security Top 10 risks – 2023.
We will deep-dive into some of those common risks and how we can protect our applications against these vulnerabilities using F5 NGINX App Protect.
Excessive Data Exposure
Problem Statement:
As shown below in one of the demo application API’s, Personal Identifiable Information (PII) data, like Credit Card Numbers (CCN) and U.S. Social Security Numbers (SSN), are visible in responses that are highly sensitive. So, we must hide these details to prevent personal data exploits.
Solution:
To prevent this vulnerability, we will use the DataGuard feature in NGINX App Protect, which validates all response data for sensitive details and will either mask the data or block those requests, as per the configured settings. First, we will configure DataGuard to mask the PII data as shown below and will apply this configuration.
Next, if we resend the same request, we can see that the CCN/SSN numbers are masked, thereby preventing data breaches.
If needed, we can update configurations to block this vulnerability after which all incoming requests for this endpoint will be blocked.
If you open the security log and filter with this support ID, we can see that the request is either blocked or PII data is masked, as per the DataGuard configuration applied in the above section.
Injection
Problem Statement:
Customer login pages without secure coding practices may have flaws. Intruders could use those flaws to exploit credential validation using different types of injections, like SQLi, command injections, etc. In our demo application, we have found an exploit which allows us to bypass credential validation using SQL injection (by using username as “' OR true --” and any password), thereby getting administrative access, as below:
Solution:
NGINX App Protect has a database of signatures that match this type of SQLi attacks. By configuring the WAF policy in blocking mode, NGINX App Protect can identify and block this attack, as shown below.
If you check in the security log with this support ID, we can see that request is blocked because of SQL injection risk, as below.
Insufficient Logging & Monitoring
Problem Statement:
Appropriate logging and monitoring solutions play a pivotal role in identifying attacks and also in finding the root cause for any security issues. Without these solutions, applications are fully exposed to attackers and SecOps is completely blind to identifying details of users and resources being accessed.
Solution:
NGINX provides different options to track logging details of applications for end-to-end visibility of every request both from a security and performance perspective. Users can change configurations as per their requirements and can also configure different logging mechanisms with different levels. Check the links below for more details on logging:
- https://www.nginx.com/blog/logging-upstream-nginx-traffic-cdn77/
- https://www.nginx.com/blog/modsecurity-logging-and-debugging/
- https://www.nginx.com/blog/using-nginx-logging-for-application-performance-monitoring/
- https://docs.nginx.com/nginx/admin-guide/monitoring/logging/
- https://docs.nginx.com/nginx-app-protect-waf/logging-overview/logs-overview/
Unrestricted Access to Sensitive Business Flows
Problem Statement:
By using the power of automation tools, attackers can now break through tough levels of protection. The inefficiency of APIs to detect automated bot tools not only causes business loss, but it can also adversely impact the services for genuine users of an application.
Solution:
NGINX App Protect has the best-in-class bot detection technology and can detect and label automation tools in different categories, like trusted, untrusted, and unknown. Depending on the appropriate configurations applied in the policy, requests generated from these tools are either blocked or alerted. Below is an example that shows how requests generated from the Postman automation tool are getting blocked.
By filtering the security log with this support-id, we can see that the request is blocked because of an untrusted bot.
Lack of Resources & Rate Limiting
Problem Statement:
APIs do not have any restrictions on the size or number of resources that can be requested by the end user. Above mentioned scenarios sometimes lead to poor API server performance, Denial of Service (DoS), and brute force attacks.
Solution:
NGINX App Protect provides different ways to rate limit the requests as per user requirements. A simple rate limiting use case configuration is able to block requests after reaching the limit, which is demonstrated below.
Conclusion:
In short, this article covered some common API vulnerabilities and shows how NGINX App Protect can be used as a mitigation solution to prevent these OWASP API security risks.
Related resources for more information or to get started: