Mitigation of OWASP API Security Risk: Broken Authentication using F5 XC Platform
Introduction to Broken Authentication: Authentication in APIs adds friction, so during the initial development phase and for the sake of simplicity developers try to not implement authentication and authorization processes. As the application keeps growing, they will add these recommendations to existing code and during this transition they may have left some of the old internal APIs without authentication. Hackers will try to find these kinds of poorly authenticated flaws to bypass the login validation and gain access to their application data. According to Okta, most of the data breaches in 2020 fall under this category and so this is one of the most preferred approaches to attackers. Authentication is said to be broken if hackers are able to compromise passwords, keys, session tokens and user account information. As per OWASP, APIs may fall under this category if API doesn’t have authentication validation API permits credential stuffing API permits attackers to perform a brute force attack without presenting captcha/account lockout mechanism Permits weak passwords Sends sensitive authentication details, such as auth tokens and passwords in the URL Strong password policy not implemented Below are some of the preventive measures which are to be followed to protect application from these kinds of exploits: Authentication support for all API’s Authorization design developed in a good and structured way using access controls Session tokens need to be expired in shorter time Rate limiting and account locking after specific invalid logins Rotation of keys and certs Internal APIs should be audited and not exposed to outside Multi factor authentication support for critical APIs Enforcing strong password policy with special chars, capitals, numbers and minimum of 8 characters length In short, if the application doesn’t have authentication mechanism, supports weak passwords or even if we are unable to identify the authentication details of our requests, our application can be prone to broken authentication. And to prevent this risk we need different kinds of solutions to identify authentication details, enforce authentication policies, prevent credential stuffing & bot attacks, continuous monitoring of API’s, etc. So, let’s delve into F5 Distributed Cloud Platform (XC) and check how it can detect and protect applications against these vulnerabilities. Authentication Vulnerabilities Detection: Login to Distributed Cloud console and navigate to your load balancer configuration Enable API Discovery feature on this load balancer Once we have enabled this feature, Web Application and API Protection (WAAP) inbuilt AI/ML engine will start tracking all incoming traffic and after some time we will be able to see API endpoint details as below Change to table view and observe different types ofauthentication details along with some of the vulnerabilities discovered by WAAP as below a. API type and authentication state b. Auth type like JWT and insights on user role c. Security assessment for API endpoint vulnerabilities, threat level and risk score d. Sensitive data leakage like IP, credentials, etc Mitigation Steps: AppSec/SecOps can navigate to the Security & API endpoint dashboards and analyze these requests data & authentication insights. If they are not familiar with any kind of requests, they can explore the solutions below and as per their requirements they can configure them to prevent these vulnerabilities. Configure rate limiting to keep a limit on number of requests - check here for more details on rate limiting Configure API Protection rules on load balancer to restrict access to applications – check here for more details on API rules Configure Bot Defense to prevent credential stuffing and bot attacks – check here for more details on bot protection Configure OpenAPI schema validation to detect/block invalid and abnormal requests – for more details check this article Malicious user detection – check this existing article for more details ConfigureMutual Transport Layer Security (mTLS) authentication using client certificates - check here for more information Conclusion: Wrapping up, this article covered an overview of broken authentication risk and then we also shed light on how WAAP can extract valuable authentication vulnerabilities. Lastly, we also discussed some of the XC mitigation steps to prevent this API Security risk. For more information or to get started check links below: OWASP API Security Top 10 2019 OWASP API Security Top 10 2023 F5 Distributed Cloud WAAPMitigating OWASP API Security Risk: Security Misconfiguration using F5 XC Platform
Overview: This article is a continuation of the series of articles on OWASP API Security vulnerabilities and demonstrates a scenario for mitigating API Security Misconfiguration using F5 Distributed Cloud Platform. Introduction to OWASP API Security Misconfiguration: APIs are the backbone of the modern application development model and because of their heavy usage they often become victim of attacks. Sometimes these vulnerabilities arise if security best practices are missed and are not followed properly in application development life cycle. Below are a few scenarios which fall under API Security Misconfiguration category: Latest security patches are not applied. Unnecessary HTTP verbs are enabled exposing APIs to get accessed by them. Improper implementation of CORS policy. Missing repeatable security hardening process. Exposing detailed stack trace error messages or sensitive information. Problem Statement: There are many ways an attacker can take advantage of security misconfigurations by utilizing readily available automation tools. In the demonstration below we will cover a scenario where the application is vulnerable for exposing stack trace information and will see how F5 Distributed Cloud WAAP can help in identifying and mitigating such threats. What is Stack Trace? Stack Trace is a system defined error message which occurs when program under execution gets abnormally terminated. This information is normally used for debugging purposes. Application throwing stack trace information gives the attacker a picture of active subroutines at that point during its execution and may help him to find flaws in the system which eventually may lead to some harmful implications. For the demonstration, we have already deployed a Load Balancer (LB) in the Distributed Cloud Console and attached the origin server to the LB. For configuration steps please follow the documentation As you can see from the above screenshot, a specific API Endpoint in our application is throwing Internal server error message along with stack trace information. F5 Distributed Cloud WAF engine can help in detecting such threats. For that you need to create a WAF policy with default configuration, enable WAF and attach theWAF policy to the LB. Configuration steps are covered in the documentation In the above screenshot you can see that Distributed Cloud WAF engine has successfully identified security misconfiguration in the API Endpoint. Prevention: From the suite of security solutions offered by F5 Distributed Cloud WAAP, here we have chosen to create an ‘API Protection Rule’ to restrict the access of API Endpoint throwing stack trace information. Step1: Select Load Balancer service tile from Distributed Cloud console homepage. Step2: On the right side of your LB click on three dots (ellipsis) and select ‘Manage Configuration’ as an action, click on ‘Edit Configuration’. Step3: Scroll down, in ‘API Protection’, click ‘Configure’ API Protection Rules. Step4: In ‘API Endpoints’, click ‘Add item’, Enter a name and configure a rule to deny access to the API Endpoint ‘/test’, Click ‘Apply’ then ‘Save and Exit’. Step5: Re-visit the same API Endpoint, throwing stack trace information. In the above screenshot you can see access to the vulnerable API Endpoint is restricted successfully. Conclusion: As demonstrated, the F5 Distributed Cloud WAF engine can successfully detect security misconfiguration event and optionally applying API Protection Rule on top of it can add a layer of security, safeguarding application against potential threats. For further information click the links below: OWASP API Security Project OWASP API7:2019 Security Misconfiguration F5 Distributed Cloud Services F5 Distributed Cloud WAAP F5 Distributed Cloud WAF Overview of OWASP API Security Top 10 2019Mitigating OWASP Web Application Risk: Insecure Design using F5 XC platform
Overview: This article is the last part in a seriesof articleson mitigation of OWASP Web Applicationvulnerabilities using F5 Distributed Cloud platform (F5 XC). Introduction to Insecure Design: In an effort to speed up the development cycle, some phases might be reduced in scope which leads to give chance for many vulnerabilities. To focus the risks which are been ignored from design to deployment phases, a new category of “Insecure Design” is added under OWASP Web Application Top 10 2021 list. Insecure Design represents the weaknesses i.e. lack of security controls which are been integrated to the website/application throughout the development cycle. If we do not have any security controls to defend the specific attacks, Insecure Design cannot be fixed by any perfect implementation while at the same time a secure design can still have an implementation flaw which leads to vulnerabilities that may be exploited. Hence the attackers will get vast scope to leverage the vulnerabilities created by the insecure design principles. Here are the multiple scenarios which comes under insecure design vulnerabilities. Credential Leak Authentication Bypass Injection vulnerabilities Scalper bots etc. In this article we will see how F5 XC platform helps to mitigate the scalper bot scenario. What is Scalper Bot: In the e-commerce industry, Scalping is a process which always leads to denial of inventory. Especially, online scalping uses bots nothing but the automated scripts which will check the product availability periodically (in seconds), add the items to the cart and checkout the products in bulk. Hence the genuine users will not get a fair chance to grab the deals or discounts given by the website or company. Alternatively, attackers use these scalper bots to abandon the items added to the cart later, causing losses to the business as well. Demonstration: In this demonstration, we are using an open-source application “Evershop” which will provide end to end online shopping cart facility. It will also provide an Admin page which helps to add/delete the item from the website whereas from the customer site users can login and checkout the items based on the availability. Admin Page: Customer Page: Scalper bot with automation script: The above selenium script will login to the e-commerce application as a customer, checks the product availability and checkout the items by adding the items into the cart. To mitigate this problem, F5 XC is providing the feasibility of identifying and blocking these bots based on the configuration provided under HTTP load balancer. Here is the procedure to configure the bot defense with mitigation action ‘block’ in the load balancer and associate the backend application nothing but ‘evershop’ as the origin pool. Create origin pool Refer pool-creation for more info Create http load balancer (LB) and associate the above origin pool to it. Refer LB-creation for more info Configure bot defense on the load balancer and add the policy with mitigation action as ‘block’. Click on “Save and Exit” to save the Load Balancer configuration. Run the automation script by providing the LB domain details to exploit the items in the application. Validating the product availability for the genuine user manually. Monitor the logs through F5 XC, Navigate to WAAP --> Apps & APIs --> Security Dashboard, select your LB and click on ‘Security Event’ tab. The above screenshot gives the detailed info on the blocked attack along with the mitigation action. Conclusion: As you have seen from the demonstration, F5 Distributed Cloud WAAP (Web Application and API Protection) has detected the scalpers with the bot defense configuration applied on the Load balancer and mitigated the exploits of scalper bots. It also provides the mitigation action of “_allow_”, “_redirect_” along with “_block_”. Please refer link for more info. Reference links: OWASP Top 10 - 2021 Overview of OWASP Web Application Top 10 2021 F5 Distributed Cloud Services F5 Distributed Cloud Platform Authentication Bypass Injection vulnerabilitiesBasic OAuth concept and OAuth with F5 solutions
In my previous article [Overview of API Access Control and implementing API key access control with BIG-IP APM] , I explained the ‘API-Key based Access Control’ method and we could see how a user implements it easily and securely using BIG-IP APM. However, although the ‘API-Key’ method has its advantages, it also has some limitations when we use it in the enterprise-grade API access control implementation. Problems of the API-Key Access Control API Key compromise Although some improved API-Key systems can set an expiration time for API keys, the expiration time for keys has to be set for a longer time such as weeks, months, or a year. This is because the issued key should be configured manually to API clients or API G/W or API endpoints. This manual process requires extra operational overhead, thus it is normally recommended to use a long expiration time for keys. However, a longer expiration time may bring security problems as well. Let’s say the issued key is stolen without recognition by the organization, then what happens? Since the key’s expiration time might be set to months or a year, the attacker who stole the key can access the corporate resources until the key reaches its expiration time, a year in the worst case. 3rd party integration Since the API-key method doesn’t have any pre-defined flow or format of the key, it could be challenging to integrate the enterprise’s API system with 3rd party client applications. For example, if Google, AWS, Dropbox, and Open banking services were to provide all different API access control methods, application developers would need to create all different modules for their applications to integrate each service. This is not a scalable solution to integrating the organization’s APIs with other 3rd party applications. OAuth 2.0 An OAuth 2.0 standard protocol was introduced in 2012 to solve these challenges and was defined in RFC6549. It was designed to implement API access control and is one of the most widely adopted methods for API access control purposes. The common misunderstanding of an OAuth is that it is considered an ‘Authentication protocol’. But it’s not an authentication protocol. While OAuth can provide authentication capability with its well-known extension – ‘OIDC(OpenID Connect)’, OAuth itself can work without OIDC and it primarily solves the access delegation problem. If a user wants to delegate third-party application access to their Gmail profile, OAuth can solve this. Many experts explain an OAuth with an example of a hotel key card. Once the key card is issued to the user, the room doesn’t authenticate the user but rather the valid key card. An OAuth works like a hotel key card, thus it is not an authentication protocol. In an OAuth implementation, a token performs the same role as a ‘key’ of the ‘API-Key method’. One of the biggest technical advantages of OAuth is to provide centralized token management, user authentication, and a privilege consent process. This centralized policy management can help an enterprise to expand their API network and organizations more easily integrate their APIs with external applications. An OAuth is a big topic and we can not cover all the details of it in this short article. However, there are some important terminologies and concepts to understand the overall OAuth flow. OAuth roles OAuth standard introduces 4 different roles in a typical OAuth flow. Resource Owner(RO): RO indicates the person who owns the resources. If a fintech app tries to access a user’s banking account, the user is the resource owner(RO). Resource Server(RS): RS is the place to host protected resources. In the above banking example, the server which hosts the banking API is the resource server and the banking API itself is the resource. OAuth Authorization Server: OAuth AS is the centralized system to manage and issue the access token to OAuth clients. OAuth Client Application: The OAuth client indicates the application which wants to access a resource on behalf of the resource owner. In the banking example, the fintech app is the OAuth client. OAuth grant types OAuth grant types define how an OAuth client can obtain a grant from a resource owner to access their resources on their behalf. An OAuth 2.0 defines 4 different grant types. 1) Authorization Code Grant The application(=client) obtains the ‘authorization code’ first from the authorization server and the client exchange the code for an access token. This allows the access token to be never exposed to the resource owner’s user-agent. 2) Implicit Grant Optimized for in-browser JS clients. Instead of an authorization code, an access token is issued immediately without client authentication. 3) Resource Owner Password Credential Grant Username and password are used instead of an authorization code to obtain an access token. Should only be used for highly trusted clients or when other types are not available. Username and password are only used to get an access token and are not stored. 4) Client Credential Grant The client supplies its own credentials to get an access token. Support OAuth in F5 solutions Since OAuth is a key protocol for the enterprise-grade API implementation, F5 solutions support OAuth widely as well. F5 BIG-IP APM and NGINX Plus support various OAuth roles and grant types. Organizations can build their own secure OAuth framework using F5 solutions. Integrating with partner solutions Since OAuth is a standard protocol, one of its strong benefits is to be supported by different vendor solutions. While F5 provides all types of OAuth roles in our product portfolio, we also provide tight integrations with our partner’s platforms, this includes leading vendors of IDaaS solutions – Microsoft Azure AD, Okta, and Ping. F5 BIG-IP APM has built-in OAuth configuration sets for these vendors already, so customers easily can configure their BIG-IP APM device to work with these vendor’s solutions. That means a customer can deploy Microsoft Azure AD or Okta or Ping Identity as their OAuth Authorization Server, and they can configure the BIG-IP APM and NGINX Plus API Gateway as their OAuth Resource Server. Both BIG-IP APM and NGINX Plus can work with those IDaaS vendor’s solutions to build an enterprise-level of OAuth for an organization. Summary An OAuth is an essential component to implement API access control to protect the enterprise’s API endpoints. However, the OAuth standard includes different roles, grant types, and extensions. Because of its complexity, some organizations may have some difficulty adopting the technology. F5 solution can help an organization adopt OAuth more easily. For example, F5 supports different roles of OAuth with multiple solutions – BIG-IP APM and NGINX Plus API Gateway. A customer can build their own OAuth network using F5 solutions only or they also can configure our solutions to work with industry-leading IDaaS vendors such as Microsoft, Okta, and Ping Identity. With all the flexibility and powerful policy management capabilities of the F5 solution, an organization can implement and operate its OAuth systems more effectively.
