Accepts domain-level cookies even when using IP addresses

VERIFIED FIXED in mozilla0.9.5

Status

()

Core
Networking: Cookies
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: Si Ly, Assigned: Stephen P. Morse)

Tracking

Trunk
mozilla0.9.5
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
Mozilla accepts domain-level cookies even when using IP addresses.  For example,
a server at 209.178.101.140 can set a cookie for the domain ".101.140". This
cookie would then be shared by any server whose IP address matches *.*.101.140.
 Obviously, this can be a security and privacy issue.  See RFC 2109, section 8.3.

Test case:
1. Go to http://209.178.101.140/mozilla/domain-cookies.jsp
2. Quit Mozilla.
3. View your cookies.txt file.
4. Note that there's an entry for .101.140.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 1

17 years ago
Bug existed in 4.x as well.  Does it happen in IE?

Changing OS to all.
OS: Linux → All
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.5
(Assignee)

Comment 2

17 years ago
Created attachment 50086 [details] [diff] [review]
reject domain names that are IP addresses
(Assignee)

Comment 3

17 years ago
cc'ing alecf and sgehani for reviews

Comment 4

17 years ago
Comment on attachment 50086 [details] [diff] [review]
reject domain names that are IP addresses


This is fine and works, and gets sr=alecf, but wouldn't this have been easier:

> 
>   /*
>+   * test for domain name being an IP address (e.g., 105.217) and reject if so
>+   */
>+  for (int i = 0; i<domainLength; i++) {
>+    // stop as soon as we know it is not an IP address
>+    if (!nsCRT::IsAsciiDigit(domain[i]) && domain[i] != '.')
>+      return PR_FALSE;
>+  }
>+
>+  /*
>    * special case for domainName = .hostName
>    *    e.g., hostName = netscape.com
>    *          domainName = .netscape.com
Attachment #50086 - Flags: superreview+
(Assignee)

Comment 5

17 years ago
No, that won't work.  When we discover that it is not an IP address, that is 
good news.  Then we want to do other checks.  Your patch would consider a non-IP 
address as bad news.

Comment 6

17 years ago
Comment on attachment 50086 [details] [diff] [review]
reject domain names that are IP addresses

r=sgehani
Attachment #50086 - Flags: review+
(Reporter)

Comment 7

17 years ago
I don't think Mozilla should reject a cookie just beause it uses an IP address.
If the cookie uses a _complete_ IP address (4 octets), it should be okay because
the cookie wouldn't be shared with another server.
(Assignee)

Comment 8

17 years ago
Nobody ever said that we would reject cookies from sites that use IP addresses.  
What we will do is not allow such sites to set domain cookies.  And the 
justification for that is obvious -- there is no way to determine what 
that domain would be.
(Assignee)

Comment 9

17 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 10

17 years ago
Sorry, I didn't realize you were patching cookie_IsInDomain().
(Assignee)

Comment 11

17 years ago
So now the complaints are coming in that IP addresses can't set domain cookies.  
See bug 116489.
(Assignee)

Comment 12

17 years ago
Looks like this fix broke hotmail.com.  See bug 105917 for details.

Comment 13

16 years ago
I agree with comment #7 above and disagree with #8 in reply.

I have a several servers, one internet, many intranet, that I always address
using IP only.  The intranet has no DNS available not do I want one.

They have been setting and using domain cookies without problems for years.

The "risk" associated with IP only domain cookies is that a partial IP used as
domain is open to abuse but I can see no risk in allowing the use of the full IP
address.

Yes I know that IP addresses might change but that applies to a DNS domain also.

Please fix this "fix" so that we can all carry on doing this harmless and
effective thing.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 14

16 years ago
Please don't reopen this bug.  A fix went in for it on 9-20-2001 and that fix
indeed prevented the acceptance of domain-level cookies from IP addresses (which
is what the problem described in this report).  Unless that fix did not solve
the problem reported in this bug report, the report should not be reopened.

If you are arguing that we should accept domain cookies from IP addresses, then
that is another issue and should be opened in a separate bug report.  But such a
bug report would be invalid because a server in an IP address in not in a
domain, so how can you expect it to set domain cookies.  What you want it to do
is set a host cookie, and that it can and always could do.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago16 years ago
Resolution: --- → FIXED

Comment 15

16 years ago
Now I understand the true nature of the problem and I can live with it.

For the benefit of others:-

When the server sets a cookie, it can supply a parameter DOMAIN=domain but, if
this parameter is omitted, the cookie will be returned to this one specific host
only, identified by IP address.

This applies both to session cookies and long-lived ones.

Comment 16

16 years ago
verified - 09/05/02 trunk builds
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.