OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Ben Mord (b-mord-5_at_alumni.uchicago.edu)
Date: Mon Jul 29 2002 - 15:07:54 CDT

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

    -----Original Message-----
    From: Sean Z. [mailto:syzhongyahoo.com]
    Sent: Friday, July 26, 2002 9:02 PM
    To: webappsecsecurityfocus.com
    Subject: Re: Coordinating SSL and session tracking layers to foil
    session hijacking
    > In fact, you should never expect SSL reach your
    > application! The SSL may terminate at an SSL offLoader,
    > a load balancer or an application firewall which is
    > used to protect your application by filtering user
    > data. So your application receives only plain text.

    Whether SSL is handled directly on the web server or in a separate box, I
    still don't see why they can't coordinate. All that is needed is an
    extension to the protocol connecting the SSL offloader to the web server.

    You can view that SSL offloader as a specialized HTTP proxy. So, one natural
    way for it to communicate SSL session info to the web server would be to add
    a unique HTTP header with a made-up but unique per-session id before
    forwarding the unencrypted request to the web and application servers. Of
    course it would need to filter this field if submitted by the client to
    prevent a malicious client from deliberately interfering with this process.
    There is precedent for this already in the HTTP 1.1 specification - it
    defines several other proxy-generated HTTP headers. This is just one example
    of how you could do it, and there are probably better ways.

    > And an URL can have multiple cookies. You can use one
    > cookie for authentication only like in the SSL and other
    > cookies for other use.

    As I think I explained earlier, my concern about cookies is not that I'll
    somehow run out of storage space on the client, or that I want to store
    other info in cookies, or anything like that. My concern is instead that
    cookies were not designed to function as the ultra-secure underpinnings of
    an authentication protocol. SSL session keys, on the other hand, were
    designed exactly for this purpose. As such, stealing SSL session keys is
    much harder than stealing cookie data. This is why you will hear of XSS
    attacks (and other script-kiddie level techniques) for stealing cookie data,
    but you probably won't hear of XSS attacks for stealing SSL session IDs.

    But thanks for the response.

    Ben