RE: How to protect against cookie stealing?

Only issue I see with this is that the client address can change in a
proxy situation without it being a security issue. Assume several
proxies being load balanced as an example.

-gabe

-----Original Message-----
From: Ingo Struck [mailto:ingo_at_ingostruck.de]
Sent: Thursday, July 24, 2003 5:34 AM
To: Phil.Cox_at_SystemExperts.com
Cc: webappsec_at_securityfocus.com
Subject: RE: How to protect against cookie stealing?

Hi...

> The application does not associate the cookie to any
session-specific
> information (e.g., source IP address), so another user can also use
the
> BLAH_SESSIONID cookie to access the same information (over a
> different TCP/IP session) that the legitimate user can. [...]
Ok, the mechanism should be clear to anyone.
You already outline a solution to prevent session stealing:
- the application must gather as much specific information as possible
  upon "initial" requests (those that generate a new session), store
that
  information internally and compare each subsequent request that
  claims to belong to that session against the stored info.
 
If an application doesnt do that, then it's of course a poor app...

What we use for this within OCL (OWASP Common Library,
see http://sourceforge.net/projects/owasp for the source and
http://beta.owasp.org/development/ocl for an overview) is:
 - host
 - originating address
 - user agent
They are attached to any session and each subsequent request is
checked against that (in addition the OCL allows for "logged in"
sessions over a secure port, e.g. 443 only and checks for that too,
privileged sessions are not allowed to be reverted to an insecure port).

See org.owasp.aux.servlet.ServletUtil::checkUnprivileged and
org.owasp.aux.servlet.ServletUtil::checkPrivileged for some java code.

> Historically I have believed that having the application associate
> the BLAH_SESSIONID session cookie and its associated privileges
> with a specific SSL session or source IP address would prevent this
> session stealing.
In fact you are right and should retain to this policy.
Note that an IP address is meant to identify exactly one computer.
Dynamic IP allocation or dynamic IP sharing should be considered
abuse anyway, so users who want to access secure web apps should
really *NOT* support or use ISPs who do that.

The problem thus has to be solved from two sides:
a) implement the known technical countermeasures against the simplest
   forms of session stealing (if there's a proxy inbetween you can at
least
   dramatically isolate the circle of possible attackers)
b) tell the users who are "locked out" due to these countermeasures
   why and what they should do to be worth considered for "secure"
access

Note, however that these countermeasures against session stealing are
not 100% fool-proof (they still allow for MITM attacks), but they are
not limited to Cookie-based sessions only. Combined with a decent
security
logging they help at least to reveal most of the trials to steal SIDs.

Kind regards

Ingo Struck

---
Ingo Struck
OWASP http://owasp.org