306519 - Duplicate cookies, changes to cookie rather than replacing cause it to be duplicated

Status: RESOLVED INVALID

(Core :: Networking: Cookies, defect)

Description

[vford]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

Similar to bug 223469

Creating a site using JBoss/Tomcat 4.0.2 that requires making changes to the
JSESSIONID cookie for failover and session management. Rather than replacing the
value a duplicate cookie is created. Worse yet the cookies can't be expired
either  properly either. It appears that all cookies are held regardless of
updates from the server until the session ends (closing the browser)

This poses major issues for site designers since there should only be one cookie
from the same domain, cookie path and ID. Most session cookies by sites are only
written once but this could pose a security issue, since when a user logs out of
a site the cookie should be deleted but in this case cookie isn't removed until
after the browser is closed. For most home users not a big issue but for those
working in other situations this could expose information.

Reproducible: Always

Steps to Reproduce:
1.go to a site that sets cookie
2.go to a jsp/servlet page that changes the cookie value
3.
Actual Results:  
Duplicate cookies created with the same ID.

Expected Results:  
One cookie updated.

Comment 1

[Daniel Veditz [:dveditz]]

This doesn't need to be security sensitive (but thanks for erring on the side of
caution).

This is not similar to bug 223469, this *is* bug 223469. Just as that was WFM so
will this unless you can provide more details on how to reproduce it. An example
site?

By specifying a jsp server app I assume you're talking about setting the cookies
using HTTP headers.

If you can't find a public site that exhibits this problem (I assume you're not
going to let us poke at the server you're building or you'd have given us the
address) please capture some logging data for us.

http://bclary.com/2004/04/10/web-site-qa#nspr
http://www.mozilla.org/projects/netlib/http/http-debugging.html

Probably logging just the cookie data might be enough to start, or cookie and
nsHttp:3

By any chance does your page set document.domain? that might be confusing
things... (It shouldn't, but I'd like to rule it out or explicitly check into it
if you're using it).

Comment 2

[Boris Zbarsky [:bzbarsky]]

Reporter, can you answer the questions in comment 1?

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I can reproduce this problem but the URL I cannot put here. Because it's not global web site(bugzilla).

I could see two cookies that names are same. But these third field name(caption?) on the cookie viewer on Fx1.6a were different that are 'domain' and 'host'.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: screenshot

Comment 5

[Boris Zbarsky [:bzbarsky]]

Er.. domain and host cookies are different things.  So what you see is correct.  If that's all there is to this bug, it's invalid.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #5)
> Er.. domain and host cookies are different things.  So what you see is correct.
>  If that's all there is to this bug, it's invalid.

But by this duplicated, the bugzilla cannot manage user log-in session. I deleted the cookie that has 'host', and I log-in to the bugzilla, another cookie that has 'domain' are overwritten to 'host' by the bugzilla...

Comment 7

[James Ross]

If you are having problems with a particular Bugzilla installation setting the wrong kind of cookies, please seek help with the configuration, or file a bug within the Bugzilla product providing the relevant configuration information and details on exactly what cookies are being set, etc..

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Umm... I don't have enough knowledge for cookie spec...
I'll check cookie spec and check netwerk/cookie code.
If I found bugzilla's bug, I'll report.

thanks,

Comment 9

[Boris Zbarsky [:bzbarsky]]

Well, this got confirmed for no reason, there's no response from reporter... Marking invalid until someone has some hard data actually showing a problem in Mozilla.