Bug ID 688365: Access can lose the initial POST body if backend resets

Last Modified: Jul 03, 2019

Bug Tracker

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

Known Affected Versions:
11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 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.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.0.0.5, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.4, 14.1.0.5, 14.1.0.6

Opened: Oct 12, 2017
Severity: 3-Major

Symptoms

If the initial request is a POST, then ACCESS will save the POST body before running the access policy. Once the policy completes, ACCESS redirects the client to the landing URI, with some injected Javascript to include a POST parameter 'dummy'. Once ACCESS receives the 'dummy' parameter, it is replaced by the initial POST body. However, this replacement can only happen once. If the backend sends a reset, the client browser will likely resend the 'dummy' POST, but ACCESS will not recognize the dummy a second time, and the initial POST body will not be inserted.

Impact

Backend application server will receive a 'dummy' POST body. Impact will depend on the application. In one deployment this resulted in SAML assertion failures.

Conditions

Initial POST body. Access policy has completed, and client browser sends a 'dummy' POST to the landing URI. Then something (backend or some APM component sends a reset) causes the browser to resend the 'dummy' POST.

Workaround

None

Fix Information

None

Behavior Change