Using SiteMinder to Secure against Session Hijacking

[AaronBerman]

There are two new videos out, first I demonstrate how the SiteMinder 12.52 Enhanced Session assurance feature secures the siteminder session against session hijacking / replay attacks,

http://www.youtube.com/watch?v=S0Atd_JFML0 

Then I discuss how to link the siteminder session to an applications session to extend this Session Assurance feature to the application cookie

http://www.youtube.com/watch?v=P6JPrL0Su-w

 

Aaron

 

 

 

[Anon Anon]

HI Aron,

Thanks for sharing the videos.

The Enhanced Session Assurance feature does enhance security in terms of session replay or its use after session being hijacked.

Question 1) Correct me please if wrong -This feature does prevent session replay attack as it has fingerprint data but its all useful if session is already hijacked.becoz we are simply storing it as a part of session to avoid replay.I do understand the traditional flow for this featue pretty much comparable to Cookie provider and.ccc

Question 2) Isint there a bigger RISK when we actually allow device/user details to be set in cookie/session , simply because it allows hijackers more information about the user/device, while using the existing functionalities of Siteminder Webagent we can always prevent session reply with exposed parameters which are already part of session spec or rather SMSESSION.

isnt this betetr , If we consider Riskfort/Risk minder there are options where we can actually check characteristics of user/device (fingerprint data) at a runtime/checkpoint.(without storing all in cookie)

Say I am using RiskMinder in XYZ BANK and while paying to third party, I can just check if device fingerprint has changed since user logged in.

What are your thougts on this Sir.

[AaronBerman]

Learner999,

I am sorry, but i am having a little trouble understanding your questions.  I think you are asking:

 

1) How will Session Assurance work if the user session has already been stolen? before the device DNA is read?

Session assurance will be part of the authentication flow that occurs during login.  While it can be done on an application by application basis, when generating the original device fingerprint the user must re-enter their credentials if the fingerprint was not captured during login

 

2) Is storing the session assurance fingerprint in a cookie increasing the overall risk of the system?

Session assurance stores a hash of the fingerprint in the SM session, but that is encrypted inside of the siteminder session.  This way we know the fingerprint of the server that the sm session was created for.  The existing siteminder agent does not provide this capability today.  While there are several settings and even architectures that one can use to reduce the chances of a siteminder session  getting stolen, typically only idle timeouts and IP address checking can be used to try and detect session stealing before the session assurance feature was introduced

 

 

[Anon Anon]

HI Aaron,

Thanks for your thougts, you covered the query one pretty well.Thanks for that.

On Query 2, let me put this way- We are putting more data in a Siteminder Sessions (though Hashed) which obviously means--the cracker or the hacker can potentially

get more information about the target system and the user now.

While Riskfort can check the same parameters/device fingerpring attributes without storing in cookie(thus less exposure) versus if I compare it with the fingerprnt as a part of session

is a higher risk. Any thoughts on this?

regards,