469287 - Cookies security problem: same domain but different ports

Status: RESOLVED WONTFIX

(Core :: Networking: Cookies, defect)

Description

[Mike]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081211 Minefield/3.2a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081211 Minefield/3.2a1pre

It might be a security problem. I have two web services on one domain.
First one on standard http port 80, doesn't require login.
Second one on different port(say, 1234) and require login which set cookie.

I've logged in to port 1234, then open page from port 80 - and Firefox send cookie (in HTTP request) from login for port 1234!

Reproducible: Always

Steps to Reproduce:
1. set up 2 web services on one domain (example.com), on different ports; one with login (port 1234), other without (port 80)
2. login to http://example.com:1234/
3. open http://example.com/
Actual Results:  
HTTP request looks like:
GET / HTTP/1.0
Host: example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081211 Minefield/3.2a1pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate
Accept-Charset: UTF-8,*
Cookie: LOGIN=<cookie_string_here!>
Connection: keep-alive

Expected Results:  
Cookie must not be sent to wrong port

Comment 1

[Benjamin Smedberg]

Hrm... I know sometimes we share cookies between http: and https:... but I thought in general we treated different port numbers as entirely different domains.

What is the Set-Cookie header which actually set the cookie?

Comment 2

[[e-mail]]

we don't store or care about port numbers with cookies at all, this is a historical thing that we've done for a long, long time.

i don't remember the reasons right now, but i'm guessing it's because IE does it too. is this the case?

Comment 4

[Daniel Veditz [:dveditz]]

Or IE does it because Netscape did originally. Cookies were added before the "host-port-scheme" same-origin policy really jelled as a concept and end up with different behaviors. For instance cookies try to be more strict by limiting cookies to particular paths by default (although allowing the option to share with the entire site), but because the same-origin policy lets any page communicate with/manipulate any other on the same host you can easily get around the cookie path restriction. But then in the case of port and schemes cookies are way more relaxed than the same-origin policy.

And this does regularly get exploited, particularly in the leakage of secure cookies to insecure versions of a site, where the insecure pages could be sniffed on a compromised network such as a wifi hotspot.

Comment 5

[Mike]

(In reply to comment #1)
> What is the Set-Cookie header which actually set the cookie?
Set-Cookie: LOGIN=<cookie_string_here>; Path=/; Version=1\r\n

I've tested various browsers:
IE8 beta2       - fail
Opera 9.60      - fail
Safari 3.1.2    - fail
Konqueror 4.1.3 - pass, it store port number as part of cookie-domain

RFC2109 mentioned in dupes is dated February 1997, quite old for modern security needs. Maybe this issue should be revised?

Comment 6

[[e-mail]]

certainly not for cookies as they exist now, but anything's possible for a future spec.

-> WONTFIX since there's nothing here that hasn't been known and deliberately implemented for a long time