[Owasp-appsensor-project] Question about SE4: Substituting Another User's Valid Session ID or Cookie

Kevin W. Wall kevin.w.wall at gmail.com
Tue Aug 30 19:36:30 EDT 2011


On Tue, Aug 30, 2011 at 6:03 PM, Ryan Barnett <ryan.barnett at owasp.org> wrote:
> This email is more about implementation of Detection Points as I am in the
> process implementing AppSensor Detection Points in the OWASP ModSecurity
> CRS.
> I am currently looking at the Session Exception category and have a question
> about SE4 -
> https://www.owasp.org/index.php/AppSensor_DetectionPoints#SE4:_Substituting_Another_User.27s_Valid_Session_ID_or_Cookie
> SE4, SE5 and SE6 all seem to be related to Session Hijacking where an
> attacker is able to somehow obtain an authenticated user's SessionID and
> they then simultaneously log into the application.  At this point, Detection
> Points SE5 and SE6 would most likely trigger as the Source IP/Range and the
> User-Agent string values would most likely change.  Without correlating
> SE5/SE6, how would you suggest SE4 be detected?  How would you know that the
> SessionID/Cookie data is not correct for that user?  In ModSecurity CRS, we
> use the SessionID as the key for persistent storage of data.  The Session
> Hijacking rules grab the User-Agent and IP block hashes and save them in the
> Session collection.  If there is ever a mismatch, they alerts for SE5 and
> SE6 are triggered.
> I am not sure how to trigger SE4 on its own.
> Suggestions welcome.

I guess that 'SE4' could depend on how you interpret the term 'Session Cookie',
or perhaps just how it is implemented. If we are talking about
something other than
the normal, run-of-the-mill 'JSESSIONID' or 'ASPSESSIONID' cookies /
identifiers that
are generally used for session identity, then I could see one way that
this could happen.
Suppose instead of merely using hashed-based session identifiers or ones from a
cryptographically strong PRNG, one instead created an *encrypted*
cookie and used
them for session identities.

On could include any reasonably unchanging HTTP request header values in
the encrypted session identifier (e.g., Locale:, User-Agent, the names [or even
values] of other cookies that are present, etc.) BTW, it is also
common to include a
last update time and the user name in such cookies.

So, in the example that Ryan was discussing, lets suppose that the
session cookie
itself contained the encrypted value for the User-Agent header in it
along with other
things (e.g., probably a cryptographically secure random # of N-bits).  So Eve
is playing the role of the passive attacker and steals Alice's encrypted session
cookie and then plays it back to the site. The server gets the cookie, decrypts
it, and checks the individual values. Lo and behold it finds a
discrepancy between
Alice's User-Agent value (from the decrypted cookie) and Eve's User-Agent
value. The conclusion is that one cookie was substituted for another.

So that is one way that SE4 could happen.

And lest you think that this is a far-fetched example, it actually is pretty
common with "web application management" systems such as CA's SiteMinder
or RSA Security's Access Manager.

HTH,
-kevin
--
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents."        -- Nathaniel Borenstein


More information about the Owasp-appsensor-project mailing list