Re: [PEN-TEST] HTTP Secure Session State Management

[Thomas Reinke <reinke () E-SOFTINC COM>]

Philip Stoev wrote:

> > Something like an MD5 hash is pretty good for this.  Perhaps
> > a hash of the user's first and last name, address and the record ID.
>
> The IP address must always be a part of the session ID, and must be checked

No...that won't work. There are numerous users (few compared to the
whole,
but enough that it needs to be covered) that sit behind round robining
proxy/NAT devices. This means the same user that in one second comes in
as one IP address will come on the request as a second IP address.
You could of course restrict the IP check to the same class C (until
you find someone that has the proxy across multiple class C's...)

> for accuracy at all stages. You should ask for password again if the user
> suddenly starts to make HTTP requests from another IP address than the one
> he initially authenticated with. I do not think this is paranoid, but it
> rather prevents somebody else's hijacking your login form and creating a
> man-in-the-middle situation. It is not the best possible protection, but
> will work in most cases.
>
> Philip

As pointed out previously (Kurt - SecurityPortal), security is NOT
only addressed by technology, but both by technology and people.
No matter what you try to do, uneducated/lazy surfing habits can
always get you in trouble.  The question is always what is too
much, and what isn't.

For what it's worth (and even this isn't as secure as it could be,
but is _very_ good and has been used in practice on several highly
secure sites), you can use:

  a) Session Identifiers in a cookie tagged as secure
  b) A second token (e.g. random string) added to the session ID,
     and also stored on the server. Basically, prevents against
     brute forcing the session identifier. E.g. WebSphere's
     session identifiers are not truly random, and IBM themselves
     recommends NOT relying on security solely through them.
  c) For the truly paranoid, a double check of the user agent string
     to confirm it is the same as when the session was first created.
  d) For the triply paranoid, the unproven technique of comparing
     a portion of the IP (I KNOW /24 won't work, I'd suggest
     limiting to /16)
  e) Sessions have a timeout from last "active" time of X (e.g.
     15 minutes). If the session has timed out, you bounce them
     to the login screen or something else appropriate.
  f) You provide a logout button and encourage users to use it.
  g) You encourage users to quit their browser after being done with
     your site (IMO overkill, but a number of financial sites
     recommend this).

Cheers, Thomas
--
------------------------------------------------------------
Thomas Reinke                            Tel: (905) 331-2260
Director of Technology                   Fax: (905) 331-2504
E-Soft Inc.                         http://www.e-softinc.com
Publishers of SecuritySpace     http://www.securityspace.com