lynx-dev
[Top][All Lists]
Advanced

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

lynx-dev Accepting invalid cookies - was: cookie bug (not in lynx)


From: Klaus Weide
Subject: lynx-dev Accepting invalid cookies - was: cookie bug (not in lynx)
Date: Sun, 27 Dec 1998 19:50:12 -0600 (CST)

On Wed, 23 Dec 1998, brian j. pardy wrote:
> From <URL:http://www.paradise.net.nz/~glineham/cookiemonster.html>:
> 
>     HTTP Cookie Bug Affecting Servers On Non-US Domains
>     
>     22 December 1998 NZDT
>     
>    If you are any sort of expert in the areas of HTTP, cookies, browsers,
>    or general Internet security we urgently want to read any comments you
>    might have. Email address@hidden now.
>    
>    Affected applications:
>      * Internet Explorer 5 Beta (Win32)
>      [...]
>      * others extremely likely
>        
>    Unaffected applications:
>      * Lynx 2.8rel.2 (Linux):
>        asks the user to "allow setting of cookie with invalid domain
>        .co.nz"
> 
> [...]
> 
> A sample exploit description is linked on that page.
> 
> My concern here -- the patch in 2.8.1 that will accept cookies with
> invalid domains *IF* ACCEPT_ALL_COOKIES is enabled. 
> 
> This is either a bug or a feature, depending on what ACCEPT_ALL_COOKIES is
> defined to mean.

I agree that there is a problem.  ACCEPT_ALL_COOKIES is currently
overloaded to mean (at least) two things:

(1) Accept cookies from all domains
(2) Accept (some) invalid cookies

That means that (a) if you set ACCEPT_ALL_COOKIES because you don't want to
be prompted for new cookies from new domains, you get the side effect of
accepting even invalid cookies; and (b) if you set ACCEPT_ALL_COOKIES to
work around some problem with a specific site, you won't be prompted for
new domains at all.

These are conceptuallt two different things, they should be controllable
by separate options.  Either an additional flag/option is needed, or
even a way to allow (some) invalid cookies on a per-domain basis.

The behavior of ACCEPT_ALL_COOKIES is also not consistently documented:
The Users Guide says that "... Lynx will accept all cookies."  The
comment in lynx.cfg says that "... Lynx will accept cookies from all
domains with no user interaction."  Nothing is said about the effect on
checking or validity.

I checked some of the history of ACCEPT_ALL_COOKIES in the archives.  I
get the impression that at first this flag just meant "accept cookies
from all domains", although I didn't check that far back.  (Correct me
if I am wrong.)  The more permissive behavior seems to have been
introduced in two stages: first, the INVALID_COOKIE_DOMAIN_CONFIRMATION
prompt was skipped for LYAcceptAllCookies.  Later, the much broader
change came based on the following exchange:

   Linkname: lynx-dev Version 0 cookie suggestion & minimal patch
        URL: http://www.flora.org/lynx-dev/html/month1098/msg00829.html

   Linkname: Re: lynx-dev Version 0 cookie suggestion & minimal patch
        URL: http://www.flora.org/lynx-dev/html/month1098/msg00844.html

This 2nd change, the "if (co->version != 0 || !LYAcceptAllCookies)"
around _all_ the initial checks in store_cookie, is _much_ too broad.
Most notably it completely bypasses the "if (!host_matches(...))" test,
so that cookies become completely promiscuous.  A better approach would
have been to bypass just those tests that create problems in concrete
cases.

[ In reality co->version is always 0 these days - I haven't seen any
version 1 cookies yet, so that additonal test currently doesn't have a
practical effect. ]

The host_matches() test is required even by the "Netscape cookie
specification" (which BTW carries the header "Preliminary Specification
- Use with caution"...).  In the URL referenced above, Risto Widenius
<address@hidden> wrote:

> As I understand it, the original v0 Netscape cookie specification does
> not require the client to reject incoming cookies at any
> circumstances; rather to check their validity before sending requests.
> The wording in the original is somewhat opaque, though.

While I agree that the document doesn't go into much detail, it seems
clear that it requires rejecting cookies in _some_ cases, namely for a
domain mismatch:

> Only hosts within the specified domain can set a cookie for a domain [...]

(It does not say anything about rejecting cookies because of a path
mismatch, which was Risto's original problem.)  If this were not
required for Netscape cookies, talking about "cookie exploits" and
"vulnerability" (of the present kind) would be rather meaningless.


To summarize, IMO Lynx should (1) have at least something like an
additional flag/option -accept_some_invalid_cookies (or
-relaxed_cookie_checking?  or -something_completely_different?), and
(2) don't accept all cookies completely unchecked _even if_ that flag
is set.


     Klaus


reply via email to

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