- Just a quick note - this statement is not really correct :
Note that even if the application uses and SSL/TLS (HTTPS) connection, the request URL itself is not encrypted over the internet and can be recovered in plain text and replayed without any need to break the HTTPS encryption.
The URL is sent over the SSL/TLS session and is not visible unless someone has the ssl session keys.
The hostname is visible since a socket connection SSL?TLS is make to the host name www.example.com to then negotiate the SSL handshake. But the contents of the URL :
is sent over the SSL/TLS encrypted channel and is not in visisble in cleartext.
There is a preference for POST data rather than GET parameters since GET parameters like the above are logged in access_logs and the like on the server, whereas POST data or cookies are not (unless you put in specific rules).
That is what I think you are probably alluding to.
2. Cookie providers domains
There is also ACO parameter validtargetdomain where you can restrict the domains where the cookie provider will return to, and there was some internal mechanism in the cookie itself to ensure those were generated for the right target when returned (my experience is with case where request was forward internally and they did not match).
ValidTargetDomain Help Prevent Attacks - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation
TrackCPSessionDomain Configure Web Agent Single Sign-On Settings - CA Single Sign-On - 12.8 - CA Technologies Documentation
There is also similar mechanism for different zones and cookies in place.
I know this has been gone over quite a few times internally from security perspective - particularly in the latter versions and fixes were added - and that they are fairly confident that the method is safe.
3. Cookie validity time
SSO cookies are valid until idletimeout is reached, (unless you have a session store). So usually the cookie is "active" for 10min or so before it becomes stale. If someone has access to your cleartext stream (including URL for redirects to cookie providers) then they can use the stolen cookie for that idle timeout time.
The methods like device DNA, and IP check are meant to be additional guards on the session cookie coming from some other source during that idle timeout period.
My suspicion however, is that they will keep the GET for cookie providers and slowly move to a more federated method for doing these cross domain relationships as the preferred approach.
But also if you have specific example of vulnerability then it is probably best to raise a case with the penetration test that is used, then we can follow it up with the security team.
Cheers - Mark