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

[Klaus Weide]

On Tue, 29 Dec 1998, brian j. pardy wrote:
> On Tue, 29 Dec 1998, Klaus Weide wrote:
> > On Mon, 28 Dec 1998, brian j. pardy wrote:
> > > 
> > > Perhaps a new option similar to COOKIE_ACCEPT_DOMAINS to specify
> > > servers that are specifically allowed to set invalid domains?
> > 
> > I'm all for giving the user fine-grained control over cookies, but
> > there are some difficulties with this.  Part of the checks is
> > comparing two domain names (the one from the cookie and the actual
> > server hostname).  Should that hypothetical new option set a property
> > of (1) the domain given in the set-cookie or (2) of the hostname?  You
> > seem to have (2) in mind, but (1) would be more equivalent to what
> > COOKIE_ACCEPT_DOMAINS does.
> 
> With (1), unless I'm missing something, a user could set "yahoo.com" as
> a domain which can be set via invalid cookies -- which it seems would
> allow *any* hostname to set a cookie for "yahoo.com".

Only if we allow the host_matches() test to be completely bypassed - which
I think we shouldn't do anyway.

If we still leave the host_matches() test in place (maybe modified?),
then "edit.my.yahoo.com" as well as "www.yahoo.com" and "www1.yahoo.com"
could set a "domain=.yahoo.com" cookie, but unrelated hosts could not.

> Under (2), "edit.my.yahoo.com" could be a domain which has the (currently
> not existing) "I can set invalid domains" flag, and be allowed to set 
> cookies for domains below it (ie for "yahoo.com").

In that case it seems to make more sense, yes.  In some other cases,
it may be not so good - the user has to know all the potential
hostnames, unless there is some kind of pattern matching.  (Like
www1.yahoo.com www2.yahoo.com www3.yahoo.com www4.yahoo.com etc., or
www7.crl.com www9.crl.com www11.crl.com www13.crl.com etc...  Well
this is not a very relevant example since they are probably meant to
always be accesses as www.crl.com, but other case where hostnames can
change on a whim are possible.)  I don't know how important this is,
just wanted to bring it up as a potential consideration.

I was thinking of (1) as the more obvious choice, because we already
have per-domain-attribute configuration info.  By putting a new flag
into domain_entry (maybe making bv a bitmask), the already existing
mechanisms could be used or duplicated, and then the (currently not
existing) "cookies for this domain can be set by invalid hosts" flag
could be changed from The Cookie Jar page at runtime.

> What I presently have (patch will be at [0] in about 10 minutes, if you're
> interested) makes an option for lynx.cfg and .lynxrc in the same style as 
> COOKIE_ACCEPT_DOMAINS (ie, just a big list) which is checked (not securely
> yet, I want to do this as a domain attribute instead of basically a list
> being grepped) when a new cookie comes across.
> 
> As for being more restrictive than 2.8.1, I'm all for it after thinking this
> over again.
> 
> 
> [0] <URL:http://www.psnw.com/~posterkid/code/lynx-invaliddomains.patch>

I just had a brief look at it.  The current implementation of
allowed_invalid_domain isn't quite what's needed, a substring match
isn't good enough - for example you would find "microsoft.com" in 
"...,www.microsoft.com,..." as well as in "...,microsoft.com.au,..."
Parsing the given string into a list seems more appropriate, as it is
done for LYCookieAcceptDomains and friends.

I also think the option should be named something else than
COOKIE_INVALID_DOMAINS, I find that confusing.
COOKIE_ACCEPT_INVALID_DOMAINS sounds more like it, but seems to imply
choice (1) from above.  If you continue to go with (2), it should be
COOKIE_ACCEPT_FROM_THESE_INVALID_HOSTS or similar...

I hope you don't find I am complaining too much.  I shouldn't, since you
are writing the code. :)


     Klaus