It's a really interesting idea, and it is a damn shame that the cookie
spec wasn't drawn up with the idea of PKI negotiation, but ultimately I
don't think it's possible to pull off. There are no webservers that I know
of (including Apache with mod_ssl) that have an API to expose that
information to software on higher levels. And if SSL is being done in
acceleration hardware, you can forget about it altogether. Even with an
open source operating system web server and SSL module, you'd be in for some
/major/ hacking.
    If you want a really secure stateful solution for HTTP sessions, start
with SSL, use long, purely pseudo-randomly generated session IDs (no hashing
the user's IP, the current time, etc.) and use keep-alive.

Kevin Spett
SPI Dynamics, Inc.
http://www.spidynamics.com/

----- Original Message -----
From: "Ben Mord" <bmordicon-nicholson.com>
To: "webappsec securityfocus.com" <webappsecsecurityfocus.com>
Sent: Thursday, July 25, 2002 2:52 PM
Subject: Coordinating SSL and session tracking layers to foil session
hijacking

> As most readers on this list know, many web applications employ a session
> tracking mechanism which set a cookie to a random identifier for that user
> session. The user is then authenticated by other means, but once
> authenticated, that cookie is then used to associate future user actions
> with the user's identity. This session-tracking mechanism is usually
> supplied by application server middleware such as a servlet engine, or an
> ASP engine. It is exposed to the programmer as customizable server-side
> "session variables" that automagically follow the user.
>
> A completely separate application layer is often used to secure the
traffic
> with SSL. Because this service can not be completely delineated from
> HTTP-level responsibilities, this SSL functionality is usually provided by
> the web server and the resulting combination is called HTTPS.
>
> Has anyone tried to get these two layers to talk to each other? We have
two
> concepts of a session here. At a lower level we have the SSL session, and
at
> a higher level we have the cookie-based concept of a session. Only one of
> these two sessions was rigorously designed using cryptographic principles
to
> prevent hijacking. Unfortunately, this is not the one used by custom
> application logic to enforce user-specific access control! Programmers use
> the weaker, cookie-based concept.
>
> The obvious solution is to get the session tracking mechanism to talk
> directly to the SSL engine, so that it can use the SSL session instead of
an
> intrinsically weak cookie identifier. Am I missing here? The fact that you
> can hijack a user session despite SSL by knowing the cookie (perhaps via
> cross-site scripting) points to a simple flaw in the middleware. Cookies
are
> simply too general-purpose of a mechanism to serve such a critical role in
> session security. The session key used in SSL, on the other hand, serves
no
> other purpose and is therefore highly optimized and protected. Getting the
> SSL implementation to talk to the session-tracking mechanism should be
> trivial for the vendors of these products - all that is needed is an
> industry standard.
>
> Is there a flaw in my logic somewhere, or do people agree with this
> assessment? Is anyone aware of efforts to make this happen, or does anyone
> have opinions about which industry organization is in the best position to
> make this happen?
>
> Thanks,
> Ben
>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]