Last Modified: Sep 13, 2023
Affected Product(s):
BIG-IP ASM
Known Affected Versions:
11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1, 12.1.2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 12.1.3.6, 12.1.3.7, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.0.0.5, 14.0.1, 14.1.0, 14.1.0.1
Fixed In:
15.0.0, 14.1.0.2, 14.0.1.1, 13.1.1.5, 12.1.4
Opened: Aug 09, 2018 Severity: 3-Major
A JavaScript whitepage challenge does not reconstruct when the challenge is on a POST request and the response from the back-end server is 307 Redirect. This happens only if the challenged URL is on a different path than the redirected URL. This prevents the application flow from completing.
Server is not able to parse the request payload and application does not work. This issue occurs because the TS*75 cookie is set on the path of the challenged URL, so the redirected URL does not contain the cookie, and the payload is not reconstructed properly to the server.
- JavaScript challenge / CAPTCHA is enabled from either Bot Defense, Proactive Bot Defense, Web Scraping, DoSL7 Mitigation or Brute Force Mitigation. - The challenge is happening on a POST request on which the response from the server is a 307 Redirect to a different path.
As a workaround, you can construct an iRule to identify that the response from the server is 307 Redirect, retrieve the TS*75 cookie from the request, and add to the response a Set-Cookie header, setting the TS*75 cookie on the '/' path.
Having a JavaScript challenge on a POST request with 307 Response no longer prevents the application from working.