256038 - cookies are accepted with another domain than the webserver's

Status: RESOLVED EXPIRED

(Core :: Networking: Cookies, defect)

Description

[Attila ZIMLER]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040619
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040619

I have two network interface in my computer.
The network interfaces resolves to different ips and hostnames are not even in
the same zone.
contacting the webserver on my computer with the first name it is allowed to set
a cookie for the second.

page cannot set cookie with an external name like www.microsoft.com

This can also be reproduced with nightly build donwloaded on 2004 aug 18

The page setting the cookie sent this header (captured with livehttpheaders)
hlfs.dyndns.org is the name second ip, the server is contacted on bluestar.space

POST /vese/index.cgi/ HTTP/1.1
Host: hlfs.dyndns.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040818
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://bluestar/vese/index.cgi?act=2001
Content-Type: application/x-www-form-urlencoded
Content-Length: 12
usr=t&pass=p
HTTP/1.x 200 OK
Date: Wed, 18 Aug 2004 18:22:17 GMT
Server: Apache/2.0.48 (Unix) mod_ssl/2.0.48 OpenSSL/0.9.7d DAV/2 PHP/4.3.5
Set-Cookie: sid=AiQNkupyrR7vJvvgjGDxuA; domain=hlfs.dyndns.org; path=/;
expires=Wed, 18-Aug-2004 18:52:17 GMT
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-2
----------------------------------------------------------


The case can be reproduced with switched names (contacting on hlfs.dyndns.org
and placing a cookie on bluestar.space)

Internet Explorer also store cookies like the described.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Andrew Schultz]

cookies

Comment 2

[Attila ZIMLER]

I was told to mention my cookie settings too, but I forgot it.
Here it is:
Cookie Acceptance Policy: Allow cookies based on privacy settings (level of
privacy is medium)
Cookie Lifetime Policy: Accept cookies normally

Comment 3

[Mike Connor [:mconnor]]

please create a cookie log as described in
http://www.mozilla.org/projects/netlib/cookies/cookie-log.html and attach it
here (as an attachment please, not inline)

Comment 4

[Attila ZIMLER]

I followed the steps described in the html reference for creating the cookies
log file, but I only ended up with an empty logfile. (Tried more times because I
thought it was my mistake.)

Before the test I removed the old cookie which was placed by the web page, and
after the test the cookie was placed again.

Is it normal that I got only an empty file?

Comment 5

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

> POST /vese/index.cgi/ HTTP/1.1
> Host: hlfs.dyndns.org

> HTTP/1.x 200 OK
> Set-Cookie: sid=AiQNkupyrR7vJvvgjGDxuA; domain=hlfs.dyndns.org; path=/;

I don't see the problem here. You visit hlfs.dyndns.org, and the cookie is for
the same domain name. No other domains involved. (other then in the referer. Ar
you sure the links in your site are correct?)

Comment 6

[Attila ZIMLER]

I generated a live http headers log for the other case. Seems that in that case
too server introduces itself in the name of the outside ip - hlfs.dyndns.org.

Ok, if these too is equal why cookie is not sent back if the server is referred
by the inner (bluestar.space) name? (Should be if storage is allowed by either
name, should not?)

Comment 7

[Attila ZIMLER]

I had an idea for further testing and it seems that the issue was only related
to that url location displayed in location bar and server name was missed.

If reproducing my firstly included http header the location shown in url bar is
http://bluestar.space/vese/.

Is that an error?

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.