270045 - IE cookie import assumes domain cookies, leading to duplicates

Status: NEW

(Firefox :: Migration, defect)

Description

[Hanno Mueller]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0

We develop a community site that uses a cookie for auto-login. Let's call it
"usercookie".

We had several bug reports from users who switched from MSIE to Firefox and
couldn't login after that. As it turned out, Firefox sends us two values for
"usercookie" for these users.

The reason is that the Firefox installer imports cookies that MSIE stored for
the site "www.example.invalid" for the _domain_ ".www.example.invalid".

But our site still stores its session and login-cookie with
"www.example.invalid" and cannot remove the domain-cookie with the additional dot.

So now we have an invalid imported cookie that we cannot get rid of.

At the moment, we tell users to clear their cookies, this solves the problem.

Reproducible: Always
Steps to Reproduce:
1. Use MSIE on a site such as www.example.invalid that sets a cookie
2. Install Firefox
3. Import Cookies & Settings from MSIE
4. Check the cookie in Firefox - it will have a cookie for ".www.example.invalid"
5. Visit www.example.invalid again and let it set another cookie

Now you have two cookies. One for "www" and one for ".www". Firefox will sent
both for each request.


Expected Results:  
I don't know how MSIE stores its cookies. Somehow the Firefox installer should
be able to distinguish between site cookies and domain cookies.

Comment 1

[Hanno Mueller]

Here's a quick PHP hack script to demonstrate the problem. Mozilla and Firefox
both create two cookies and are able to tell them apart. But since the browser
doesn't tell the web server how these two cookies differ, a web application gets
two cookies with the same name, but different values.

Interestingly, MSIE is not able to identify the two different cookies and thinks
that a cookie for "www.example.invalid" is identical to a cookie for
".www.example.invalid".

So the question is wether this is a bug in the import function or not really a
bug in the way Mozilla handles cookies?


-------------------



<?

$c1 = $testcookie+1;
$c2 = $testcookie+2;

setcookie("testcookie", $c1, time() + 60*60*24, "", "");
setcookie("testcookie", $c2, time() + 60*60*24, "", ".$HTTP_HOST");

?>

Cookie-Test<p>

Read Cookies: <? echo $HTTP_COOKIE ?><p>

<p>
<ul>
<li>Set testcookie <? echo $c1; ?> for <? echo $HTTP_HOST ?></li>
<li>Set testcookie <? echo $c2; ?> for <? echo ".$HTTP_HOST" ?></li>
</ul>
</p>



<?

$c1 = $testcookie+1;
$c2 = $testcookie+2;

setcookie("testcookie", $c1, time() + 60*60*24, "", "");
setcookie("testcookie", $c2, time() + 60*60*24, "", ".$HTTP_HOST");

?>

Cookie-Test<p>

Read Cookies: <? echo $HTTP_COOKIE ?><p>

<p>
<ul>
<li>Set testcookie <? echo $c1; ?> for <? echo $HTTP_HOST ?></li>
<li>Set testcookie <? echo $c2; ?> for <? echo ".$HTTP_HOST" ?></li>
</ul>
</p>

Comment 2

[Hanno Mueller]

(In reply to comment #1)

(Sorry, I copied/pasted the PHP script twice.)

Comment 3

[Samuli Kärkkäinen]

I'm getting this also. Breaks our web app until the user removes the cookie
whose name is starting with a dot. Also on XP.

Comment 4

[Michiel van Leeuwen (email: mvl+moz@)]

(In reply to comment #1)
> So the question is wether this is a bug in the import function or not really a
> bug in the way Mozilla handles cookies?

More likely in the way msie handles cookies....

Comment 5

[Hanno Mueller]

(In reply to comment #4)
> More likely in the way msie handles cookies....

I don't know. IMHO, the RFCs (2109 and 2965) are far too vague on this issue.
And it seems that the members of the HTTP-State mailing list haven't made up
their mind, either. Frankly, I think that the MSIE style of handling this issue
is more logical, but then again, I have to admit that I didn't read the
technobabble of the cookie RFCs word by word yet.

Comment 6

[Hanno Mueller]

(In reply to comment #3)
> I'm getting this also. Breaks our web app until the user removes the cookie
> whose name is starting with a dot. Also on XP.

We "solved" this by removing a cookie ".domain.tld" before setting cookie
"domain.tld".

Comment 7

[Michiel van Leeuwen (email: mvl+moz@)]

from rfc 2109:
 To prevent possible security or privacy violations, a user agent rejects a
cookie (shall not store its information) if any of the following is true:
   * The value for the Domain attribute contains no embedded dots or
     does not start with a dot.

I don't consider that vague. It is a bug that IE accepts domain=foo.com. And
mozilla copied that bug, in order not to break a lot of sites.

the other question is if the cookie was really set for domain=foo.com, or just
for no specific domain. Because that is actually how you would set a host cookie.
from the rfc:
 Domain Defaults to the request-host. (Note that there is no dot at the
beginning of request-host.)

Comment 8

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 9

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 10

[Peter Tolmachov]

If cookie is imported from IE to FF it should be converted from
format that IE uses to store cookies into format that FF uses to store 

cookies
to avoid having two 'same' cookies that contain different values.
If Firefox cannot interpret and deal with IE cookie or 'thinks' it is 

buggy or it has improper format etc. it shouldn't import such cookie at 

all!
Anyway current implementation of FF cookie import is unacceptable. 
The only benefit I see from it is that developers need to write some 

quirky
workarounds to remove such a 'buggy' imported cookie which is described 

in 
comment #6.
Please have a look at bug 316532 as well.

Comment 11

[Daniel Veditz [:dveditz]]

*** Bug 316532 has been marked as a duplicate of this bug. ***

Comment 12

[Daniel Veditz [:dveditz]]

This really happens, confirming. We may WONTFIX it, but that should be an explicit decision to close the bug. "expired" is wrong for this issue.

Comment 13

[[e-mail]]

IE interprets all cookies as domain cookies, while we make a distinction between host and domain cookies (rightly so!). when importing, we thus interpret them as domain cookies, leading to duplicates.

i can't see any good fix here, and i don't think we want to stop importing IE cookies. which leaves us with hacks. perhaps we could cobble together a few prefixes that look like they should be hosts rather than domains, and test for them during import... e.g. "www.", "ww.", etc? perhaps we could even use the etld service to say any URL with more levels than the base domain is a host?

Comment 14

[Steve Leroux]

We ran into this duplicate cookie problem as well.  We are setting and reading cookies via javascript, and to work around the problem we explicitly erase the given cookie for both domain and host before updating with a new value:

// code originally from quirksmode.org
function eraseCookie(name) {
	_createCookie(name,"",-1);
	_createCookie(name,"",-1,"." + document.domain);
}

function _createCookie(name,value,days,domain) {
	if (days) {
		var date = new Date();
		date.setTime(date.getTime()+(days*24*60*60*1000));
		var expires = "; expires="+date.toGMTString();
	}
	else var expires = "";	
	document.cookie = name+"="+value+expires+"; path=/" + (domain ? ";domain=" + domain : "");
}