- From: Dave Kristol <dmk@allegra.att.com>
- Date: Tue, 23 Apr 96 15:32:01 EDT
- To: koen@win.tue.nl
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
koen@win.tue.nl (Koen Holtman) wrote: > > > >The latest draft of the cookie spec. is at > > http://www.research.att.com/~dmk/cookie.html > > Only two comments: > > > #4.3.5 Sending Cookies in Unverifiable Transactions Users must have | > #control over sessions in order to insure privacy. > ^^^^^^ > > Shouldn't this be `assure'? Well, maybe "ensure". > > > #8.2 Cookie Spoofing > # > [...] > #Note that a server at cracker.edu could send a cookie to the client and | > #subsequently get both of the cookies in the preceding example as well as | > #its own. > > I was confused by this, and after re-reading it twice, I think this is > wrong. I believe this should be: > > Note that a server called cracker.edu could send a cookie to the > client without an explicit domain, and subsequently get the second > cookie in the preceding example as well as its own. No. Actually, the whole passage must be dropped. I put it in when Ted Hardie observed the problem as stated. But we've fixed the problem by requiring explicit leading dots in Domain=. If a server at cracker.edu sent a cookie to the client, it would only get back its own cookie. It could only set Domain=cracker.edu, which is also the default Domain. (Domain=.cracker.edu would not domain-match the host name (cracker.edu), and the cookie would be discarded.) Since cookies with domains victim.cracker.edu and .cracker.edu do not domain-match "cracker.edu", neither cookie in the example would get send to the bad guy. Dave
Received on Tuesday, 23 April 1996 12:48:20 UTC