RE: How to protect against cookie stealing?

[Ingo Struck <ingo () ingostruck de>]

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