Javascript injecting systems effect on web application end users - a scenario review
Hello! ArvinF is back to share a scenario review where Javascript-injecting systems affected web application end users - web and mobile application. Problem Users are failing to login to a web application protected by BIG-IP ASM/Adv WAF and Shape Security Defense. The site owner notes that the authentication was failing for an unknown reason. There were ASM Support ID noted and an error informing to enable Javascript. Please enable JavaScript to view the page’s content. Your support ID is: xxxxxxxxxxxx Troubleshooting To understand the cause of the authentication failure, we gathered HTTP traffic through a HTTP sniffer. We used httpwatch and gathered HAR (HTTP Archive) files. The site was protected with both on-premise BIG-IP ASM/Adv WAF bot defense and back then, Shape Security Defense (now F5 Distributed Cloud Bot Defense). After the review of the HAR file in httpwatch, the following were noted: ASM blocks a request in a URL related to authentication with a Support ID in the response. There was also javascript code included and it references https[:]//s[.]go-mpulse[.]net/boomerang/. The authentication attempt failed with an error in the HTTP response: ...unable to process your request. Please try again later... BIG-IP ASM/Adv WAF related HTTP cookies from its various features such as Bot Defense Client Side challenges as TSPD_101* cookie was present and other TS cookies, which could also come from Bot defense and DoS profile and security policy configurations. There were also HTTP cookies coming from BIG-IP AVR - f5_cspm cookie was present. Application Visibility and Reporting (AVR) module provides detailed charts and graphs to give you more insight into the performance of web applications, with detailed views on HTTP and TCP stats, as well as system performance (CPU, memory, etc.). https://clouddocs.f5.com/training/community/analytics/html/index.html https://clouddocs.f5.com/api/irules/AVR_CSPM_INJECTION.html Seeing the javascript code referencing "/boomerang/" included in the ASM blocking response was interesting. Reviewing the HAR file, there were several instances of this "/boomerang/". This finding was inquired with the site owner and they noted that there is another system that is in the path between the end users and their web application - a CDN. The traffic flow is as follows: End user web browser / mobile application >>> CDN >>> FW >>> BIG-IP >>> web application On the BIG-IP Virtual Server that fronts the web application, F5 AVR profile, ASM/Adv WAF Bot defense, and security policy and Shape Security defense iRule are configured. From the F5 side, these were the products with features that may insert Javascript in the client-side response. As part of troubleshooting, to isolate the feature that might be causing the failing authentication for the web application, the bot defense profile was removed from the site's Virtual Server and the Shape Security iRule and AVR profile were left untouched. Site owner noted that the authentication works after this change. Shape Security Defense was implemented using an iRule to protect specific URIs. When the iRule was removed from the Virtual Server and the Bot defense and AVR profile were left on, the VS, Site owner noted that the authentication works after this change. But if both ASM/Adv WAF Bot defense and Shape Security Defense iRule is configured on the VS, the site's authentication fails. Per the site owner, there were no changes in the Bot Defense or Shape Security Defense iRule configurations prior to the incident and that these configurations were in place way before the incident. Site owners shared the findings with their respective internal teams for their review. Resolution Afterwards, Site owner shared that their site now works as expected and authentication works for the web application with no changes done on both ASM/Adv WAF Bot defense and Shape Security Defense iRule on the site's VS. The cause of the authentication failure was undetermined. A theory on the possible cause of the issue was perhaps, there was another system inserting Javascript code in the responses and it might have affected the authentication process of the web application by prevented that portion of the site from loading. Additional Troubleshooting Notes The data gathered during the troubleshooting were the qkview and HTTPWatch capture - HAR files. It would help if a packet capture was taken along with the HTTPWatch capture while the issue was happening to have a full view of the issue. Decrypt the packet capture to observe HTTP exchanges and to correlate it with HTTPWatch capture events. The corresponding BIG-IP ASM/Adv WAF application event logs, Bot Defense or DoS protection logs will also be helpful in the correlation. Having a visual idea on how the Security Policy, Bot Defense or DoS protection profile are configured is also helpful - so its good to have a screenshot of these. It helps in analysis when there is complete data. Gathering the asmqkview with report and traffic data and corresponding ASM and AVR db dumps helps in the analysis. asmqkview -s0 --add-request-log --include-traffic-data -f /var/tmp/`/bin/hostname`_asmqkview_`date +%Y%m%d%H%M%S`.tgz #mysqldump -uroot -p`perl -I/ts/packages -MPassCrypt -nle 'print PassCrypt::decrypt_password($_)' /var/db/mysqlpw` DCC | gzip -9 > /shared/tmp/dcc.dump.gz # mysqldump -uroot -p`perl -I/ts/packages -MPassCrypt -nle 'print PassCrypt::decrypt_password($_)' /var/db/mysqlpw` PLC | gzip -9 > /shared/tmp/plc.dump.gz # mysqldump -uroot -p`perl -I/ts/packages -MPassCrypt -nle 'print PassCrypt::decrypt_password($_)' /var/db/mysqlpw` PRX | gzip -9 > /shared/tmp/prx.dump.gz # mysqldump -uroot -p`perl -I/ts/packages -MPassCrypt -nle 'print PassCrypt::decrypt_password($_)' /var/db/mysqlpw` logdb | gzip -9 > /shared/tmp/logdb.dump.gz It would also help if the systems in the path of the web application are known and whether it has features that may interfere with the features of BIG-IP ASM/Adv WAF or Shape Security Defense. Per the findings, there was a CDN that was injecting javascript code in the HTTP response and it may have contributed to the authentication failure for the end users. Isolate potentially conflicting features by removing one of them one at a time and observe the HTTP responses. Per the reference configuration, BIG-IP ASM/Adv WAF, Shape Security Defense, and BIG-IP AVR worked well prior to the incident. boomerang The injected javascript code noted in the ASM blocking page response was loaded from https[:]//s[.]go-mpulse[.]net/boomerang/. Checking this reference, it was related to https://github.com/akamai/boomerang. boomerang is a JavaScript library that measures the page load time experienced by real users, commonly called RUM (Real User Measurement). It has the ability to send this data back to your server for further analysis. With boomerang, you find out exactly how fast your users think your site is. In BIG-IP, the similar product we have is BIG-IP AVR - Application Visibility and Reporting (AVR) - where it collects "performance of web applications, with detailed views on HTTP and TCP stats, as well as system performance (CPU, memory, etc.)." Organizations may have specific needs on data that they need to collect from their site/web application and using a customizable solution such as boomerang can help. That's It For Now I hope this scenario review on Javascript-injecting systems effect on web application end users will be helpful on your next troubleshooting and hopefully gives you guidance on what data to gather and look for and troubleshooting options. The F5 SIRT creates security-related content posted here in DevCentral, sharing the team’s security mindset and knowledge. Feel free to view the articles that are tagged with the following: F5 SIRT series-F5SIRT-this-week-in-security TWIS
F5 AWAF Bot Defense Whitelist
According to https://techdocs.f5.com/en-us/bigip-14-1-0/big-ip-asm-implementations-14-1-0/configuring-bot-defense.html, having whitelists can speed up access time to the website. Is it because WAF will not check those whitelisted URLs coming to the web site, thereby making it faster? (Faster when users access the web site because less traffic to be validated by WAF?)
Invalid Character
System Information: F5 BIG-IP r2600 Version 17.1.1.1 Build 0.0.2 Hello everyone, I want to protect a web application with the f5 BIG-IP. When I open the page, I get the error "SyntaxError: Invalid character '\u2013'" in the browser's developer menu. If I now deactivate Bot Defense for the virtual server, the website works. There is no indication in the logs that anything is being blocked. I have also tried adding the URL path as an exception, but to no avail. Perhaps someone here has had the same problem. Google and ChatGPT could not help me. Best regards :)F5 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 protectyour 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 Service
ASM Bot Defense JS and CSP
Our company has issued a requirement for all applications to enable CSP (Content Security Policy). The problem is one of the first applications to enable this has Bot Defense enabled. Part of PBD is to inject a JAVA script inline which causes an issue with the page not loading per the CSP policy. We opened a support case and F5 level II and the ENE say they can't find a way to make these compatible and this is beyond the scope of Support i.e. engage Professional Services. I'm a long-time F5 user and so this was frustrating, to say the least. Part of our CSP is our scripts have a nonce key generated. PBD script is not being delivered from our server (it's directly injected into the response), and it does not contain our nonce key. This means that the CSP will tell the browser to NOT allow the execution of that script thereby breaking the application. Part of the CSP Rules The browser should accept any JS that is delivered as a file from 'self' which means it's delivered from our web server with a relative path The browser should accept any JS that is delivered to the browser with our nonce key (value in the header) All other JS should be ignored by the browser! So, the only question that we really had for F5 is how do we make PBD JS work with a CSP? The CSP is set up in a basic way and is not customized to our application at all. It seems we either need to have this JS delivered by a file (not directly injected) or the F5 will need to pick up our nonce key and add it to that injection. Has anyone come across this and what methods did you employ to resolve it, i.e. iRule or Traffic policy to set the nonce key on the JS, which is not super ideal? Depending on when ASM/PBD fire, something similar to the following: when HTTP_RESPONSE { # Check if the response header contains a CSP if {[HTTP::header exists "Content-Security-Policy"]} { # Get the CSP header value set csp [HTTP::header value "Content-Security-Policy"] # Check if the CSP contains a nonce if {[string first "nonce-" $csp] != -1} { # Get the nonce value set nonce [string range $csp [string first "nonce-" $csp] [string first ";" $csp]] # Check if the response body contains a script tag if {[string first "<script" [HTTP::payload]] != -1} { # Add the nonce to the script tag HTTP::payload replace [string first "<script" [HTTP::payload]] [string first ">" [HTTP::payload]] "<script nonce=\"$nonce\"" } } } }Making Mobile SDK Integration Ridiculously Easy with F5 XC Mobile SDK Integrator
Introduction To prevent attackers from exploiting mobile apps to launch bots, F5 provides customers with the F5 Distributed Cloud (XC) Mobile SDK, which collects signals for the detection of bots. To gain this protection, the SDK must be integrated into mobile apps, a process F5 explains in clear step-by-step technical documentation. Now, F5 provides an even easier option, the F5 Distributed Cloud Mobile SDK Integrator, a console app that performs the integration directly into app binaries without any need for coding, which means no need for programmer resources, no need to integration delays. The Mobile SDK Integrator supports most iOS and Android native apps. As a console application, it can be tied directly into CI/CD pipelines to support rapid deployments. Use Cases While motivations for using SDK Integrator may vary, below are some of the more common reasons: Emergency integrations can be accomplished quickly and correctly. Customers experiencing active bot attacks may need to integrate with F5 Distributed Cloud Bot Defense immediately and minimize integration risks. Apps using 3rd-party libraries may not be suitable for manual integration, particularly when these libraries do not provide APIs for adding HTTP headers into network requests. In such cases, the SDK Integrator can inject SDK calls into the underlying network stack, bypassing the limitations of the network library. Customers who own multiple apps, which may have different architectures, or are managed by different owners, need a single integration method, one which works for all app architectures and is simple to roll out to multiple teams. The SDK Integrator facilitates a universal integration approach. How It Works The work of the SDK Integrator is done through two commands: the first command creates a configuration profile for the SDK injection, and the second performs the injection. Step 1: $ python3 ./create_config.py --target-os Android --apiguard-config ./base_configuration_android.json --url-filter "*.domain.com/*/login" --enable-logs --outfile my_app_android_profile.dat In Step 1, apiguard-config lets the user specify the base configuration to be used in integration. With url-filter we specify the pattern for URLs which require Bot Defense protection, enable-logs allows for APIGuard logs to be seen in the console, outfile specifies the name of this integration profile. Step 2: $ java -jar SDK-Integrator.jar --plugin F5-XC-Mobile-SDK-Integrator-Android-plugin-4.1.1-4.dat --plugin my_app_android_profile.dat ./input_app.apk --output ./output_app.apk --keystore ~/my-key.keystore --keyname mykeyname --keypass xyz123 --storepass xyz123 In Step 2, we specify which SDK Integrator plugin and configuration profile should be used. In the same step, we can optionally pass parameters for app-signing: keystore, keyname, keypass and storepass. Output parameter specifies the resulting file name. The resulting .apk or .aab file is a fully integrated app, which can be tested and released. Injection steps for iOS are similar. The commands are described in greater detail in the SDK Integrator user guides distributed with the SDK Integrator. Mobile SDK Integrator Video In Conclusion In order to thwart potential attackers from capitalizing on mobile apps to initiate automated bots, The F5 Distributed Cloud Mobile SDK Integrator seamlessly incorporates the SDK into app binaries, completely bypassing the necessity for coding making the process easy and fast. Related Content Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) Protecting Your Native Mobile Apps with F5 XC Mobile App Shield Bot Defense for Mobile Apps in XC WAAP Part 1: The Bot Defense Mobile SDKProtecting Your Native Mobile Apps with F5 XC Mobile App Shield
Introduction Mobile App Shield is a security technology that integrates directly into mobile applications to provide proactive security against a wide range of attacks, such as tampering, debugging, code injection, code modification and stealing of data from the app. Mobile App Shield is delivered in separate packages for iOS and for Android. Shielding an app with Mobile App Shield is an automated process. Key Capabilities F5 Distribtued Cloud (XC) Mobile App Shield contains multiple security features to counter threats found in the Android and iOS eco-system, and are outlined further below. Product Demo In this Product Demonstration we'll be showcasing Mobile App SHIELD with a product demonstration of how to both integrate SHIELD while also highlighting the protection it provides Conclusion Mobile App Shield represents an advanced security technology seamlessly embedded within mobile applications, offering proactive protection against a diverse array of threats and is easily coupled with XC Bot Defense for comprehensive Mobile App Protection for both Android and iOS. Related Content Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) Bot Defense for Mobile Apps in XC WAAP Part 1: The Bot Defense Mobile SDK F5 Bot Defense Solutions F5 Fraud Solutions F5 Authentication Intelligence The OWASP Automated Threats Project OWASP Automated Threats - CAPTCHA Defeat (OAT-009) OWASP Automated Threats - Credential Stuffing (OAT-008) OWASP Automated Threats - OAT-001 Carding Operationlizing Online Fraud Detection, Prevention, and Response JavaScript Supply Chains, Magecart, and F5 XC Client-Side Defense (Demo) How Attacks Evolve From Bots to Fraud Part: 1 How Attacks Evolve From Bots to Fraud Part: 2 F5 Distributed Cloud Bot Defense (Overview and Demo)Bot Defense for Mobile Apps in XC WAAP Part 1: The Bot Defense Mobile SDK
Introduction The amount of automated attacks that target mobile devices is increasing rapidly each year and causes major financial damage across industries. Today, malicious bots are launched in droves to attack our mobile devices and apps where most of our online activity happens. Unfortunately for developers of mobile apps, many techniques used by traditional bot-defense solutions are not supported by native mobile apps. As a result, if developers do not take precautions, their back-end mobile API components can be exposed to automated attacks such as content scraping, denial of service (DOS), credential stuffing, fake account creation, and a host of others. F5's Mobile SDK is a component of the F5 Distributed Cloud (F5 XC) Bot Defense service. It is designed to protect requests made by native mobile apps.Similar to the web JavaScript solution, Bot Defense Mobile SDK works by gathering telemetry on the mobile device, and sending it to the Bot Defense server as headers with the protected requests. Bot Defense Mobile SDK exists for both iOS and Android, and functions similarly on both platforms. Demo: In our first demo we’re going to navigate through the WAAP (Web App & API Protection) Connector for Distributed Cloud Bot Defense and step through the configuration items to protect a mobile application endpoint In Conclusion: A Mobile app is a prime target for attack because it is so ubiquitous and has been traditionally difficult to secure. Software Development Kits (SDKs) such as the F5 Bot Defense Mobile SDK eliminate that difficulty and enable app developers to quickly integrate critical security features into their code—without having to write additional code themselves. F5 Related Content Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) F5 Bot Defense Solutions F5 Fraud Solutions F5 Authentication Intelligence The OWASP Automated Threats Project OWASP Automated Threats - CAPTCHA Defeat (OAT-009) OWASP Automated Threats - Credential Stuffing (OAT-008) OWASP Automated Threats - OAT-001 Carding Operationlizing Online Fraud Detection, Prevention, and Response JavaScript Supply Chains, Magecart, and F5 XC Client-Side Defense (Demo) How Attacks Evolve From Bots to Fraud Part: 1 How Attacks Evolve From Bots to Fraud Part: 2 F5 Distributed Cloud Bot Defense (Overview and Demo)OWASP Automated Threats - OAT-005 Scalping
Introduction: In thisOWASP Automated ThreatArticle we'll be highlightingOAT-005 Scalpingwith some basic threat information as well as a recorded demo to dive into the concepts deeper. In our demo we'll show how Automation is used to monitor and wait for goods or services to become available and then take rapid action to beat normal users to obtain them. We'll wrap it up by highlightingF5 XC Bot Defenseto show how we solve this problem for our customers. Scalping Description: Acquisition of goods or services using the application in a manner that a normal user would be unable to undertake manually. Although Scalping may include monitoring awaiting availability of the goods or services, and then rapid action to beat normal users to obtain these.Scalping includes the additional concept of limited availability of sought-after goods or services, and is most well known in the ticketing business where the tickets acquired are then resold later at a profit by the scalpers. OWASP Automated Threat (OAT) Identity Number OAT-005 Threat Event Name Scalping Summary Defining Characteristics Obtain limited-availability and/or preferred goods/services by unfair methods. OAT-005 Attack Demographics: Sectors Targeted Parties Affected Data Commonly Misused Other Names and Examples Possible Symptoms Entertainment Many Users NA Bulk purchase High peaks of traffic for certain limited-availability goods or services Financial Application Owner Purchase automation Increased circulation of limited goods reselling on secondary market Retail Purchase bot Queue jumping Ticket Scalping Scalping Demo: In this demo we will be showing a simple example of how automation is used to monitor and wait for goods or services to become available and then take rapid action to beat normal users to obtain them. We'll then have a look at the same attack with F5 Distributed Cloud Bot Defense protecting the application. In Conclusion: Scalping Bots are a real problem for organization and customers as they are made up of a vast ecosystem to acquire large amounts of inventory at scale to be sold for a profit. F5 has the solutions to provide superior efficacy to interrupt and stop this unwanted automation. 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 The OWASP Automated Threats Project OWASP Automated Threats - CAPTCHA Defeat (OAT-009) OWASP Automated Threats - Credential Stuffing (OAT-008) OWASP Automated Threats - OAT-001 Carding Operationlizing Online Fraud Detection, Prevention, and Response JavaScript Supply Chains, Magecart, and F5 XC Client-Side Defense (Demo) How Attacks Evolve From Bots to Fraud Part: 1 How Attacks Evolve From Bots to Fraud Part: 2 F5 Distributed Cloud Bot Defense
