[3749] in WWW Security List Archive
Re: Cookie question
daemon@ATHENA.MIT.EDU (Robert P Cunningham)
Mon Dec 9 03:48:17 1996
Date: Sun, 8 Dec 96 20:39 WET
From: bob@lava.net (Robert P Cunningham)
To: darren@factcomm.co.jp, www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
>Server B: stores a cookie on client A's machine, with name and password, to
>save the user having to type his name and password in each time (*).
>
>Server C: first pretends to be server B, and gets the cookie from client A.
>It then pretends to be client A, and logs on to server B.
Server C would have to be in the same domain as Server B in order
to retrieve the cookie, even if Server B was sloppy about the domain
it assigned to the cookie. If Server B is careful, then they only
way Server C could get a copy of the cookie is have the same full
domain name as Server B (i.e., Server C would have to be the same
machine as Server B). See "tail matching" in:
http://home.netscape.com/newsref/std/cookie_spec.html
But in general, it's a poor idea for sites which charge use cookies
to store name/password combinations in cookies, because:
1. Though the attack you describe isn't feasible, a variety
of other attacks, ranging from simple sniffing to complex
DNS spoofing of Server B, certainly are feasible. So, the
cookie could be stolen.
2. The user's browser could flush the cookie under any of
a variety of circumstances, leaving the user without
authorization to use Server B. For example, a user might
accidentally browse a "cookie cutter" site (which replaces
all existing cookies the browser holds with a collection
of its own cookies).
>but I suppose a nasty server could send a 1Gb cookie if it wanted?).
It might send it, but no browser will accept it, nor should they.
Cookies are limited to 4KBytes. All that, and more is explained
in detail at
http://home.netscape.com/newsref/std/cookie_spec.html
