net/http/cookiejar: Domain matching against IP address

[sebcat]

Hello,

The following test fails:

package foo 

import (
    "net/http"
    "net/http/cookiejar"
    "net/url"
    "testing"
)

func TestIPDomain(t *testing.T) {
    u, err := url.Parse("http://127.0.0.1/")
    if err != nil {
        t.Fatal(err)
    }   

    jar, err := cookiejar.New(nil)
    if err != nil {
        t.Fatal(err)
    }   

    c := &http.Cookie{Name: "foo", Value: "bar", Domain: "127.0.0.1"}
    jar.SetCookies(u, []*http.Cookie{c})
    cs := jar.Cookies(u)
    if len(cs) != 1 { 
        t.Fatalf("Got %v cookies, expected 1\n", len(cs))
    } else if cs[0].Name != "foo" || cs[0].Value != "bar" {
        t.Fatal("Invalid cookie name/value")
    }   
}

Further inspection shows that it fails with errNoHostname here:

go/src/net/http/cookiejar/jar.go

Lines 447 to 452 in 7f0be1f

	if isIP(host) {
	// According to RFC 6265 domain-matching includes not being
	// an IP address.
	// TODO: This might be relaxed as in common browsers.
	return "", false, errNoHostname
	}

I believe the comment refers to RFC6265 5.1.3. It states that the domain string must either be identical with the string it's matched against, OR that all of the three subsequently listed conditions are met, one of which are that the string being matched must be a host name.

In the case of the matched string being an IP address and the domain string being the same IP address, the first condition is met. I therefor believe that L447-L452 should be removed.

[vdobler]

The situation is not really simple: RFC 6265 is not clear whether to allow or deny
domain cookies on IP addresses and browsers handle this case differently.
That was the reason for the TODO in line 450 [1] of the cookiejar implementation.
I have the impression that half a decade ago domain cookies on IP addresses
where commonly accepted, sometimes just to match the behavior of Internet Explorer
(see e.g. [2] [3] [4] [10]).

The current implementation in Chromium rejects domain cookies in IP addresses
[5] lines 457-477. If I my understanding of the Mozilla code [6] is correct then
Firefox silently converts a domain cookie for an IP address to a host cookie.
(I have not done tests on any browsers recently.)

My gut feeling is that cookies with an IP address as the domain-attribute should be
either rejected (an IP address is not a domain) or be converted to host cookie (i.e.
pretending the domain-attribute was not set, a forgivable user error).

RFC 6265 is not really clear here. I read the following

The string is a host name (i.e., not an IP address).

RFC 6265 section 5.1.3, second bullet, third star [7] as a definition of host name in
the sense of: "a host name is not an IP address".

Therefore my understanding of the algorithm to produce a canonicalized host name

Convert the host name to a sequence of individual domain name labels.

RFC 6265 section 5.1.2 step 1 [8] is that an IP address does not qualify as a
canonicalized host name.
As an IP address is not a canonicalized host name I think that RFC 6265 section 5.3
step 6 first case [9] applies:

If the canonicalized request-host does not domain-match the domain-attribute:
Ignore the cookie entirely and abort these steps.

and the cookie should be dropped as it is done currently.

[1]

go/src/net/http/cookiejar/jar.go

Lines 447 to 452 in 7f0be1f

	if isIP(host) {
	// According to RFC 6265 domain-matching includes not being
	// an IP address.
	// TODO: This might be relaxed as in common browsers.
	return "", false, errNoHostname
	}

[2] https://code.google.com/p/chromium/issues/detail?id=3699
[3] https://codereview.chromium.org/18657/diff/1/net/base/cookie_monster_unittest.cc
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=125344
[5] http://src.chromium.org/viewvc/chrome/trunk/src/net/cookies/cookie_store_unittest.h
[6] https://hg.mozilla.org/mozilla-central/file/3e8dde8f8c17/netwerk/cookie/nsCookieService.cpp#l3502

[7] http://tools.ietf.org/html/rfc6265#section-5.1.3
[8] http://tools.ietf.org/html/rfc6265#section-5.1.2
[9] http://tools.ietf.org/html/rfc6265#section-5.3
[10] https://bugzilla.mozilla.org/show_bug.cgi?id=125344

[sebcat]

The Chromium test case you linked as [5] shows that Chromium allows a cookie to be set with a domain attribute if that attribute is an exact match (L470-L472 in the same file).

RFC 6265 is not really clear here. I read the following

The string is a host name (i.e., not an IP address).

RFC 6265 section 5.1.3, second bullet, third star [7] as a definition of host name in
the sense of: "a host name is not an IP address".

The third star is so that suffix matching is only applied on host names. 5.1.3 also states that if the two strings matches each other exactly, they domain-match.

Regarding RFC6265 5.3:

If the canonicalized request-host does not domain-match the domain-attribute:
Ignore the cookie entirely and abort these steps.

If I visit the URL http://127.0.0.1/ in my browser, it is my understanding that "the canonicalized request-host" is "127.0.0.1". If the domain-attribute in the Set-Cookie header is set to 127.0.0.1, the canonicalized request-host domain-matches the domain-attribute under the rules of 5.1.3 (exact match).

[vdobler]

The comment in the Chromium test case is interesting: "This matches IE/Firefox, even though it seems a bit wrong." Maybe that behaviour is wrong.

One more from the Chromium test case: Chromium treats domain=.1.2.3.4 as an illegal domain attribute. But if you follow RFC 6265 (as package cookiejar tries to) you would chop off the leading trail first (see 5.3.2), even before domain matching it. Chromiums behaviour here is not RFC 6265 compliant no matter if RFC 6265 allows domain cookies on IP addresses or not.

As I said RFC 6265 is not clear here.

I think silently converting the domain cookie to a host cookie is okay, but I do not think that domain cookies on IP addresses make sense at all.

Would you have time to test the behaviour on Chrome, FF, IE, Safari and curl? I thinks showing that all these "browsers" handle domain attributes equal to the request IP address the same would add considerable weight to the proposed change.

[sebcat]

For the following web service:

package main

import (
    "net/http"
    "log"
)

func CookieHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Set-Cookie", "foo=bar; domain=127.0.0.1")
    w.Write([]byte("foo"))
}

func main() {
    http.HandleFunc("/", CookieHandler)
    log.Fatal(http.ListenAndServe(":8080", nil))
}

curl 7.40.0
Google Chrome 47.0.2503.0 dev
Mozilla Firefox 40.0.3

sets the cookie "foo" for 127.0.0.1

I will be able to test IE, Safari in the beginning of next week.

[sebcat]

Safari 9.0 (11601.1.56)
IE 10.0.9200.17492 (Update version 10.0.31, Windows 2012 Server) *

sets the cookie "foo" for 127.0.0.1 for the previously mentioned test case.

*: Added Expires attribute to make sure a persistent cookie file was created in "Temporary Internet Files".

[dcormier]

This certainly makes it challenging to use httptest.Server and try to set cookies with the Domain attribute set to the httptest.Server's address.

[jongiddy]

Having spent some time working out why a Go test behaved differently to a browser test, I ended up at this discussion. Even after following the referenced links, I find the argument for the current behavior to be unconvincing.

RFC 6265 section 5.1.3 states that there is a match if "the domain string and the string are identical". The only way to make this exclude IP addresses is to infer a definition of the term "string" to mean "host name (i.e., not an IP address)". But if "string" is defined this way for the entire section, then why would the RFC need these exact words as a requirement of the alternative branch? It would be tautological.

Combined with the other evidence that browsers do support exact matches on IP addresses (the Chromium tests, Firefox code, and the last comment by @sebcat), my opinion is that this should be fixed in the Go library.

[jayateertha043]

Please Golang allow ip address, domain setting cookie in next release .I had to comment out this whole part:

go/src/net/http/cookiejar/jar.go

Lines 447 to 452 in 7f0be1f

	if isIP(host) {
	// According to RFC 6265 domain-matching includes not being
	// an IP address.
	// TODO: This might be relaxed as in common browsers.
	return "", false, errNoHostname
	}

to make my code run.

Most of the browsers allow ip address for cookie setting, kindly try to relax that behaviour or atleast mention that somewhere,It took me nearly 1 day to figure out what was going bad.

https://stackoverflow.com/questions/67872836/use-cookies-txt-as-cookies-jar-client-side-in-golang?noredirect=1#comment119971669_67872836

[vdobler]

@jayateertha043

You seem to imply that domain-cookies should unconditional be setable on IP addresses if the cookie's domain-attribute is an IP address and equal to the host which also must be an IP address?

Do you consider such cookies domain- or host-cookies?

You mention "Most of the browsers allow ip address for cookie setting". Could you provide evidence of the details, especially:

• What if only one of the cookie-domain-attribute and the host is an IP address but the IP address ist that of the domain name on the other? What do browsers do in such cases? Do all browsers behave the same way?
• Do browsers treat such cookies a domain-cookies or host-cookies? Does this matter? Do all browsers behave the same?
• On which requests do browsers return cookies set with an IP address as the domain-attribute? Only tho the IP address? Or also to the domain name resolving tho this IP?
• Are there any security considerations to take care of? If not: Why is the behaviour unproblematic?

[jongiddy]

Do you consider such cookies domain- or host-cookies?

• Do browsers treat such cookies a domain-cookies or host-cookies? Does this matter? Do all browsers behave the same?

It turns out that it doesn't matter - for IP addresses, host and domain cookies are the same.

RFC 6265 Sec 2.3 says:

The request-host is the name of the host, as known by the user agent,
to which the user agent is sending an HTTP request or from which it
is receiving an HTTP response (i.e., the name of the host to which it
sent the corresponding HTTP request)."

This does not appear to exclude IP addresses, since a HTTP request can be sent to an IP address and the IP address would be the only name known by the user agent. This section also refers to request-uri from https://datatracker.ietf.org/doc/html/rfc2616#section-5.1.2 which, via https://datatracker.ietf.org/doc/html/rfc2396, ultimately defines its host component as hostname | IPv4address.

https://datatracker.ietf.org/doc/html/rfc6265#section-5.1.2 defines a "canonicalized host name" and refers to domain name RFC's. So although it is not definitive, we could probably say that this refers to a domain name, and specifically not an IP address. This is backed up by section 5.1.3 which says "The string is a host name (i.e., not an IP address)"

So in RFC 6265 "request-host" includes IP addresses and "host name" does not.

When considering Host cookies (cookies without a Domain attribute):

• 5.3(4) sets the domain-attribute to an empty string
• 5.3(6) sets the host-only-flag to true and the domain to the canonicalized request-host.

The phrase "canonicalized request-host" isn't defined, but it is a "request-host" and not just a "host name". The most sensible way to interpret it is as a request-host that has been canonicalized if it is a host name.

So we get a cookie with host-only-flag=true and domain=canonicalized request-host (in this case an IP address).

When we come to send the cookie Sec 5.4(1) says, since the host-only-flag is true, we send the cookie when the canonicalized request-host is identical to the cookie's domain (when sending to the same IP address).

When considering a Domain cookie (cookie with a Domain attribute) returned from an IP address, running through the same sections, since the second part of sec 5.1.3 is inoperable if the request-host is an IP address, the cookie is ignored unless the cookie domain is identical to the request-host, both for the receiving and sending of the cookie. So a cookie from an IP address with the domain set to the IP address is equivalent to an IP address host cookie.

• What if only one of the cookie-domain-attribute and the host is an IP address but the IP address ist that of the domain name on the other? What do browsers do in such cases? Do all browsers behave the same way?
• On which requests do browsers return cookies set with an IP address as the domain-attribute? Only tho the IP address? Or also to the domain name resolving tho this IP?

Domain name resolution does not occur for cookie management. This is also true for domain names: https://stackoverflow.com/questions/10020987/cname-and-cookies

• Are there any security considerations to take care of? If not: Why is the behaviour unproblematic?

The security considerations appear to be the same as those for domain names. e.g. there are potential problems if you use a request-host that reaches a different host on different networks. But the lack of true domain cookies for IP addresses eliminates one class of problems: accidentally giving access to an untrusted subdomain.