Login, Authentication and SSO Session (the basics):
SMSESSION is a Transient Cookie: A SiteMinder environment with (one or more) Policy Servers and 'traditional' Web Agents tracks a users 'web' session using an SMSESSION cookie. By default this is a transient (or session) HTTP cookie set in the users browser, hence it will be removed when the user's browser session is closed, or when another web server expires or overwrites the cookie in the same domain.
SMSESSION contains encrypted data from both the Web Agent and Policy Server: When a user logs in the Web Agent asks the Policy Server to authenticate the user (over the RSA RC4 encrypted connection between the agent and Policy Server). If the user can be authenticated, the Policy Server generates a unique session ID, this ID is combined with the user's identity and other tracking data and is encrypted using the 'Session Ticket Key' to create a Session Ticket. If the SiteMinder session server is enabled then the session ID is written in the session store. It is the Session Ticket that is returned to the Web Agent with the authentication success message. The Web Agent then combines the encrypted Session Ticket with its own tracking data and encrypts the result using the 'Web Agent Key' to produce the content for the SMSESSION cookie. This cookie is returned to the user's browser in the HTTP(s) response. CA always recommends that all authentication and access to secured content is provided over SSL (HTTPS). Once the user has an SMSESSION in her browser, the cookie will be provided in the subsequent HTTP(s) request to any web server in the matching cookie domain. If the Web Agent is configured to 'UseSecureCookie' then the SMSESSION is flagged with the cookie secure parameter - this is an instruction to the web client (browser) to only send the cookie over SSL connections (obviously it is up to the client to enforce this).
SMSESSION provides SSO: When an SMSESSION cookie is presented to a Web Agent secured server, the agent can decrypt the cookie if it shares the same Web Agent Key as the Web Agent which encrypted the cookie. After its own validation the agent will present the encrypted Session Ticket to a Policy Server. The Policy Server can decrypt the Session Ticket IFF it shares the same Session Ticket Key as the Policy Server which encrypted the Session Ticket, it can also validate the Session Ticket IFF it applies the same Policies to the user repository. It is important to note the Web Agent never has access to the Session Ticket Key on the Policy Server. The keys are shared using the Key Store and maybe rotated at configured intervals. The SSO solution provides flexibility to deploy multiple protected Web Servers and Policy Servers; providing high performance, redundancy, availability and scalability across multiple sites and geographies. This can be provided with minimal data replication - i.e. shared keys.
Man in the Middle (stealing a cookie):
HTTP is a stateless protocol; HTTP session cookies allow the user to maintain a security or application session across web based applications. There are other session tracking solutions, including SSL ID tracking, URL rewriting (and query strings). However, cookies are the least bad solution. SSL ID's are renegotiated by the client during a single session (by the client), URL rewriting or other URL schemes are weak as the URL is exposed in many more scenarios than a cookie would be exposed, and unique session URLs impact on caching solutions. With an HTTP session cookie solution there are a number of scenarios where an attacker may steal the cookie; any security solution is only as strong as its weakest link:
In the examples above, where the attacker has access to be able to programmatically capture the cookie in plain format, he would most likely also have access to capture entered credentials in plain format - which is arguably more dangerous than the cookie itself. If a cookie is captured there are safeguards to prevent it from being 'replayed'.
Logout and Session Timeout:
If a cookie is stolen it must be reused within the Max Session Time and Max Idle Time configured on the SiteMinder protected realm. So by configuring a short Idle Timeout, the window of opportunity for a reply can be reduced. And by configuring a short Max Session Time the period for which the session can be reused before the user must re-authenticate is limited.
If Transient IP Checking is enabled on the SiteMinder Web Agent configuration object, then any replay of the cookie must originate from the same IP address as the original authentication (the original IP address is contained in the encrypted content of the session cookie). Due to HTTP proxies, firewalls and NAT it is likely that requests which are routed over the internet, from say a machine on a corporate network, will look to originate from the same IP address, so the transient IP check does not prevent all cookie replay attacks.
If the user logs out from his authenticated session then this does not automatically prevent a stolen session cookie from being re-used. The default behavior for logout is to invalidate the browsers copy of the session cookie by overwriting the content, additionally all Policy Server and Web Agent memory caches pertaining to the session are flushed, the session flush may take up to twice the time of the Web Agent management interval or Policy Server admin interval (default is one minute) to propagate to all Web Agents.
To prevent any access using a stolen session cookie after the user has logged out. The SiteMinder Session Server must be enabled. This database tracks the sessions (by session ID) generated by each Policy Server. When a logout occurs the session is removed from the Session Server, so can no longer be validated.
The Session Server database must be accessible by each Policy Server, and is access for authentication, logout and at any point where the Policy Server(s) must validate the users session. As such there is additional overhead when using the Session Server. To limit this overhead it is possible to enable the Session Server on a per-Realm.
Let?s consider the 4 position the attack could come from, as described in the previous note:
In cases 2 and 3, there is nothing we can do on the SiteMinder side. On the other hand, if an attacker was to get access there, he would probably focus on getting different information than session cookies.
In case 1, CA always recommends the use of SSL (HTTPs) communication for all secure traffic.
Additionally measures should be in place to prevent the cookie from being unwittingly sent over HTTP:
In case 4, we can imagine an attacker getting physical access to a PC. In that case, I imagine he would simply copy the session cookie and paste it on his own machine, to be able to access the session. The best prevention here is to educate and remind employees that they should never leave their PC unattended without locking it first.
Anyway, if you think this is a high risk in your environment, please read the section "Logout and Session Timeout", where it is explained some principles such as Transient IP, Max Session Time and Max Idle Time, Session Server. Although those will not prevent the attacker to steal the cookie, it does mitigate the risk.
As you explained me, your company went under a security audit which recommends to put in place additional protection against phishing. At the moment, you are using HTTPS and standard SiteMinder security recommendations.
We have discussed the 3 main parameters relative to phishing that you could use. However, along our conversation, it appeared that there was cross incompatibility between those. Please find below a summary of dependencies and incompatibilities for those 3 parameters.