Single Sign On SMSESSION able to be stolen and reused - is that a vulnerability?

Document ID : KB000117845
Last Modified Date : 19/10/2018
Show Technical Document Details
Security Testing is able to demonstrate how they can store an SMSESSION, perform a logoff and then reuse the SMSESSION cookie - is that a vulnerability.?
Single Sign On environments 12.52 12.7 12.8. 

Yes, if you can steal the SMSESSION cookie, and make use of it within the idle timeout period - then yes you can hijack the session. 

The reliance is on the SSL session, and the integrity of the client computer, and the server computer so that the cookies are not stolen. 

If the SMSESSION is stolen, then the SMSESSION cookie is valid for short period of time (idle-timeout) time after it is stolen. 

In that sense it acts much the same as a JSESSIONID (or ASPSESSIONID) - if a user steals these cookies then they can also use them to hijack a users session (although stolen JSESSIONID's/ASPSESSIONID's do not have an inbuilt expiry timestamp). 

However, the subtle difference is that for the short period after user logout, an older SMSESSION is valid (until idle timeout), whereas a JSESSIONID / ASPSESSIONID which rely on backend database are invalid from the point of logout when the entry in the db/memory table is deleted. 

In my opinion, a lot is made of that small difference, whereas in practice the difference in exposure is small. 


a) Ensure integrity of SSL, client computer and server computers. 

b) Client IP Check 
The SMSESSION cookie has the IP address stored in it, if you implement client IP check it ensures all requests from from the same IP as was used for the login (this check has limitations because of limits of what IP can be obtained from the server side. )

c) Session Store 
A session store can be setup and will give the ability to invalidate the session at logout across all domains. So that the session cannot be used after the logout - and that is what we recommend if this feature is needed. 

d) Device DNA 
As per the article, device DNA takes a hash or "fingerprint" of the client machine, using various headers and variables available to javascript, the hash is used to periodically re-direct the user back for a check, to ensure the fingerprint has not changed. The hash still has a small time-to-lice after last update, but is a more comprehensive fingerprint of the client. 


For secure transactions we needed: 
a) The reliance is on the SSL session, and 
b) the integrity of the client computer, and 
c) the integrity of the server computer 

to ensure the cookies are not stolen. 

If either of those things are broken, a) the SSL session, or b) the client computer, or c) the server computer - then generally you have much worse problems to worry about. Since you are open to stealing the user credentials UN/PW, run keyloggers on your local machine, or the ability to modify the or insert requests into the SSL stream or doctor them at the server. The hacker can also does not need to wait for you to logout to use your session - they can (generally) make requests while you are still logged in. 

Other options for session stealing from getting access to backup logs, or use of data left in browsers on shared use computers. Again with the inbuilt timestamp helps make the SMSESSION time sensitive. A proper logout will give the SMSSESSION=LOGGEDOFF so the cookie is not accessible to a next user on a communal computer. However, the case of not logging out of a communal computer, or closing the browser does allow someone to continue the session. 


The siteminder SMSESSION uses an encrypted session details (including a timestamp) in the SMSESSION cookie, that is why it is so large. 

With all the details contained within the cookie, it did not need a central database of valid sessions or require the request to come back to the same physical web server to be validated. 

Historically that gave much better performance, failure tolerance, and resilience, since each webserver/policy server could validate the session cookie independent of other servers. (For comparison, JSESSIONID or ASPSESSIONID do require you to come back to the same server, and/or other schemes always required webservers to check with a central database of valid session id's ). 

The tradeoff is the SMSESSION cookie is quite large, and validity of the session is determined by a timestamp in the cookie - and the (large) cookie is updated regularly to update the timestamp. (Compared to say JSESSIONID, which is just 20 bytes or so, is a random value, is not updated, and never changes, since it is just an hash index to an in-memory-database of valid sessions). 

However, since early days, networks and computers are much more reliable, and so having a centralized database of valid sessions, works fairly well now. And SSO has this ability when needed, using the session store. The main use is for storage of server side session variables, such as those associated with OAuth logins, but it is also used for single logout purposes. 
Additional Information:
Logoff of SSO Session 
At logoff the users SMSESSION cookie is set to LOGGEDOFF, terminating the session.

Multiple cookie domains 
A Single Sign On install can be setup with multiple domains, coordinating their session via a cookie provider.    If there are multiple "Single Sign On" domains and a cookie provider coordinating the sessions between the domains, then it is possible that logout of one domain will leave SMSESSION cookies for other domains still active for the idle-timeout-time.   

A logout process can be designed to redirect to all the active domains setting the SMSESSION cookie in all domains to LOGGEDOFF

Other useful links :