Date: Thu, 11 Mar 2004 03:58:44 +0000
From: "Adam M. Costello" <email address hidden>
Subject: Re: [w3m-dev-en 00989] Cookie rejected
Gilles Casse wrote:
> When a particular form is submitted, the following message appears:
> "This cookie was rejected to prevent security violation [RFC 2109
4.3.2 rule 3]."
>
> The concerned url is:
> https://gna.org//account/login.php
The server, named gna.org, sends cookies of the form:
RFC-2109 4.3.2 rule 3 says that a cookie must be rejected if the request
host does not domain-match the domain attribute. The RFC includes a
very clear precise definition of domain-match, and gna.org does *not*
domain-match .gna.org.
However, that is irrelevant in this case, because RFC-2109 explicitly
disclaims jurisdiction over Set-Cookie fields that lack a Version
attribute:
4.2.2 Set-Cookie Syntax
Version=version
Required. The Version attribute, a decimal integer, identifies
to which version of the state management specification the
cookie conforms. For this specification, Version=1 applies.
4.3.1 Interpreting Set-Cookie
The user agent applies these defaults for optional attributes that
are missing:
Version
Defaults to "old cookie" behavior as originally specified by
Netscape. See the HISTORICAL section.
Therefore, I think it is a mistake for w3m to cite RFC-2109 as a reason
to reject a Set-Cookie that lacks a Version attribute. If we want to
know how to properly handle such a Set-Cookie field, we need to consult
the Netscape cookie spec:
When searching the cookie list for valid cookies, a comparison of
the domain attributes of the cookie is made with the Internet domain
name of the host from which the URL will be fetched. If there is
a tail match, then the cookie will go through path matching to see
if it should be sent. "Tail matching" means that domain attribute
is matched against the tail of the fully qualified domain name of
the host. A domain attribute of "acme.com" would match host names
"anvil.acme.com" as well as "shipping.crate.acme.com".
Only hosts within the specified domain can set a cookie for a domain
and domains must have at least two (2) or three (3) periods in them
to prevent domains of the form: ".com", ".edu", and "va.us". Any
domain that fails within one of the seven special top level domains
listed below only require two periods. Any other domain requires at
least three. The seven special top level domains are: "COM", "EDU",
"NET", "ORG", "GOV", "MIL", and "INT".
The default value of domain is the host name of the server which
generated the cookie response.
Does the domain attribute .gna.org match the tail of the host gna.org?
I would think not. But is tail matching even involved in deciding
whether to accept the cookie? The spec says that tail matching is
involved when deciding whether to send a cookie, but doesn't say that
tail matching is involved when deciding whether to accept a cookie.
The cookie is accepted if the host is "within" the domain. Is gna.org
"within" .gna.org? Again, I would think not, but this is even less
clear. Of course, even if you accept the cookie, that probably won't
help you if you then refrain from sending it back to gna.org because it
fails the tail-match.
Curiously, if the server were using RFC-2109 Set-Cookie (with
$Version=1), it wouldn't even include the domain attribute, and the
domain the would default to be the same as the host, and there would be
no problem. But for Netscape Set-Cookie (without $Version), the default
domain of gna.org would fail the two-dot requirement.
It looks to me like there is no way for a server with a second-level
name (like gna.org) to use Netscape cookies at all, at least according
to the Netscape spec. Maybe someone should ask Netscape for a
clarification of the discrepancy between their spec and their
implementation.
By the way, there is another reason to question w3m's citation of
RFC-2109. RFC-2109 was obsoleted a few years ago by RFC-2965, which
uses Set-Cookie2, and mentions using the old Set-Cookie field for
supporting Netscape cookies, but not RFC-2109 cookies. Could it be
that deployment of RFC-2109 cookies never got very far? RFC-2965 does
not even suggest legacy support for 2109; it seems to view Netscape
as the legacy, and 2109 as something to be forgotten (and barely even
acknowledged).
Well, I was reading http:// www.sic. med.tohoku. ac.jp/~ satodai/ w3m-dev- en/200406. month/1022. html and noticed this section as relevant (sorry for the long paste, but there's no l:
Date: Thu, 11 Mar 2004 03:58:44 +0000
From: "Adam M. Costello" <email address hidden>
Subject: Re: [w3m-dev-en 00989] Cookie rejected
Gilles Casse wrote:
> When a particular form is submitted, the following message appears: /gna.org/ /account/ login.php
> "This cookie was rejected to prevent security violation [RFC 2109
4.3.2 rule 3]."
>
> The concerned url is:
> https:/
The server, named gna.org, sends cookies of the form:
Set-Cookie: session_foo=foo; path=/; domain=.gna.org
RFC-2109 4.3.2 rule 3 says that a cookie must be rejected if the request
host does not domain-match the domain attribute. The RFC includes a
very clear precise definition of domain-match, and gna.org does *not*
domain-match .gna.org.
However, that is irrelevant in this case, because RFC-2109 explicitly
disclaims jurisdiction over Set-Cookie fields that lack a Version
attribute:
4.2.2 Set-Cookie Syntax
Version= version
Required. The Version attribute, a decimal integer, identifies
to which version of the state management specification the
cookie conforms. For this specification, Version=1 applies.
4.3.1 Interpreting Set-Cookie
The user agent applies these defaults for optional attributes that
are missing:
Version
Defaults to "old cookie" behavior as originally specified by
Netscape. See the HISTORICAL section.
Therefore, I think it is a mistake for w3m to cite RFC-2109 as a reason
to reject a Set-Cookie that lacks a Version attribute. If we want to
know how to properly handle such a Set-Cookie field, we need to consult
the Netscape cookie spec:
http:// www.netscape. com/newsref/ std/cookie_ spec.html
Unfortunately, that spec is unclear:
When searching the cookie list for valid cookies, a comparison of acme.com" as well as "shipping. crate.acme. com".
the domain attributes of the cookie is made with the Internet domain
name of the host from which the URL will be fetched. If there is
a tail match, then the cookie will go through path matching to see
if it should be sent. "Tail matching" means that domain attribute
is matched against the tail of the fully qualified domain name of
the host. A domain attribute of "acme.com" would match host names
"anvil.
Only hosts within the specified domain can set a cookie for a domain
and domains must have at least two (2) or three (3) periods in them
to prevent domains of the form: ".com", ".edu", and "va.us". Any
domain that fails within one of the seven special top level domains
listed below only require two periods. Any other domain requires at
least three. The seven special top level domains are: "COM", "EDU",
"NET", "ORG", "GOV", "MIL", and "INT".
The default value of domain is the host name of the server which
generated the cookie response.
Does the domain attribute .gna.org match the tail of the host gna.org?
I would think not. But is tail matching even involved in deciding
whether to accept the cookie? The spec says that tail matching is
involved when deciding whether to send a cookie, but doesn't say that
tail matching is involved when deciding whether to accept a cookie.
The cookie is accepted if the host is "within" the domain. Is gna.org
"within" .gna.org? Again, I would think not, but this is even less
clear. Of course, even if you accept the cookie, that probably won't
help you if you then refrain from sending it back to gna.org because it
fails the tail-match.
Curiously, if the server were using RFC-2109 Set-Cookie (with
$Version=1), it wouldn't even include the domain attribute, and the
domain the would default to be the same as the host, and there would be
no problem. But for Netscape Set-Cookie (without $Version), the default
domain of gna.org would fail the two-dot requirement.
It looks to me like there is no way for a server with a second-level
name (like gna.org) to use Netscape cookies at all, at least according
to the Netscape spec. Maybe someone should ask Netscape for a
clarification of the discrepancy between their spec and their
implementation.
By the way, there is another reason to question w3m's citation of
RFC-2109. RFC-2109 was obsoleted a few years ago by RFC-2965, which
uses Set-Cookie2, and mentions using the old Set-Cookie field for
supporting Netscape cookies, but not RFC-2109 cookies. Could it be
that deployment of RFC-2109 cookies never got very far? RFC-2965 does
not even suggest legacy support for 2109; it seems to view Netscape
as the legacy, and 2109 as something to be forgotten (and barely even
acknowledged).