|
WebApp Sec
mailing list archives
RE: How to protect against cookie stealing?
From: "Dawes, Rogan (ZA - Johannesburg)" <rdawes () deloitte co za>
Date: Fri, 25 Jul 2003 08:33:31 +0200
Hi Death, :-)
The reason that one can't simply link the IP address to the session is that
there are ISP's, in particular AOL, that use cache arrays in a load
balancing configuration. So a request that goes through one proxy could be
followed by one that goes through a different one.
Plus the fact that all users behind a single proxy would be seen to have the
same IP address.
A lot of people do not permit active content such as ActiveX objects, which
would be the only way to get the MAC address from the client. Besides which,
if the originating site can access this object through a script, so could
the attacker through an XSS, and supply that information to the attacker at
the same time as the sessionid.
I think this is the reason that nothing has been done about this problem:
* If the attacker can't XSS the user, they can't get the sessionid (unless
it is predictable, which is just stupid!), hence there is no problem.
* If the attacker CAN XSS the user, then they can also get whatever other
information that they need to impersonate the user, except for the IP
address, which unfortunately, we can't rely on anyway, so we CAN'T do
anything about the problem.
Rogan
-----Original Message-----
From: .:[ Death Star]:. [mailto:deathstar () optonline net]
Sent: 24 July 2003 07:14 PM
To: 'Dawes, Rogan (ZA - Johannesburg)'; 'Phil Cox';
webappsec () securityfocus com
Subject: RE: How to protect against cookie stealing?
It is possible to associate each session ID with one IP address. In
other words, you can make your script reject sessions
generated from the
same IP (this is to avoid proxy's having the same IP address for
different sessions and the same IP address requesting an existing
session). This can be done by keeping an active table of
sessionID's and
associated IP's.
There is another solution, you can use both sessionID's and
cookies, so
based on the IP address you would look for the cookie before
giving the
user access control. The session ID will store 2 fields
(example userid
and associated ip address) the cookie will hold other fields.
And u can
use multiple sessions and multiple cookies that will be destroyed upon
opening another page.
Another solution is to create a script that will place an
object on the
user machine this will allow your server not only to check
the ip (user
gateway or proxy) but also the MAC and the local IP associated with it
(could be the local IP of the user) and this info will also be
associated with the gateway IP (public IP of the user).
-----Original Message-----
From: Dawes, Rogan (ZA - Johannesburg) [mailto:rdawes () deloitte co za]
Sent: Thursday, July 24, 2003 7:34 AM
To: 'Phil Cox'; webappsec () securityfocus com
Subject: RE: How to protect against cookie stealing?
Well, there are only a limited number of things that one can do.
The objective is to detect a change when a request is made. What
information
can we check against?
* Source IP address - can change if behind a proxy server
array, doesn't
protect against other users behind the same proxy
* SSL sessionid - helps if you are using SSL, but this can
also change,
I
think. Particularly if the session is idle for a while?
What else? Here is a sample request:
POST http://localhost:8080/WebGoat/attack HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword,
application/x-shockwave-flash, */*
Referer: http://localhost:8080/WebGoat/attack
Accept-Language: en-za
Content-Type: application/x-www-form-urlencoded
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: localhost:8080
Content-Length: 0
Pragma: no-cache
Cookie: JSESSIONID=5971DC264B764275ED682A353BD3D44C
* Accept header - this is unlikely to change, but is easy to guess
* Accept-Language - most likely to be en-us, but could vary. Worth
adding,
anyway.
* UserAgent - one would have a reasonably good chance of
guessing this.
A
single incorrect guess should invalidate the session, although that
would
lead to DOS, perhaps.
I would be inclined to make up a validation string comprised of a hash
of
(Accept: + User-Agent: + Accept-Language:) at the time of the user's
login
and check that on every request. If it ever changes, immediately
invalidate
the session, and warn the real user when they make a request with the
correct string, that someone is trying to access their session.
One could also check against the source IP as a precaution,
and at least
flag sessions where the source IP changes as potentially being
compromised.
Quite what you would do with that, I'm not sure :-)
One flaw with this scheme, though: If the attacker manages to execute
some
script or other scheme to get the sessionid to their server,
they would
be
able to reap the headers as well :-(
Bang goes that theory. :-(
That brings us back to source IP and SSL sessionid.
IIRC, proxies are supposed to add an X-Forwarded-for header to the
request
headers. That could allow the server to track request that
occur across
different proxies. However, an attacker that does not go
through a proxy
would also be in a position to add such a spoofed header, and
they would
be
able to reap it from the request that delivered the sessionid. If they
were
behind a proxy, they could also add that header, but it might be
overwritten
by an upstream proxy?
One could, over time, build up a list of IP addresses of
known proxies,
and
source ranges that they serve. That could work, but would take time to
build
up.
Which leaves SSL sessionid. I'm not sure how reliable that is, and it
doesn't help non secure sites.
Which I think explains why no-one has done anything about
this problem!
:-)
Rogan
-----Original Message-----
From: Phil Cox [mailto:Phil.Cox () SystemExperts com]
Sent: 24 July 2003 07:34 AM
To: webappsec () securityfocus com
Subject: How to protect against cookie stealing?
All,
I have a question on how people are handling cookie stealing
and session
segregation. For example, it is possible to use session
cookie information
on multiple systems for most (all?) web applications I know
of. Here is a
scenario:
When a user logs in he is assigned a BLAH_SESSIONID cookie
which serves as
an authorization mechanism in the application. 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. If an attacker obtains, or guesses a valid
BLAH_SESSIONID cookie
for an active session, he can use it without the user's
knowledge. For
example, I was able to execute the following command using an
BLAH_SESSIONID
that was obtained from another session: Command on Linux box:
# curl -b "BLAH_SESSIONID=0000FDHTNLVY5WX"
https://somesite.com/App/Function?
Returns the page: (some portion of the returned page)
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. But
recently I have been told that this solution does not work
because of the
dynamic IP nature of MANY ISP's and the disassociation of
SSL/HTTP. I would
like to know what others are doing to solve this problem, or
if they are
just not solving it at all.
Thoughts and comments are appreciated...
Phil
Important Notice: This email is subject to important restrictions,
qualifications and disclaimers ("the Disclaimer") that must
be accessed
and read by clicking here or by copying and pasting the following
address into your Internet browser's address bar:
http://www.Deloitte.co.za/Disc.htm. The Disclaimer is deemed to form
part of the content of this email in terms of Section 11 of the
Electronic Communications and Transactions Act, 25 of 2002. If you
cannot access the Disclaimer, please obtain a copy thereof from us by
sending an email to ClientServiceCentre () Deloitte co za
Important Notice: This email is subject to important restrictions, qualifications and disclaimers ("the Disclaimer")
that must be accessed and read by clicking here or by copying and pasting the following address into your Internet
browser's address bar: http://www.Deloitte.co.za/Disc.htm. The Disclaimer is deemed to form part of the content of this
email in terms of Section 11 of the Electronic Communications and Transactions Act, 25 of 2002. If you cannot access
the Disclaimer, please obtain a copy thereof from us by sending an email to ClientServiceCentre () Deloitte co za
 By Date 
By Thread
Current thread:
- Re: How to protect against cookie stealing?, (continued)
|
Intro
