Apparently, there is a security vulnerability with Cross Domain Single Sign On (Cookie Provider). With GET based requests at login time or during session update, the browser will redirect to the cookie provider with the SMSESSION recoverable by a hacker from just the request URL. With SecureURLs=NO, the redirect includes an SMSESSION query parameter that can be replayed through the browser directly. With SecureURLs=Yes, you will see SMQUERYDATA, but the whole URL can be copied to a browser and replayed to set the session cookie and redirect the user back to the original application. A second redirect will then recover the Cookie Provider cookie and set one for the application and the hacker is in. 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.
According to a case opened with CA (01072531: Security Vulnerability with Cookie Provider), there are only a couple of options to close this loophole. You can try to implement IP address checking for the session (TransientIPCheck=Yes, PersistentIPCheck=Yes). This will prevent the request from being replayed by someone from a different user source IP address. It is possible to spoof an originating IP address. Also, this setting is not always possible as users sometime come from inside client networks that "NAT" the address from a pool. From SiteMinder's perspective, the user is seen to jump between source IP addresses. This setting will reject these users.
The second option is to implement a Session Store and use Session Validation to detect the shift of the users device. According to CA support, there is no other way at present to prevent session hijacking when cross domain single sign on is used. The use of a session store can be problematic across datacenters. In addition, all application access is lost if the session store becomes unavailable. My company has been trying to avoid this component for these reasons.
The documentation should be VERY clear on this point.
Also, redirects between domains should encrypt any sensitive data in the body of a POST request. This is not how the web agents work today. I request that CA consider a web agent upgrade to add this capability and a new configuration parameter similar to "PostCPRedirects" which can be used enable/disable it for compatibility and adoption purposes.