422353 - fix allowed schemes and innermost URI usage in cookies

Status: NEW

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

Description

[[e-mail]]

spun off from bug 421494 comment 20:

1) currently just block ftp, we should have a whitelist instead. i think http, https, and possibly file are sufficient. can anyone think of others? not sure if we even want file, i've heard it's useful for webdevs, but they usually have an empty domain and that scares me.

2) should we be using NS_GetInnermostURI() on the host URI or originating URI? what exactly would a nested URI mean, in the context of cookies - i don't know enough about their uses to answer this. i suspect we don't want them, so perhaps we should enforce this.

3) when comparing the domains of the host and originating URIs in nsCookieService::IsForeign(), perhaps we should also enforce same scheme (http/https is trivial, i'm worried about file).

Comment 1

[Tony Mechelynck [:tonymec]]

If you're worried about file, maybe you can set special rules for it? Such as setting the domain internally to "localhost" for all file URLs, at least if typed with an empty host, so that a cookie set by a file:/// URL will only be sent back to a file: URL and not (let's say) to an http: URL? Anyway, IIUC, "file:///" is equivalent to "file://localhost/" isn't it?

Comment 2

[[e-mail]]

as far as i can guess, yes, though i'm not sure about that on all plats.

the file:// case is somewhat special, because (perhaps non-intuitively) it can have any domain... e.g. "file:///foo.html" will load the same file as "file://bugzilla.mozilla.org/foo.html". which means file:// URI's can access cookies from any domain. (this came up in bug 109982, which was WONTFIXed with the argument that local html files can pwn you anyway; see also bug 209964 and bug 165334.)

the argument for allowing it is for ease-of-testing (if we blocked it, users would have to set up a local http server instead). IE allows them while Safari blocks them. what i'm concerned about here is that it can pollute the cookie host space with things that shouldn't be accessible cross-scheme, even though this wasn't deemed to be a big problem, given the other exploits possible in such a situation.

so, while i'd like to block it and be done, it's probably best to a) allow it as-is or b) tweak the host to "localhost" to at least make it predictable. (this would allow sharing between file://localhost and http://localhost, but that's probably fine.) i don't think it's worth storing scheme in the cookie file over this, especially if we're going to whitelist only http, https, and file.

Comment 3

[[e-mail]]

Reassigning to nobody. If anyone wants to work on this, feel free!

Comment 4

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 5

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 6

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.