lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Lynx-dev] "invalid cookie path", Re: redirection loop


From: Bela Lubkin
Subject: [Lynx-dev] "invalid cookie path", Re: redirection loop
Date: Tue, 23 Oct 2018 01:59:39 -0700

Sylvain Bertrand wrote:

> Regarding the "invalid cookie paths":
>
> From the trace file, I have the following request-uri:
> GET 
> /search?ie=ISO-8859-1&hl=fr&source=hp&q=tintin&btnG=Recherche+Google&gbv=1 
> HTTP/1.1
>
> In server response, I have 2 cookies with an "invalid path attribute":
> /complete/search
> /search
>
> Lynx code seems to perform some prefix validation on the paths regarding the
> request uri, but it seems there is no such thing as path validation in the 
> RFC:
> https://tools.ietf.org/html/rfc6265
>
> Namely, /complete/search and /search path attributes should not block lynx
> acceptance of those cookies.

The code which checks this is in src/LYCookie.c, with this comment:

     * Apply sanity checks.
     *
     * Section 4.3.2, condition 1:  The value for the Path attribute is
     * not a prefix of the request-URI.

'Section 4.3.2' apparently refers to https://tools.ietf.org/html/rfc2109
(1997):

" 4.3.2  Rejecting Cookies
"
"    To prevent possible security or privacy violations, a user agent
"    rejects a cookie (shall not store its information) if any of the
"    following is true:
"
"    * The value for the Path attribute is not a prefix of the request-
"      URI.

RFC 2109 was was obsoleted by https://tools.ietf.org/html/rfc2965
(2000), which had:

"    3.3.2  Rejecting Cookies  To prevent possible security or privacy
"    violations, a user agent rejects a cookie according to rules below.
"    [...]
"
"    A user agent rejects (SHALL NOT store its information) if [...]
"    any of the following is true of the attributes explicitly present
"    in the Set-Cookie2 response header:
"
"       *  The value for the Path attribute is not a prefix of the
"          request-URI.

RFC 6265 obsoleted RFC 2965 in 2011; it says:

" 5.1.4.  Paths and Path-Match
"
"    The user agent MUST use an algorithm equivalent to the following
"    algorithm to compute the default-path of a cookie:
"
"    [...]
"
"    A request-path path-matches a given cookie-path if at least one of
"    the following conditions holds:
"
"    o  The cookie-path and the request-path are identical.
"
"    o  The cookie-path is a prefix of the request-path, and the last
"       character of the cookie-path is %x2F ("/").

... which means that your cookies (or at least the "/complete/search"
one) do not path-match the request.  However, RFC 6265 does not appear
to say that the user agent should reject received cookies for this
reason; as far as I can make out, from section "5.3.  Storage Model",
these cookies should be stored.  RFC 6265 only seems to care about path
matching when later retrieving a cookie, not when initially storing one.

Thomas, do you agree?

In any case, this code was written to comply with RFC 2109 and does not
appear to have been consciously updated to the standards of 2965 or
6265.  Doing so would likely be a Big Project and might break or
destabilize Lynx.  I'm not sure if spot-updating this one thing to 6265
level is a good idea.  It might introduce a security problem that isn't
a problem in 6265 due to changes elsewhere.  (Note: I am not saying that
I have knowledge of such a problem, only speculating that it could
exist.)

>Bela<



reply via email to

[Prev in Thread] Current Thread [Next in Thread]