the fix for bug 161228 possibly re-introduced the princeton-style exploit for cookies. mitch, dveditz and i discussed this issue before choosing to go ahead with the fix for bug 161228, which was a regression resulting from the original princeton attack fix (bug 149943). basically, the problem is that our DNS table now maps host:port -> ipaddress instead of host -> ipaddress. see bug 161228 for a description of why this was necessary. as a result, we may connect to a different ip node depending on the desired port. this is expected, but since the cookies security model is based solely on the hostname (not including the port), we could potentially be sharing cookies between different ip nodes. one of the nodes might be a page with sensitive content and the other might be an attackers webserver. there are a few things about cookies that we might be able to leverage to fix or at least diminish this sort of attack. 1) the Set-Cookie header may include a domain= value which can be used to verify that the requesting hostname matches the specified domain name. this would prevent www.evil.com:4444 from seeing the cookies set by www.evil.com:80, in the case that www.evil.com:80 actually mapped to www.amazon.com, for example. i haven't looked to see exactly what we do with the domain= parameter... morse? 2) the Set-Cookie header may also specify that the cookie is secure. for secure cookies, we might want to consider restricting the cookie to only the originating server (e.g., must match protocol://host:port). mitch suggested that this probably would break some sites, but it might still be reasonable.
Unles I'm misunderstanding this, there is no problem because currently the port is stored along with the hostname and is used by the cookie module when making tests. There is of course bug 142803 in which I claim that we shouldn't be testing ports because it is violation of the cookie spec. But I was concerned about making such a radical change and probably breaking a few sites. Based on what you are saying here, there is even more reason not to fix bug 142803.
my cookies.txt file does not mention any port numbers... so how is the cookie module able to compare ports?
or, is it that we assume port 80 when none is specified?
If a port is specified, it will be included with the host name in the cookies.txt file. If none is specified, there will be none in the cookies.txt file.
does the cookie service use the protocol's default port if none is explicitly specified in the URL string?
The cookie service doesn't "use" ports. It simply records them and tests for them, and it records just what it is given. That is, if it is not given a port, it doesn't record any port. It's the network layer that would "use" the port, and it would decide to use a default port if none is specified.
the cookie service takes nsIURI's as input and decides what to extract from the URL in order to determine what to record to its database. from a quick glance at my cookies.txt, it is apparent that the cookie service is not storing the port along with the hostname in all cases. that has nothing to do with networking other than perhaps the fact that cookies is leveraging networking URL parsing routines to access fields in the URL. if we determine that we should be storing host:port in all cases, then the cookie service needs to take due diligence to ensure that host:port is written out to cookies.txt in all cases. given that cookies does not store the port in all cases, we have to consider the possibility of a potential princeton like exploit. morse: can you address my original two comments? do we check the domain= value included in Set-Cookie headers against the hostname of the URL? thx!
In a private e-mail from darin he reported: actually, i tried setting this up, and the exploit wasn't possible. it turns out that cookies will in fact compare www.evil.com to www.evil.com:4444 before attempting to share cookies. now, i wonder what would happen if i were instead running a HTTPS server at https://www.evil.com:443/ ... could i then steal cookies? because the protocol scheme is not recorded in the cookies database, right? Sounds like what I said in comment 1 and comment 4. Closing out as invalid
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
steve: no i don't think this should be marked INVALID yet. we haven't ruled out the possibility of stealing cookies from a HTTPS site using a HTTP site. e.g., https://www.evil.com/ and http://www.evil.com/ can see each others cookies. given that these may each resolve to different IP addresses, there is the possibility of a princeton like attack. i just haven't had the time yet to setup a testcase.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
after some more thought... 1) it would be impossible for a DNS server to make www.evil.com point at the ip-address of another domain's HTTPS server. that sort of thing is prevented by SSL. 2) that means that an attackers DNS server would only be able to steal cookies from a HTTP site using a HTTPS server under its own control. case 2 is not very interesting, and probably doesn't correspond to any kind of real security threat. so, i'm going to mark this bug INVALID.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago → 16 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.