\n

This 2019 API Security article provides a valuable summary of the OWASP API Security Top 10 risks identified for that year, outlining key vulnerabilities.

\n

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. 

\n\n

API2:2019 - Broken User Authentication

\n

Problem Statement:

\n

A critical API security risk, Broken Authentication occurs when weaknesses in the API's identity verification process permit attackers to circumvent authentication mechanisms. Successful exploitation leads attackers to impersonate legitimate users, gain unauthorized access to sensitive data, perform actions on behalf of victims, and potentially take over accounts or systems. 

\n

This demonstration utilizes the Damn Vulnerable Web Application (DVWA) to illustrate the exploitability of Broken Authentication. We will execute a brute-force attack against the login interface, iterating through potential credential pairs to achieve unauthorized authentication.

\nFig: DVWA homepage\n

Below is the selenium automated script to execute brute-force attack, submitting multiple credential combinations to attempt authentication.

\nFig: Selenium script to execute brute force attack\n

The brute-force attack successfully compromised the authentication controls by iterating through multiple credential pairs, ultimately granting access.

\nFig: Brute Force attack executed successfully\n

Solution:

\n

To mitigate the above vulnerability, NGINX App Protect is deployed and configured as reverse proxy in front of the application and requests are first validated by NAP for the vulnerabilities. The NGINX App Protect Brute Force WAF policy is utilized as shown below.

\nFig: NGINX App Protect Brute Force WAF Policy\n

Re-attempt to gain access to the application using the brute force approach is rejected and blocked.

\nFig: Brute Force attack is blocked\n

Support ID verification in the Security logs shows request is blocked because of Brute Force Policy.

\nFig – Request captured in NGINX App Protect security log\n

API3:2019 - Excessive Data Exposure

\n

Problem Statement:

\n

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.

\nFig: Highly Sensitive Data Exposure\n

Solution:

\n

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.

\nFig: NGINX App Protect dataguard_blocking WAF Policy\n

Next, if we resend the same request, we can see that the CCN/SSN numbers are masked, thereby preventing data breaches.

\nFig: Sensitive Data is masked successfully\n

If needed, we can update configurations to block this vulnerability after which all incoming requests for this endpoint will be blocked.

\nFig: The request is blocked when block mode in blocking_settings is \"true\"\n

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.

\nFig – Request captured in NGINX App Protect security log\n

API4:2019 - Lack of Resources & Rate Limiting 

\n

Problem Statement:

\n

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.

\n

Solution:

\n

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.

\n

\n

API6:2019 - Mass Assignment

\n

Problem Statement:

\n

API Mass Assignment vulnerability arises when clients can modify immutable internal object properties via crafted requests, bypassing API Endpoint restrictions. Attackers exploit this by sending malicious HTTP requests to escalate privileges, bypass security mechanisms, or manipulate the API Endpoint's functionality. 

\n

Placing an order with quantity as 1:

\nFig: Order placed with product count as 1\n

Bypassing API Endpoint restrictions and placing the order with quantity as -1 is also successful.

\nFig: Order placed with product count as -1\n

Solution:

\n

To overcome this vulnerability, we will use the WAF API Security Policy in NGINX App Protect which validates all the API Security event triggered and based on the enforcement mode set in the validation rules, the request will either get reported or blocked, as shown below.

\n

Restricted/updated swagger file with .json extension is added as below:

\nFig: api.json file is updated with minimum Product Quantity\n

Policy used: App Protect API Security

\nFig: NGINX App Protect WAF API Security Policy\n

Re-attempting to place the order with quantity as -1 is getting blocked.

\nFig: Attempt to place order with product count as -1\n

Validating the support ID in Security log as below:

\nFig – Request captured in NGINX App Protect security log\n

API7:2019 - Security Misconfiguration

\n

Problem Statement:

\n

Security misconfiguration occurs when security best practices are neglected, leading to vulnerabilities like exposed debug logs, outdated security patches, improper CORS settings, unnecessary allowed HTTP methods, etc. To prevent this, systems must stay up to date with security patches, employ continuous hardening, ensure API communications use secure channels (TLS), etc. 

\n

Example:

\n

Unnecessary HTTP methods/verbs represent a significant security misconfiguration under the OWASP API Top 10. APIs often expose a range of HTTP methods (such as PUT, DELETE, PATCH) that are not required for the application's functionality. These unused methods, if not properly disabled, can provide attackers with additional attack surfaces, increasing the risk of unauthorized access or unintended actions on the server. Properly limiting and configuring allowed HTTP methods is essential for reducing the potential impact of such security vulnerabilities. Let’s dive into a demo application which has exposed “PUT” method., this method is not required as per the design and attackers can make use of this insecure unintended method to modify the original content.

\nFig - GET call being made to fetch the original contentFig - Original content is modified using PUT method\n

Solution:

\n

NGINX App Protect makes it easy to block unnecessary or risky HTTP methods by letting you customize which methods are allowed. By easily configuring a policy to block unauthorized methods, like disabling the PUT method by setting \"$action\": \"delete\", you can reduce potential security risks and strengthen your API protection with minimal effort. 

\nFig – PUT method disallowed in NGINX App Protect policy fileFig – PUT method blocked by NGINX App ProtectFig – GET method is still allowed and fetching the earlier updated content\n

As shown below the attack request is captured in security log which conveys the request was successfully blocked, because of “Illegal method” violation. 

\nFig – Request captured in NGINX App Protect security log

\n

API9:2019 - Improper Assets Management

\n

Problem Statement:

\n

Improper Asset Management in API security signifies the crucial risk stemming from an incomplete awareness and tracking of an organization's full API landscape, including all environments like development and staging, different versions, both internal and external endpoints, and undocumented or \"shadow\" APIs. This lack of comprehensive inventory leads to an expanded and often unprotected attack surface, as security measures cannot be consistently applied to unknown or unmanaged assets. Consequently, attackers can exploit these overlooked endpoints, potentially find older, less secure versions or access sensitive data inadvertently exposed in non-production environments, thereby undermining overall security posture because you simply cannot protect assets you don't know exist. 

\n

We’re using a flask database application with multiple API endpoints for demonstration.

\n

As part of managing API assets, the “/v1/admin/users” endpoint in the demo Flask application has been identified as obsolete. The continued exposure of the deprecated “/v1/admin/users” endpoint constitutes an Improper Asset Management vulnerability, creating an unnecessary security exposure that could be leveraged for exploitation. 

\nFig: <public_ip>/v1/admin/users\n

The current endpoint for user listing is “/v2/users”.

\nFig: <public_ip>/v2/users with user as admin1\n

Solution:

\n

To mitigate the above vulnerability, we are using NGINX as an API Gateway. The API Gateway acts as a filtering gateway for API incoming traffic, controlling, securing, and routing requests before they reach the backend services. The server’s name used for the above case is “f1-api” which is listening to the public IP where our application is running.   

\n\n

To query the “/v1/admin/users” endpoint, use the curl command as shown below. 

\nFig: https://f1-api/v1/admin/users\n

Below is the configuration for NGINX as API Gateway, in “api_gateway.conf”, where “/v1/admin/users” endpoint is deprecated.

\nFig: api_gateway.conf\n

The “api_json_errors.conf” is configured with error responses as shown below and included in the above “api_gateway.conf”.

\nFig: api_json_errors.conf\n

 Executing the curl command against the endpoint yields an “HTTP 301 Moved Permanently” response.

\nFig: https://f1-api/v1/admin/users is deprecated\n

API10:2019 - Insufficient Logging & Monitoring

\n

Problem Statement:

\n

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.

\n

Solution:

\n

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:

\n

\n
• https://www.nginx.com/blog/logging-upstream-nginx-traffic-cdn77/
\n
• https://www.nginx.com/blog/modsecurity-logging-and-debugging/
\n
• https://www.nginx.com/blog/using-nginx-logging-for-application-performance-monitoring/
\n
• https://docs.nginx.com/nginx/admin-guide/monitoring/logging/
\n
• https://docs.nginx.com/nginx-app-protect-waf/logging-overview/logs-overview/ 
\n

\n

Conclusion: 

\n

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.

\n

Related resources for more information or to get started:

\n

\n
• F5 NGINX App Protect
\n
• OWASP API Security Top 10 2019
\n
• OWASP API Security Top 10 2023 
\n

\n

\n

This 2019 API Security article provides a valuable summary of the OWASP API Security Top 10 risks identified for that year, outlining key vulnerabilities.

\n

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. 

\n\n

The below OWASP risks are successfully tested on both NGINX App Protect Version 4 and Version 5. The set up and configurations for both the Versions are different.

\n

To bring up the setup for NGINX Version 5, follow the below links: 

\n

https://docs.nginx.com/nginx-app-protect-waf/v5/admin-guide/install/

\n

https://docs.nginx.com/nginx-app-protect-waf/v5/admin-guide/compiler/

\n\n

API2:2019 - Broken User Authentication

\n

Problem Statement:

\n

A critical API security risk, Broken Authentication occurs when weaknesses in the API's identity verification process permit attackers to circumvent authentication mechanisms. Successful exploitation leads attackers to impersonate legitimate users, gain unauthorized access to sensitive data, perform actions on behalf of victims, and potentially take over accounts or systems. 

\n

This demonstration utilizes the Damn Vulnerable Web Application (DVWA) to illustrate the exploitability of Broken Authentication. We will execute a brute-force attack against the login interface, iterating through potential credential pairs to achieve unauthorized authentication.

\nFig: DVWA homepage\n

Below is the selenium automated script to execute brute-force attack, submitting multiple credential combinations to attempt authentication.

\nFig: Selenium script to execute brute force attack\n

The brute-force attack successfully compromised the authentication controls by iterating through multiple credential pairs, ultimately granting access.

\nFig: Brute Force attack executed successfully\n

Solution:

\n

To mitigate the above vulnerability, NGINX App Protect is deployed and configured as reverse proxy in front of the application and requests are first validated by NAP for the vulnerabilities. The NGINX App Protect Brute Force WAF policy is utilized as shown below.

\nFig: NGINX App Protect Brute Force WAF Policy\n

Re-attempt to gain access to the application using the brute force approach is rejected and blocked.

\nFig: Brute Force attack is blocked\n

Support ID verification in the Security logs shows request is blocked because of Brute Force Policy.

\nFig – Request captured in NGINX App Protect security log\n

API3:2019 - Excessive Data Exposure

\n

Problem Statement:

\n

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.

\nFig: Highly Sensitive Data Exposure\n

Solution:

\n

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.

\nFig: NGINX App Protect dataguard_blocking WAF Policy\n

Next, if we resend the same request, we can see that the CCN/SSN numbers are masked, thereby preventing data breaches.

\nFig: Sensitive Data is masked successfully\n

If needed, we can update configurations to block this vulnerability after which all incoming requests for this endpoint will be blocked.

\nFig: The request is blocked when block mode in blocking_settings is \"true\"\n

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.

\nFig – Request captured in NGINX App Protect security log\n

API4:2019 - Lack of Resources & Rate Limiting 

\n

Problem Statement:

\n

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.

\n

Solution:

\n

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.

\n

\n

API6:2019 - Mass Assignment

\n

Problem Statement:

\n

API Mass Assignment vulnerability arises when clients can modify immutable internal object properties via crafted requests, bypassing API Endpoint restrictions. Attackers exploit this by sending malicious HTTP requests to escalate privileges, bypass security mechanisms, or manipulate the API Endpoint's functionality. 

\n

Placing an order with quantity as 1:

\nFig: Order placed with product count as 1\n

Bypassing API Endpoint restrictions and placing the order with quantity as -1 is also successful.

\nFig: Order placed with product count as -1\n

Solution:

\n

To overcome this vulnerability, we will use the WAF API Security Policy in NGINX App Protect which validates all the API Security event triggered and based on the enforcement mode set in the validation rules, the request will either get reported or blocked, as shown below.

\n

Restricted/updated swagger file with .json extension is added as below:

\nFig: api.json file is updated with minimum Product Quantity\n

Policy used: App Protect API Security

\nFig: NGINX App Protect WAF API Security Policy\n

Re-attempting to place the order with quantity as -1 is getting blocked.

\nFig: Attempt to place order with product count as -1\n

Validating the support ID in Security log as below:

\nFig – Request captured in NGINX App Protect security log\n

API7:2019 - Security Misconfiguration

\n

Problem Statement:

\n

Security misconfiguration occurs when security best practices are neglected, leading to vulnerabilities like exposed debug logs, outdated security patches, improper CORS settings, unnecessary allowed HTTP methods, etc. To prevent this, systems must stay up to date with security patches, employ continuous hardening, ensure API communications use secure channels (TLS), etc. 

\n

Example:

\n

Unnecessary HTTP methods/verbs represent a significant security misconfiguration under the OWASP API Top 10. APIs often expose a range of HTTP methods (such as PUT, DELETE, PATCH) that are not required for the application's functionality. These unused methods, if not properly disabled, can provide attackers with additional attack surfaces, increasing the risk of unauthorized access or unintended actions on the server. Properly limiting and configuring allowed HTTP methods is essential for reducing the potential impact of such security vulnerabilities. Let’s dive into a demo application which has exposed “PUT” method., this method is not required as per the design and attackers can make use of this insecure unintended method to modify the original content.

\nFig - GET call being made to fetch the original contentFig - Original content is modified using PUT method\n

Solution:

\n

NGINX App Protect makes it easy to block unnecessary or risky HTTP methods by letting you customize which methods are allowed. By easily configuring a policy to block unauthorized methods, like disabling the PUT method by setting \"$action\": \"delete\", you can reduce potential security risks and strengthen your API protection with minimal effort. 

\nFig – PUT method disallowed in NGINX App Protect policy fileFig – PUT method blocked by NGINX App ProtectFig – GET method is still allowed and fetching the earlier updated content\n

As shown below the attack request is captured in security log which conveys the request was successfully blocked, because of “Illegal method” violation. 

\nFig – Request captured in NGINX App Protect security log

\n

API9:2019 - Improper Assets Management

\n

Problem Statement:

\n

Improper Asset Management in API security signifies the crucial risk stemming from an incomplete awareness and tracking of an organization's full API landscape, including all environments like development and staging, different versions, both internal and external endpoints, and undocumented or \"shadow\" APIs. This lack of comprehensive inventory leads to an expanded and often unprotected attack surface, as security measures cannot be consistently applied to unknown or unmanaged assets. Consequently, attackers can exploit these overlooked endpoints, potentially find older, less secure versions or access sensitive data inadvertently exposed in non-production environments, thereby undermining overall security posture because you simply cannot protect assets you don't know exist. 

\n

We’re using a flask database application with multiple API endpoints for demonstration.

\n

As part of managing API assets, the “/v1/admin/users” endpoint in the demo Flask application has been identified as obsolete. The continued exposure of the deprecated “/v1/admin/users” endpoint constitutes an Improper Asset Management vulnerability, creating an unnecessary security exposure that could be leveraged for exploitation. 

\nFig: <public_ip>/v1/admin/users\n

The current endpoint for user listing is “/v2/users”.

\nFig: <public_ip>/v2/users with user as admin1\n

Solution:

\n

To mitigate the above vulnerability, we are using NGINX as an API Gateway. The API Gateway acts as a filtering gateway for API incoming traffic, controlling, securing, and routing requests before they reach the backend services. The server’s name used for the above case is “f1-api” which is listening to the public IP where our application is running.   

\n\n

To query the “/v1/admin/users” endpoint, use the curl command as shown below. 

\nFig: https://f1-api/v1/admin/users\n

Below is the configuration for NGINX as API Gateway, in “api_gateway.conf”, where “/v1/admin/users” endpoint is deprecated.

\nFig: api_gateway.conf\n

The “api_json_errors.conf” is configured with error responses as shown below and included in the above “api_gateway.conf”.

\nFig: api_json_errors.conf\n

 Executing the curl command against the endpoint yields an “HTTP 301 Moved Permanently” response.

\nFig: https://f1-api/v1/admin/users is deprecated\n

API10:2019 - Insufficient Logging & Monitoring

\n

Problem Statement:

\n

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.

\n

Solution:

\n

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:

\n

\n
• https://www.nginx.com/blog/logging-upstream-nginx-traffic-cdn77/
\n
• https://www.nginx.com/blog/modsecurity-logging-and-debugging/
\n
• https://www.nginx.com/blog/using-nginx-logging-for-application-performance-monitoring/
\n
• https://docs.nginx.com/nginx/admin-guide/monitoring/logging/
\n
• https://docs.nginx.com/nginx-app-protect-waf/logging-overview/logs-overview/ 
\n

\n

Conclusion: 

\n

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.

\n

Related resources for more information or to get started:

\n

\n
• F5 NGINX App Protect
\n
• OWASP API Security Top 10 2019
\n
• OWASP API Security Top 10 2023 
\n

\n