OWASP Automated Threats - Credential Stuffing (OAT-008)
Introduction: In this OWASP Automated Threat Article we'll be highlighting OAT-008 Credentials Stuffing with some basic threat information as well as a recorded demo to dive into the concepts deeper. In our demo we'll show how Credential Stuffing works with Automation Tools to validate lists of stolen credentials leading to manual Account Takeover and Fraud. We'll wrap it up by highlighting F5 Bot Defense to show how we solve this problem for our customers. Credential Stuffing Description: Lists of authentication credentials stolen from elsewhere are tested against the application’s authentication mechanisms to identify whether users have re-used the same login credentials. The stolen usernames (often email addresses) and password pairs could have been sourced directly from another application by the attacker, purchased in a criminal marketplace, or obtained from publicly available breach data dumps. Unlike OAT-007 Credential Cracking, Credential Stuffing does not involve any bruteforcing or guessing of values; instead credentials used in other applications are being tested for validity Likelihood & Severity Credential stuffing is one of the most common techniques used to take-over user accounts. Credential stuffing is dangerous to both consumers and enterprises because of the ripple effects of these breaches. Anatomy of Attack The attacker acquires usernames and passwords from a website breach, phishing attack, password dump site. The attacker uses automated tools to test the stolen credentials against many websites (for instance, social media sites, online marketplaces, or web apps). If the login is successful, the attacker knows they have a set of valid credentials. Now the attacker knows they have access to an account. Potential next steps include: Draining stolen accounts of stored value or making purchases. Accessing sensitive information such as credit card numbers, private messages, pictures, or documents. Using the account to send phishing messages or spam. Selling known-valid credentials to one or more of the compromised sites for other attackers to use. OWASP Automated Threat (OAT) Identity Number OAT-008 Threat Event Name Credential Stuffing Summary Defining Characteristics Mass log in attempts used to verify the validity of stolen username/password pairs. OAT-008 Attack Demographics: Sectors Targeted Parties Affected Data Commonly Misused Other Names and Examples Possible Symptoms Entertainment Many Users Authentication Credentials Account Checker Attack Sequential login attempts with different credentials from the same HTTP client (based on IP, User Agent, device, fingerprint, patterns in HTTP headers, etc.) Financial Application Owner Account Checking High number of failed login attempts Government Account Takeover Increased customer complaints of account hijacking through help center or social media outlets Retail Login Stuffing Social Networking Password List Attack Password re-use Use of Stolen Credentials Credential Stuffing Demo: In this demo we will be showing how attackers leverage automation tools with increasing sophistication to execute credential stuffing against the sign in page of a web application. We'll then have a look at the same attack with F5 Distributed Cloud Bot Defense protecting the application. In Conclusion: A common truism in the security industry says that there are two types of companies—those that have been breached, and those that just don’t know it yet. As of 2022, we should be updating that to something like “There are two types of companies—those that acknowledge the threat of credential stuffing and those that will be its victims.” Credential stuffing will be a threat so long as we require users to log in to accounts online. The most comprehensive way to prevent credential stuffing is to use an anti-automation platform. OWASP Links OWASP Automated Threats to Web Applications Home Page OWASP Automated Threats Identification Chart OWASP Automated Threats to Web Applications Handbook F5 Related Content Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) F5 Bot Defense Solutions F5 Labs "I Was a Human CATPCHA Solver" The OWASP Automated Threats Project OWASP Automated Threats - CAPTCHA Defeat (OAT-009) How Attacks Evolve From Bots to Fraud Part: 1 How Attacks Evolve From Bots to Fraud Part: 2 F5 Distributed Cloud Bot Defense F5 Labs 2021 Credential Stuffing Report
How Attacks Evolve from Bots to Fraud - Part 1
Bot Basics A bot is a software program that performs automated, repetitive, pre-defined tasks. Bots typically imitate or replace human user behavior because they operate much faster than human users. Good Bots make the Internet work - From search engine crawlers that bring the world to your fingertips to chatbots that engage and enhance the user experience. How Do Bots Facilitate Fraud? Bots can also be used to scale automated attacks which can result in account takeover (ATO) and fraud. Motivated cyber criminals leverage a sophisticated arsenal of bots, automation, and evasion techniques. They also perform ongoing reconnaissance to identify security countermeasures and constantly retool their attacks to evade detection. Automated Bot Attack Vector Examples... Credential Stuffing Automated Account Creation Content Scraping High Value Data Credit Application Fraud Gift Card Cracking Application DDoS Aggregator Threats Fake Account Creation Inventory Hoarding Bypass Auth reCAPTCHA The list goes on... Business Impact of Bad Bots Infrastructure Costs - Infrastructure needs to scale to deal with unwanted and/or undetected bot traffic Competitive Intelligence - Web scrapers collect important data to help competitors adjust their pricing strategies Wrong Business Decisions - Bot traffic distorts web site analytics which could lead to making wrong business decisions Sneaker Bots - Bots are buying limited editions of certain products before regular buyers and then sell on black market Account Take-over - Credential stuffing leveraging stolen accounts purchased on the Darkweb providing access Fraudulent Transactions - Fraudulent transactions with large financial consequences as a result of account take-over in the finance sector The Industrialized (organized) Attack Lifecycle Figure 1. It begins with unwanted automation and ends with account takeover and application fraud What are Credential Spills? Credential Spill - A cyber incident in which a combination of username and/or email and password pairs becomes compromised. Date of Announcement - The first time a credential spill becomes public knowledge. This announcement could occur in one of two ways: A breached organization alerts its users and/or the general public A security researcher or reporter discovers a credential spill and breaks the news Date of Discovery - When an organization first learned of its credential spill. Organizations are not always willing to share this information. Stolen Credentials - Criminal Usage by Stage Stage 1: Slow and Quiet Sophisticated threat actors operating in stealth mode - 150 to - 30 days before the public announcement Each credential used (on average) 20 times per day Figure 2. Slow and quiet stage. Attackers use credentials in stealth mode from 150 to 30 days before the public announcement Stage 2: Ramp Up Creds become available on Darknet around ~30 days before public announcement Use of creds ramp up to 70 times per day Figure 3. The ramp-up stage. Attackers ramp up use of compromised credentials 30 days before the public announcement. Stage 3: The Blitz Credentials become public knowledge Script Kiddies + N00bs The first week is absolute chaos - each account attacked > 130 times per day Figure 4. The blitz stage. Script kiddies and other amateurs race to use credentials after the public announcement. Stage 4: Drop-Off / New Equilibrium Creds *should* be worthless at this point... Consumer reuse and lack of change allows for attacker "repackaging" and long tail value Figure 5. The drop-off stage. Credentials no longer have premium value Network Traffic Automation The simplest level of user simulation contains tools that make no attempt to emulate human behavior or higher level browser activity. They simply craft HTTP requests along specified parameters and pass them along to the target. These are the simplest, cheapest, and fastest tools. Sentry MBA is perhaps the standard tool of this type. Figure 6. Sentry MBA, a standard user simulation tool Browser and Native App Automation Most of the websites that we interact with every day—online banking, ecommerce, and travel sites—consist of large web applications built on hundreds of thousands of lines of JavaScript. These webpages are not simple documents, so simulating convincing transactions at the network level is extremely complex. At this point, it makes more sense for an attacker to automate activity at the browser level. Until 2017, PhantomJS was the most popular automated browser in the market. When Google released Chrome 59 that year, however, it pushed forward the state of browser automation by exposing a programmatically controllable “headless” mode (that is, absent a graphical user interface) for the world's most popular browser, Chrome. This gave attackers the ability to quickly debug and troubleshoot their programs using the normal Chrome interface while scaling their attacks. Furthermore, just weeks after this announcement, Google developers released Puppeteer, a cross-platform Node.js library that offers intuitive APIs to drive Chrome-like and Firefox browsers. Puppeteer has since become the go-to solution for browser automation, as you can see from its growing popularity in web searches. Figure 7. Google trends graph showing interest in PhantomJS versus Puppeteer between 2010 and 2016. (Source: Google Trends) Simulating Human Behavior The next level of sophistication above simulating a browser is simulating human behavior. It's easy to detect rapid, abrupt mouse movements and repeated clicks at the same page coordinates (such as a Submit button), but it is much harder to detect behavior that includes natural motion and bounded randomness. While Puppeteer and the Chrome DevTools Protocol can generate trusted browser events, such as clicks or mouse movements, they have no embedded functionality to simulate human behavior. Even if perfect human behavior was as simple as including a plug-in, Puppeteer is still a developer-oriented tool that requires coding skill. Enter Browser Automation Studio, or BAS. BAS is a free, Windows-only automation environment that allows users to drag and drop their way to a fully automated browser, no coding needed. Figure 8. Browser Automation Studio User Interface Scaling Up Real Human Behavior As attackers grow in capability, they succeed in creating automated attacks that look more like human behavior. In some contexts, it actually makes more sense to just use actual humans. "Microwork" is a booming industry in which anyone can farm out small tasks in return for pennies. These services describe their jobs as ideal for labeling data destined for machine learning systems and, in theory, that would be a perfect use. In reality, the tasks the human workers perform are helping bypass antibot defenses on social networks, retailers, and any site with a login or sign-up form. Figure 9. Data labeling “microwork” using humans to help bypass antibot defenses In Conclusion Depending on the attacker sophistication level and motivation there are a variety of tools ranging from basic automation to leveraging real humans to attempt to bypass bot defenses and perform account takeover actions. No matter the skill level, most attackers (at least, most cybercriminals) will start off with the cheapest, that is, least sophisticated, attacks in order to maximize rate of return. Able attackers will only increase sophistication (and thereby cost) if their target has implemented countermeasures that detect their original attack, and if the rewards still outweigh that increased cost. Related Content: Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) How Attacks Evolve From Bots to Fraud - Part 2 F5 Labs 2021 Credential Stuffing ReportBots, Fraud, and the OWASP Automated Threats Project (Overview)
Introduction Many of us have heard of OWASP in the context of the OWASP Top 10. In this article series we will take a look at another very important threat classification list called the OWASP Automated Threats (OAT) Project and provide a foundational overview. The terms Malicious Bot and Automated Threat can be used interchangeably throughout. In future articles we'll dive deeper into individual key threats called OATs and demonstrate how these attacks work and how to defend against them. Why should we care about the OWASP Automated Threats Project? Web security is no longer constrained to inadvertent vulnerabilities and attackers are abusing inherent functionality to conduct Automated and Manual Fraud. Existing technologies are not capable of detecting advanced automated abuse, fraud teams can’t keep up with new fraud mechanisms, while web users are increasingly adverse to encountering Authentication Friction created by legacy or traditional bot defenses like CAPTCHAs. From its original release in 2015, the OWASP Automated Threat Handbook has now become a de facto industry standard in classifying Bots and better understanding all aspects of Malicious Web Automation. What OATs Are Not - Not another vulnerability list - Not an OWASP Top N List - Not threat modelling - Not attack trees - Not non web - Not non application What Are OATs (aka Malicous Bots)? In order to quantify these threats, it is necessary to be able to name them. OAT stands for OWASP Automated Threat and there are currently 21 attack vectors defined. Currently OAT codes 001 to 021 are used. Within each OAT the Threat definition contains a description, the sectors targeted, parties affected, the data commonly misused, and external cross mappings to other lists like CAPEC Category, possible symptoms, suggested countermeasures, etc... Here is the Full List of OATs ordered by ascending name: Identifier OAT Name Summary Defining Characteristics OAT-020 Account Aggregation Use by an intermediary application that collects together multiple accounts and interacts on their behalf OAT-019 Account Creation Create multiple accounts for subsequent misuse OAT-003 Ad Fraud False clicks and fraudulent display of web-placed advertisements OAT-009 CAPTCHA Defeat Solve anti-automation tests OAT-010 Card Cracking Identify missing start/expiry dates and security codes for stolen payment card data by trying different values OAT-001 Carding Multiple payment authorisation attempts used to verify the validity of bulk stolen payment card data OAT-012 Cashing Out Buy goods or obtain cash utilising validated stolen payment card or other user account data OAT-007 Credential Cracking Identify valid login credentials by trying different values for usernames and/or passwords OAT-008 Credential Stuffing Mass log in attempts used to verify the validity of stolen username/password pairs OAT-021 Denial of Inventory Deplete goods or services stock without ever completing the purchase or committing to the transaction OAT-015 Denial of Service Target resources of the application and database servers, or individual user accounts, to achieve denial of service (DoS) OAT-006 Expediting Perform actions to hasten progress of usually slow, tedious or time-consuming actions OAT-004 Fingerprinting Elicit information about the supporting software and framework types and versions OAT-018 Footprinting Probe and explore application to identify its constituents and properties OAT-005 Scalping Obtain limited-availability and/or preferred goods/services by unfair methods OAT-011 Scraping Collect application content and/or other data for use elsewhere OAT-016 Skewing Repeated link clicks, page requests or form submissions intended to alter some metric OAT-013 Sniping Last minute bid or offer for goods or services OAT-017 Spamming Malicious or questionable information addition that appears in public or private content, databases or user messages OAT-002 Token Cracking Mass enumeration of coupon numbers, voucher codes, discount tokens, etc OAT-014 Vulnerability Scanning Crawl and fuzz application to identify weaknesses and possible vulnerabilities Automated Threats Breakdown By Industry Within each OAT definition there is a section for the Sectors Targeted for that particular attack vector. For example, a Carding Attack would be seen on ecommerce and retail type of sites with payment card processing. Here they would be able to validate a list of stolen credit card numbers to identify the working ones from non working. Example: OAT-001 Carding Attack example highlighting "Sectors Targeted" for this type of attack. This exists for each attack definition. OWASP Defined Countermeasures Countermeasure Classes: The technology and vendor agnostic countermeasure classes attempt to group together the types of design, development and operational controls identified from research that are being used to partially or fully mitigate the likelihood and/or impact of automated threats to web applications. In all applications, builder-defender collaboration is key in controlling and mitigating automated threats – the best protected applications do not rely solely upon standalone external operational protections, but also have integrated protection built into the design. Similarly to other types of application security threat, it is important to build consideration of automated threats into multiple phases of a secure software development lifecycle (S-SDLC). 14 Countermeasure Classes: Value Authentication Requirements Rate Testing Monitoring Capacity Instrumentation Obfuscation Contract Fingerprinting Response Reputation Sharing Countermeasure Controls Countermeasures are controls that attempt to mitigate the identified automated threats in three ways: Prevent - Controls to reduce the susceptibility to automated threats Detect - Controls to identify whether a user is an automated process rather than a human, and/or to identify if an automated attack is occurring, or occurred in the past Recover - Controls to assist response to incidents caused by automated threats, including to mitigate the impact of the attack, and to to assist return of the application to its normal state. Cross References Other Threat Mappings Each OAT Threat is cross referenced with other external threat lists to provide and understanding of how this OAT Handbook can be integrated with other works. Example, OAT Threat below shows the cross referenced CAPEC, CWE, and WASC Threat ID's You can find links to each of the external classification models below: Mitre CAPEC - best full and/or partial match CAPEC category IDs and/or attack pattern IDs WASC Threat Classification - best match to threat IDs Mitre Common Weakness Enumeration - closely related base, class & variant weakness IDs Matching pages defining terms classified as Attacks on the OWASP wiki Youtube Conclusion In conclusion, the OWASP Automated Threat Handbook has now become a de facto industry standard in classifying and better understanding all aspects of malicious web automation. We can use this handbook to build secure software development lifecycles around our web properties and implement the appropriate countermeasure to prevent unwanted automation against them. OWASP Links OWASP Automated Threats to Web Applications Home Page OWASP Automated Threats Identification Chart OWASP Automated Threats to Web Applications Handbook F5 Related Content Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) How Attacks Evolve From Bots to Fraud Part: 1 How Attacks Evolve From Bots to Fraud Part: 2 F5 Distributed Cloud Bot Defense F5 Labs 2021 Credential Stuffing ReportF5 Distributed Cloud Bot Defense (Overview and Demo)
What is Distributed Cloud Bot Defense? Distributed Cloud Bot Defense protects your web properties from automated attacks by identifying and mitigating malicious bots. Bot Defense uses JavaScript and API calls to collect telemetry and mitigate malicious users within the context of the Distributed Cloud global network. Bot Defense can easily be integrated into existing applications in a number of ways. For applications already routing traffic through Distributed Cloud Mesh Service, Bot Defense is natively integrated into your Distributed Cloud Mesh HTTP load balancers. This integration allows you to configure the Bot Defense service through the HTTP load balancer's configuration in the Distributed Cloud Console. For other applications, connectors are available for several common insertion points that likely already exist in modern application architectures. Once Bot Defense is enabled and configured, you can view and filter traffic and transaction statistics on the Bot Defense dashboard in Distributed Cloud Console to see which users are malicious and how they’re being mitigated. F5 Distributed Cloud Bot Defense is an advanced add-on security feature included in the first launch of the F5 Web Application and API Protection (WAAP) service with seamless integration to protect your web apps and APIs from a wide variety of attacks in real-time. High Level Distributed Cloud Security Architecture Bot Defense Demo: In this technical demonstration video we will walk through F5 Distributed Cloud Bot Defense, showing you how quick and easy it is to configure, the insights and visibility you have while demonstrating a couple of real attacks with Selenium and Python browser automation. "Nature is a mutable cloud, which is always and never the same." - Ralph Waldo Emerson We might not wax that philosophically around here, but our heads are in the cloud nonetheless! Join the F5 Distributed Cloud user group today and learn more with your peers and other F5 experts. Hope you enjoyed this Distributed Cloud Bot Defense Overview and Demo. If there are any comments or questions please feel free to reach us in the comments section. Thanks! Related Resources: Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) Protecting Your Web Applications Against Critical OWASP Automated Threats Making Mobile SDK Integration Ridiculously Easy with F5 XC Mobile SDK Integrator JavaScript Supply Chains, Magecart, and F5 XC Client-Side Defense (Demo) Bots, Fraud, and the OWASP Automated Threats Project (Overview) Protecting Your Native Mobile Apps with F5 XC Mobile App Shield Enabling F5 Distributed Cloud Client-Side Defense in BIG-IP 17.1 Bot Defense for Mobile Apps in XC WAAP Part 1: The Bot Defense Mobile SDK F5 Distributed Cloud WAAP Distributed Cloud Services Overview Enable and Configure Bot Defense - F5 Distributed Cloud ServiceBeyond REST: Protecting GraphQL
GraphQL GraphQL is a query language for APIs developed by Facebook, that provides an efficient and flexible alternative to traditional RESTful APIs. It allows clients to request only the data they need, avoiding over-fetching or under-fetching of information. GraphQL enables developers to specify the structure of the response they want, making it easier to aggregate data from multiple sources in a single request. This adaptability is particularly advantageous in scenarios where mobile or web applications require diverse sets of data. As a result, GraphQL has become an attractive alternative for many developers and organizations looking to capitalize on this flexibility and possible performance improvements. Introspection Introspection is a feature that allows clients to query the schema of a GraphQL API at runtime. It allows for the dynamic exploration of types, fields, and their associated information, giving clients the ability to create documentation, validate queries, and understand the structure and capabilities of the GraphQL server. Security Considerations While GraphQL offers numerous advantages in terms of flexibility and efficiency, it also introduces unique security considerations that warrant attention. One notable concern is the potential for unintentional data exposure due to its introspective nature. Additionally, GraphQL's ability to execute multiple queries in a single request creates the risk of resource exhaustion through complex or nested queries, leading to denial-of-service (DoS) vulnerabilities. Furthermore, the dynamic nature of GraphQL schemas makes it crucial to implement proper input validation to prevent malicious queries or injections. Understanding and addressing these security risks is paramount for ensuring the robustness of GraphQL-based systems, and it underscores the importance of incorporating effective security measures into the development, deployment, and runtime processes. Protecting GraphQL with F5 Distributed Cloud GraphQL Discovery: GraphQL discovery plays a pivotal role in the comprehensive API discovery process within the F5 Distributed Cloud WebApp and API Protection service. This ensures that developers, security architects, and administrators gain visibility into and information about the available GraphQL endpoints. GraphQL Inspection: Inspection is a fundamental component of protecting GraphQL, offering granular control over security parameters. By setting limits on the maximum total length, maximum structure depth of a GraphQL query, and imposing restrictions on the maximum number of queries in a single batched request, the service can mitigate the risk of DOS attacks and ensures optimal system performance by preventing excessively complex or resource-intensive requests. Disabling introspection queries further enhances security by limiting the exposure of sensitive API details, reducing the attack surface and reinforcing overall GraphQL security. Conclusion Since its development in 2012, adoption of GraphQL has witnessed a steady growth year-over-year. The efficiency and power of the API has made it a popular choice with many development teams. With an ever-increasing threat surface and a high potential for attack, organizations must prioritize safeguarding their users by investing in robust security. As part of a Defense in-Depth security strategy, the F5 Distributed Cloud WebApp and API Protection service can help ensure your GraphQL APIs are protected from abuse. F5 GraphQL Inspection and Protection Demo Additional Resources Deploy F5 Distributed Cloud API Discovery and Security: F5 Distributed Cloud WAAP Terraform Examples GitHub Repo Deploy F5 Hybrid Architectures API Discovery and Security: F5 Distributed Cloud Hybrid Security Architectures GitHub Repo F5 Distributed Cloud Documentation: F5 Distributed Cloud Terraform Provider Documentation F5 Distributed Cloud Services API Documentation
Mitigation of OWASP API Security Risk: BOPLA using F5 XC Platform
Introduction: OWASP API Security Top 10 - 2019 has two categories “Mass Assignment” and “Excessive Data Exposure” which focus on vulnerabilities that stem from manipulation of, or unauthorized access to an object's properties. For ex: let’s say there is a user information in json format {“UserName”: ”apisec”, “IsAdmin”: “False”, “role”: ”testing”, “Email”: “apisec@f5.com”}. In this object payload, each detail is considered as a property, and so vulnerabilities around modifying/showing these sensitive properties like email/role/IsAdmin will fall under these categories. These risks shed light on the hidden vulnerabilities that might appear when modifying the object properties and highlighted the essence of having a security solution to validate user access to functions/objects while also ensuring access control for specific properties within objects. As per them, role-based access, sanitizing the user input, and schema-based validation play a crucial role in safeguarding your data from unauthorized access and modifications. Since these two risks are similar, the OWASP community felt they could be brought under one radar and were merged as “Broken Object Property Level Authorization” (BOPLA) in the newer version of OWASP API Security Top 10 – 2023. Mass Assignment: Mass Assignment vulnerability occurs when client requests are not restricted to modifying immutable internal object properties. Attackers can take advantage of this vulnerability by manually parsing requests to escalate user privileges, bypass security mechanisms or other approaches to exploit the API Endpoints in an illegal/invalid way. For more details on F5 Distributed Cloud mitigation solution, check this link: Mitigation of OWASP API6: 2019 Mass Assignment vulnerability using F5 XC Excessive Data Exposure: Application Programming Interfaces (APIs) don’t have restrictions in place and sometimes expose sensitive data such as Personally Identifiable Information (PII), Credit Card Numbers (CCN) and Social Security Numbers (SSN), etc. Because of these issues, they are the most exploited blocks to gain access to customer information, and identifying the sensitive information in these huge chunks of API response data is crucial in data safety. For more details on this risk and F5 Distributed Cloud mitigation solution, check this link: Mitigating OWASP API Security Risk: Excessive Data Exposure using F5 XC Conclusion: Wrapping up, this article covers the overview of the newly added category of BOPLA in OWASP Top 10 – 2023 edition. Finally, we have also provided minutiae on each section in this risk and reference articles to dig deeper into F5 Distributed Cloud mitigation solutions. Reference links or to get started: F5 Distributed Cloud Services F5 Distributed Cloud WAAP Introduction to OWASP API Security Top 10 2023Mitigating OWASP API Security Risk: Excessive Data Exposure using F5 XC Platform
This is part of the OWASP API Security TOP 10 mitigation series, and you can refer here for an overview of these categories and F5 Distributed Cloud Platform (F5 XC) Web Application and API protection (WAAP). Introduction to Excessive Data Exposure Application Programming Interfaces (APIs) are the foundation stone of modern evolving web applications which are driving the digital world. They are part of all phases in product development life cycle, starting from design, testing to end customer using them in their day-to-day tasks. Since they don't have restrictions in place, sometimes APIs expose sensitive data such as Personally Identifiable Information (PII), Credit Card Numbers (CCN) and Social Security Numbers (SSN), etc. Because of these issues, they are the most exploited blocks in cybercrime to gain access to customer information which can be sold or further used in other exploits like credential stuffing, etc. Most of the time, the design stage doesn't include this security perspective and relies on 3rd party tools to perform sanitization of the data before displaying the results to customers. Identifying the sensitive information in these huge chunks of API response data is sophisticated and most of the available security tools in the market don't support this capability. So instead of relying on third party tools it's recommended to follow shift left strategies and add security as part of the development phase. During this phase, developers must review and ensure that the API returns only required details instead of providing unnecessary properties to avoid sensitive data exposure. Excessive data exposure attack scenario-1 To showcase this category, we are exposing sensitive details like CCN and SSN in one of the product reviews of Juice shop application (refer links for more info) as below - Overview of Data Guard: Data Guard is F5 XC load balancer feature which shields the responses from exposing sensitive information like CCN/SSN by masking these fields with a string of asterisks (*). Depending on the customer's requirement, they can have multiple rules configured to apply or skip processing for certain paths and routes. Preventing excessive data exposure using F5 Distributed Cloud Step1: Create origin pool - Refer here for more information Step2: Create Web Application Firewall policy (WAF) - Refer here for details Step3: Create https load balancer (LB) with above created pool and WAF policy - Refer here for more information Step4: Upload your application swagger file and add it to above load balancer - Refer here for more details Step5: Configure Data Guard on the load balancer with action and path as below Step6: Validate the sensitive data is masked Open postman/browser, check the product reviews section/API and validate these details are hidden and not exposed as in original application In Distributed Cloud Console expand the security event and check the WAF section to understand the reason why these details are masked as below: Excessive data exposure attack scenario-2 In this demonstration we are using an API based vulnerable application VAmPI (VAmPI is a vulnerable API made with Flask, and it includes vulnerabilities from the OWASP top 10 vulnerabilities for APIs, for more info follow the repo link). Follow below steps to bring up the setup: Step1: Host the VAmPI application inside a virtual machine Step2: Login to XC console, create a HTTP LB and add the hosted application as an origin server Step3: Access the application to check its availability. Step4: Now enable API Discovery and configure sensitive data discovery policy by addingall the compliance frameworks in your HTTP LB config. Step5: Hit the vulnerable API Endpoint '/users/v1/_debug' exposing sensitive data like username, password etc. Step6: Navigate to security overview dashboard in the XC console and select the API Endpoints tab. Check for vulnerable endpoint details. Step7: In the Sensitive Data section, click Ellipsis on the right side to get options for action. Step8: Clicking on the option 'Add Sensitive Data Exposure Rule' will automatically add the entries for sensitive data exposure rule to your existing LB configs. Apply the configuration. Step9: Now again, hit the vulnerable API Endpoint '/users/v1/_debug' Here in the above image, you can see masked values in the response. All letters changed to 'a' and number is converted to '1'. Step10: Optionally you can also manually configure sensitive data exposure rule by adding details about the vulnerable API endpoint. Login back to XC console Start configuring API Protection rule in the created HTTP LB Click Configure in the Sensitive Data Exposure Rules section. Click Add Item to create the first rule. In the Target section, enter the path that will respond to the request. Also enter one or more methods with responses containing sensitive information. In the Values field in Pattern section, enter the JSON field value you want to mask. For example, to mask all emails in the array users, enter “users[_].email”. Note that an underscore between the square brackets indicates the array's elements. Once the above rule gets applied, values in the response will be masked as follows: All letters will change to a or A (matching case) and all numbers will convert to 1. Click Apply to save the rule to the list of Sensitive Data Exposure Rules. Optionally, Click Add Item to add more rules. Click Apply to save the list of rules to your load balancer. Step11: After the completion of Step10, Hit back the vulnerable API Endpoint. Here also in the above image, you can see masked values in the response as per the configurations done in Step 10. Conclusion As we have seen in the above use cases sensitive data exposure occurs when an application does not protect sensitive data like PII, CCN, SSN, Auth Credentials etc. Leaking of such information may lead to serious consequences. Hence it becomes extremely critical for organizations to reduce the risk of sensitive data exposure. As demonstrated above, F5 Distributed Cloud Platform can help in protecting the exposure of such sensitive data with its easy to use API Security solution offerings. For further information check the links below OWASP API Security - Excessive Data Exposure OWASP API Security - Overview article F5 XC Data Guard Overview OWASP Juice Shop VAmPIMitigating OWASP API Security Risk: Unrestricted Resource Consumption using F5 Distributed Cloud Platform
Introduction: Unrestricted Resource Consumption vulnerability occurs where an API allows end users to over-utilize resources (e.g., CPU, memory, bandwidth, or storage) without enforcing proper limitations. This can lead to overwhelming of the system, performance degradation, denial of service (DoS) or complete unavailability of the services for valid users. Attack Scenario: In this demo, we are going to generate huge traffic and observe the server’s behaviour along with its response time. Fig 1: Using Apache JMeter to send arbitrary number of requests to API endpoint continuously in very short span of time. Fig 2: (From left to right) Response time during normal and server with huge traffic. Above results show higher response time when abnormal traffic is sent to a single API endpoint when compared to normal usage. By further increases in volume, server can become unresponsive, deny requests from real users and result in DoS attacks. Fig 3: Attackers performing arbitrary number of API request to consume the server’s resources Customer Solution: F5 Distributed Cloud (XC) WAAP helps in solving above vulnerability in the application by rate limiting the API requests, thereby preventing complete consumption of memory, file system storage, CPU resources etc. This protects against traffic surge and DoS attacks. This article aims to provide F5 XC WAAP configurations to control the rate of requests sent to the origin server. Step by Step to configure Rate Limiting in F5 XC: These are the steps to enable Rate Limiting feature for APIs and its validation Add API Endpoints with Rate Limiter values Validation of request rate to violate threshold limit Verifying blocked request in F5 XC console Step 1: Add API Endpoints with Rate Limiter values Login to F5 XC console and Navigate to Home > Load Balancers > Manage > Load Balancers Select the load balancer to which API Rate Limiting should be applied. Click on the menu in Actions column of the app’s Load Balancer and click on Manage Configurations as shown below to display load balancer configs. Fig 4: Selecting menu to manage configurations for load balancer Once Load Balancer configurations are displayed, click on Edit configuration button on the top right of the page. Navigate to Security Configuration and select “API Rate Limit” in dropdown of Rate Limiting and click on “Add Item” under API Endpoint section. Fig 5: Choosing API Rate Limit to configure API endpoints. Fig 6: Configuring rate limit to API Endpoint Rate limit is configured to GET request from API Endpoint “/product/OLJCESPC7Z”. Click on Apply button displayed on the right bottom of the screen. Click on “Save and Exit” for above configuration to get saved to Load Balancer. Validation of request rate to violate threshold limit Fig 7: Verifying request for first time Request is sent for the first time after configuring API Endpoint and can be able to see the response along with status code 200. Upon requesting to the same API Endpoint beyond the threshold limit blocks the request as shown below, Fig 8: Rate Limiting the API request Verifying blocked request from F5 XC console From the F5 XC Console homepage, Navigate to WAAP > Apps & APIs > Security and select the Load Balancer. Click on Requests to view the request logs as below, Fig 9: Blocked API request details from F5 XC console You can see requests beyond the rate limiter value get dropped and the response code is 429. Conclusion: In this article, we have seen that when an application receives an abnormal amount of traffic, F5 XC WAAP protects APIs from being overwhelmed by rate limiting the requests. XC's Rate limiting feature helps in preventing DoS attacks and ensures service availability at all times. Related Links: API4:2019 Lack of Resources and Rate Limiting API4:2023 Unrestricted Resource Consumption Creating Load balancer Steps F5 Distributed Cloud Security WAAP F5 Distributed Cloud Platform
