270710 - nsICookieService::setCookieString does not conform with RFC 2109, and RFC 2068

Status: RESOLVED WONTFIX

(Core :: Networking: Cookies, defect)

Description

[Michael (GoodWill)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

When used from XPCOM directly nsICookieService::setCookieString allows addition
of bugs with no name, with no value, with spaces in the values with ;
delimiters, ant etc.

after reviewing RFC 2109, and RFC 2068 it appears that it does not at all
conform with standards.

Reproducible: Always
Steps to Reproduce:
var uri =
Components.classes["@mozilla.org/network/standard-url;1"].createInstance(Components.interfaces.nsIURI);
var cservice =
Components.classes["@mozilla.org/cookieService;1"].getService().QueryInterface(Components.interfaces.nsICookieService);
uri.spec: = 'http://foobar.com/';
var cookieString ="cookie name with spaces in it=;expires=Sat Nov 19 2016
16:13:03 GMT-0800 (Pacific Standard Time);path=;"
var rv = cservice.setCookieString(uri, null, cookieString, null );

Actual Results:  
The cookie was added with no problem errors. It had empty spaces in its name and
no value.

Expected Results:  
An error should have been returned an no cookie set because the cookie has no value.
An error should have returned about name containing illegal characters or thos
characters whould have at leas been escaped.

RFC Standard: 
http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc2109.html

Potential implicatins:
According to bz document.cookie uses this method.
This may cause data corruption at least and maybe some security problems.

Comment 1

[Daniel Veditz [:dveditz] (OOO: back Aug 26)]

Several important things to note:
1) if you accurately implement the cookie rfc you break important sites on the
web. There's what the spec says, and there's the common implementation that
evolved with Netscape and IE and the two don't always match. I don't know that
this is such a case, just want to make sure that's understood.

2) The RFC does not cover an internal mozilla API, the API covers what gets sent
over the net. Are cookies getting sent out in a broken standard?

Of course if the API can be used to break cookie storage that would be a
problem, but you're only speculating whether that can happen. Can it?

The "document.cookie" interface is more to the point since that's a defacto
browser standard. Internal mozilla apis can legitimately have all sorts of
limitations on safe use, though of course we would want those limitations to be
documented.

IE also allows (in document.cookie) name=, plain name (no equals), and names
with spaces -- I strongly suspect that changing that behavior will start
breaking sites.

The de facto standard is far far more important than the spec when it comes to
cookies. We have learned this the hard way, repeatedly. Proceed with all due
caution.

Comment 2

[[e-mail]]

so, you ended up with a cookie name of 'cookie name with spaces in it' and a
blank value?

i don't see anything wrong with that... we're intentionally lax in our
enforcement of the RFC during parsing, because IE does the same. can you show
IE's behavior here, and/or make a tangible case for why it's a problem?

Comment 3

[Michael (GoodWill)]

The question again is: Should Mozilla comply with the standards or not?
If yes then this is a bug.
If no, should there be a Mozilla Standard?
(same goes for many other IE "standards" that Mozilla does not support, one that
comes to mind is document.all)
Its not a question of mozilla internal API.

> Are cookies getting sent out in a broken standard
I do not know, can broken cookies be even sent out? probably.

> so, you ended up with a cookie name of 'cookie name with spaces in it' and a
> blank value?
Well I can also create a cookie with no name and no value.

I've be working on my cookie editing extension for nearly half a year, and I
have not met any cookies that has an 
empty value or an emty name, or spaces in and etc that were set by other sites.
On the other hand:
Apache mod_security considers a value with a cookies suspicious and reports on
them. 
https://bugzilla.mozilla.org/show_bug.cgi?id=268146

I can also put characters of ascii value before 32 in the name and value.
Is that ok?

Comment 4

[[e-mail]]

> The question again is: Should Mozilla comply with the standards or not?

We use RFC2109 as a guide, we do not strictly adhere to it.

> Well I can also create a cookie with no name and no value.

How is that a problem? If a site wants to do it, is there a reason we should
stop them?

> Apache mod_security considers a value with a cookies suspicious and reports on
> them. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=268146
> 
> I can also put characters of ascii value before 32 in the name and value.
> Is that ok?

I don't see why these would be problems, but they may well be. Again, if you can
provide a case why, then we can look into it.

Comment 5

[Daniel Veditz [:dveditz] (OOO: back Aug 26)]

In general Mozilla wants to comply with standards. In the specific case of
cookies the historical implementations (Netscape and IE) have *never* strictly
matched the standards, and that even though it was Netscape who contributed the
standard in the first place.

Every time we've attempted to tighten up and match some aspect of the standard
that wasn't enforced before we've broken sites, and since they "work" in IE and
Netscape 4.x it's Mozilla that's considered at fault and we're forced to give in.

It seems impossible to break the cookie.txt format with control characters.
Sometimes the inclusion of control characters will change the interpretation of
the data, but sites that are actually trying to *use* their cookies won't do
that (\u000a and \u000d will start a new cookie right at that point; \u0009
embedded in the name effectively turns a<tab>b=c into a=b<tab>c; and initial tab
or other whitespace are ignored).

There's some oddness here, and arguably some bugs, but we're not going to
implement the spec. It's probably perfectly fine if your tool is more strict and
disallows some of these characters, but you definitely need to handle empty
cookies (yes it violates the spec, but they wouldn't have coded in a warning in
Apache if they weren't seeing it actually be used).

Comment 6

[Michael (GoodWill)]

Okie. I guess life will never conform to stadards. I do agree with your reasoning.