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@ingostruck.de]
Sent: Thursday, July 24, 2003 5:34 AM
To: Phil.Cox@SystemExperts.com
Cc: webappsec@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
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
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
Received on Sun Jul 27 11:42:23 2003
This archive was generated by hypermail 2.1.8
: Wed Aug 23 2006 - 14:07:54 EDT
|