Last Modified: Nov 07, 2022
Affected Product:
See more info
BIG-IP APM
Known Affected Versions:
11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.10, 11.5.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9
Fixed In:
13.0.0
Opened: Jun 29, 2016
Severity: 3-Major
In multidomain SSO, when accessing a virtual with a POST, the user may be redirected to the auth virtual. When the user is redirected back to the original url, we lose the original POST data. This is because we use HTTP 302, which allows the browser to change the method. In these situations we should use 307, which does not allow the browser to change the method.
User sends a GET to the resource, instead of the POST that should have been sent.
This is difficult to avoid if the access policy needs to run on the auth virtual. This bug is about saving the POST when the policy has already run, and we are only redirecting to the auth virtual to receive the cookie.
An iRule can be used to change some of the 302 redirects to a 307. when HTTP_REQUEST { set uri [HTTP::uri] } when HTTP_RESPONSE_RELEASE { if { [HTTP::status] contains "302" && ([HTTP::header value "Location"] contains "SSO_ORIG_URI" || $uri contains "SSO_ORIG_URI") } { HTTP::header replace ":S" "307 Temporary Redirect" } }
When redirecting to and from the auth virtual, we now use a 307. We continue using 302 with redirects to /my.policy and other parts of running the access policy. In those situations, a 307 could cause the browser to resend the POST made to an APM login page.