Bug ID 519612: JavaScript challenge fails when coming within iframe with different domain than main page

Last Modified: May 07, 2019

Bug Tracker

Affected Product:  See more info
BIG-IP ASM(all modules)

Known Affected Versions:
12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3

Fixed In:
13.1.0, 13.0.1, 12.1.3

Opened: Apr 23, 2015
Severity: 3-Major

Symptoms

The JavaScript Challenge fails when coming within an iframe that is on a different domain than the main page.

Impact

On the browser, the iframe will fail to load, leaving a white box, or the following message: "Please enable browser cookies to view the page content." There may be error messages in the browser's console.

Conditions

1. The web application uses an iframe coming from a different domain than the main page, AND 2. Any of the following options are enabled on an ASM Policy or Application DoS Profile attached to the Virtual Server which is handling the iframe: a. DoS Client-Side Integrity Defense Mitigation (affecting only during attack mitigation) b. DoS CAPTCHA Mitigation (affecting only during attack mitigation) c. Device-ID (fingerprint) d. Web Scraping Bot Detection Challenge e. Proactive Bot Defense (with/without "Block Suspicious Browsers")

Workaround

It is possible to workaround the problem using Proactive Bot Defense (DoS Profile) and iRules. This works even if the problem is in Web Scraping and DoS profile was not previously used. The following steps must be done for the Virtual Server handling the iframe, as well as the one handling the main page. 1. Attach a DoS profile to the Virtual Server (if not already attached). 2. Disable TPS-based detection (unless already enabled, or it is desired). 3. Enable Proactive Bot Defense on the DoS profile (if not already enabled). a. Disable "Block Suspicious Browsers" (unless already enabled, or it is desired). b. Configure Cross-Domain Requests to "Allow configured domains; validate upon request". c. Add the domain of the main page to the Related Site Domains. 4. Attach the following iRule to the virtual server: ltm rule rule_fix_cross_domain_challenges { when HTTP_REQUEST { set refdom "" regexp -nocase {^https?://([^/]*).*$} [HTTP::header referer] -> refdom log local0. "uri [HTTP::uri] host [HTTP::host] referer [HTTP::header referer] refdom $refdom" if { $refdom ne "" && $refdom ne [HTTP::host] } { BOTDEFENSE::cs_allowed false } } } NOTES: 1. The challenges must run on the main page. The following rule block could be used to force the challenges to run on a specified URL or URLs. when HTTP_REQUEST { if { [HTTP::uri] eq "/" } { BOTDEFENSE::cs_allowed true } } 2. If additional URLs are getting blocked or challenged as a result of Proactive Bot Defense and it is unwanted, it is possible to control them in the iRule by checking for URLs and using the "BOTDEFENSE::action allow" command.

Fix Information

JavaScript challenges no longer fail when coming within an iframe on a different domain than the main page.

Behavior Change