165334 - Compare scheme when setting and sending cookies

Status: RESOLVED WONTFIX

(Core :: Networking: Cookies, defect, P3)

Description

[Mitchell Stoltz (not reading bugmail)]

I'm opening this bug to get some discussion on this issue, which we have
discussed informally in the past few weeks. Please don't mark the bug invalid
out of hand; let's talk it out first. The DOM security manager (CAPS) compares
scheme, host, and port when making security decisions. The cookie module
compares only host, and sometimes the port. Comparing scheme, host, and port on
cookies would make these two security policies equivalend and will probably make
us safer, though it may break some sites. I'd like to try this and see what happens.

I realize there will be backward-compatibility issues with existing cookies.txt
files, but I blieve these issues can be overcome.

The issue, as discussed in bug 90644, is that multiple servers running different
protocols and/or on different ports can currently share cookies. While a good
host configuration can avoid possible security problems caused by this setup, we
can give site creators a hand by treating different protocols and ports as
different hosts. Of course, we can make specific exceptions, such as treating
http and https on default ports as equivalent. Please don't treat this proposal
as monolithic - pick it apart and let me know what will work.

Comment 1

[Stephen P. Morse]

See also the discussion in bug 142803

Comment 2

[Daniel Veditz [:dveditz]]

Making this queryable as security-related

Comment 3

[Stephen P. Morse]

Oops, I forgot about this bug.  I just checked in the patch in bug 142803 based
on the recent discussion in that report.  That bug is the opposite of this bug
as far as the ports go.

The discussion in bug 142803 clearly indicated that we were violating the
RFC2109 spec by testing for port.  Furthermore, IE does not test for port, so we
would be breaking websites unless we removed the port test.  It is for these two
reasons that I finally decided to check in the patch in 142803.

Comment 4

[Stephen P. Morse]

I suggest we change the summary of this bug to talk about scheme only.  The
ports issue should be left to bug 142803.

Removing "and port" from summary.

Comment 5

[Daniel Veditz [:dveditz]]

Bug 142803 was about the spec for http/https. If we want to use port for other
schemes, or not allow cookies at all as was recently done for FTP, that's
completely our call.

I personally think we should support cookies in all schemes, but fix this bug so
we can unblock FTP cookies. I'd still consider comparing ports for non-HTTP(s)
schemes, it's quite possible servers on different ports could be owned by
different entities (example: small sites who buy hosting from some ISP). This
applies especially to HTTP sites, but the spec and web practice has enshrined
unhelpful behavior so we can't undo the 142803 fix.

Comment 6

[benc]

Unless an RFC says to equivocate, I think we should assume the various schemes
are different. 

Comment 7

[benc]

This is probably the best place to ask, what is the current expected behavior?

Setting cookies: file, gopher, http, https -> yes. ftp -> no (where the bug?)

Sharing between protocols: yes.

Comment 8

[benc]

->defaults.

I'm getting back to more cookies issues and docs, and this is an important
aspect of the design I want to get clarified.

Comment 9

[[e-mail]]

-> default owner

Comment 10

[Patrick McManus [:mcmanus]]

dan, unsure of the current state of things. Should this be closed or marked for development?

Comment 11

[Daniel Veditz [:dveditz]]

The underlying problem is still there (boy is it), but we're even less likely to be able to pull off this kind of major change without breaking things. We might be able to play games around the edges like "for an HSTS origin ignore any non-secure domain cookies".

As much as it would be nice to do this, if we couldn't do it a decade ago because of bustage it hasn't really gotten much better. I'd say WONTFIX this one and then look at the incremental improvement proposals from Mike West in new bugs (https://lists.w3.org/Archives/Public/public-webappsec/2015Nov/0069.html).

Comment 12

[Patrick McManus [:mcmanus]]

i agree