Re: [http-state] Summary of discussion of Ticket 5 (Cookie ordering)

[Adam Barth <[e-mail]>]

On Fri, Apr 16, 2010 at 3:29 AM, Daniel Stenberg <[e-mail]> wrote:
> On Fri, 16 Apr 2010, Achim Hoffmann wrote:
>> I'd recommend that the spec does not recommend the cookie ordering.
>
> I strongly agree with this. It just seems that we're a minority and we can't
> get stuck on the sorting issue forever...

Indeed.  We're way off in the weeds on this issue.

On Fri, Apr 16, 2010 at 8:14 AM, Achim Hoffmann <[e-mail]> wrote:
> Sorry, have to disagree here.
> See my (still unanswered) posting
>  http://www.webappsec.org/lists/websecurity/archive/2005-11/msg00097.html
> and if we look at the posting in this thread, we see that the ordering is
> not unique anyhow.

Here's how I would respond to your email:

] Does somebody know a paper/link where I can find a definition how browsers
] (should) send cookies?

http://tools.ietf.org/id/draft-ietf-httpstate-cookie

] For example Mozilla/FF seems to send the cookies in this order:

I don't believe you've done your reverse engineering correctly (or
maybe the behavior has changes since you wrote that email).

] Above examples are just a small set of tests, I guess that following
attributes
] are used somehow, somewhere also:

I don't believe that's correct.

] All these variations make tests complicated, that's why I'm asking if there
] exists a rule or alike.

Indeed.  That's why having everyone reverse engineer everyone else's
implementation is no good for interoperability, which is why we
started this working group.  :)

> IIRC the purpose is to write down the status quo today.

That's correct.  Does the current text of the draft not reflect the status quo?

> If the spec says "MAY have any order", they don't need to read the spec,
> and security analysts can always blame the application developer without
> refering the specs if something went wrong ;-)

The spec already requires that servers not depend on the ordering.  If
you're interested in the blame game (which I'm not), the spec already
gives you grounds for blaming the application developer.

On Fri, Apr 16, 2010 at 3:11 AM, Achim Hoffmann <[e-mail]> wrote:
> hmm, this description leads me to following example:
>
>  * cookies send by www.some.tld in following chronological sequence
>
>        Set-Cookie: key=val0;
>        Set-Cookie: key=val1; path=/foo
>        Set-Cookie: key=val2; path=/
>        Set-Cookie: key=val3; path=/bar
>        Set-Cookie: key=val4; domain=.some.tld
>        Set-Cookie: key=val5; domain=.some.tld; path=/some/thing/very/long/to/ensure/being/first

I've converted your test case to test ordering0001:

Set-Cookie: key=val0;
Set-Cookie: key=val1; path=/cookie-parser-result
Set-Cookie: key=val2; path=/
Set-Cookie: key=val3; path=/bar
Set-Cookie: key=val4; domain=.example.org
Set-Cookie: key=val5; domain=.example.org; path=/cookie-parser-result/foo
Location: /cookie-parser-result/foo/baz?ordering0001

I don't think it's possible for both val1 and val3 to appear in the
same Cookie header because neither is a prefix of the other.

>  * cookies send by user agent for a request to http://www.some.tld/
>
>        Cookie: key=val5; key=val1; key=val3; key=val2; key=val0; key=val4

Here's the ordering that Internet Explorer, Firefox, and Chrome produce:

Cookie: key=val5; key=val1; key=val2; key=val4

Notice that the ordering matches the spec.  The cookie with val3 is
missing because /bar is not a prefix of the result URL (we have a
choice of either getting val1 or val3).  The cookie with val0 is
missing because the cookie is set from the path "/cookie-parser",
which gets a default path of "/" and so gets overwritten by val2.

> I guess (but did not yet prove) that most browsers do not send cookies in this
> (above) sequence. It would rather be:
>
>        Cookie: key=val3; key=val1; key=val2; key=val0; key=val5; key=val4
>
> So the new description does not show current practice.

Perhaps you should run your test cases instead of making bold claims
like the above.

> According application security, I already explained that web applications which
> rely on the ordering somehow, are prone to some attacks.

Which is why we require servers not to rely on the ordering.

> As there is no common behaviour according this ordering in current browsers, I'd
> recommend that the spec does not recommend the cookie ordering. This is not wrong
> and would force web application developers to implement proper measures:
>        User agents MAY send cookies in any sequence.

Do you have test cases that demonstrate that there is no common
ordering?  The test case that you presented above does not behave as
you claim.

> KISS - keep it simple, stupid

The cookie protocol is far from simple, but that's just how the world
is.  If I were designing a state management protocol today, I would
design something that was one or two orders of magnitude simpler.

Adam