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

[brian j. pardy]

On Tue, 29 Dec 1998, Klaus Weide wrote:

> 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.

Okay.  I'll work for now on getting a proper flag for domains that are
specified, and then we can decide on just what to do with it and how.

> > 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 thought about pattern matching for COOKIE_ACCEPT_DOMAINS and 
COOKIE_REJECT_DOMAINS and I was simply too lazy to code it.  This is
indeed a thought, but since the (two or three) sites I accept cookies
from don't have the problem we're working on, I don't feel qualified
to decide.

> 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.

I've made bv a bitmask, keeping all of the original settings.  Some of
them are mutually exclusive, that needs to be hacked through. 

I think the actual creation of this extra flag in the domain_entry struct
is removed from whether implementation is chosen to be (1) or (2).

> [...]
> 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 agree that it is a pretty miserably named option, I just wanted a name
so I can start to play with it.  

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

It's not a problem. :)  I'm just a hacker and can occasionally put things
together without fully thinking them through.  Other voices help.


Okay, I think I have it mostly handled.

New patch is at:

<URL:http://www.psnw.com/~posterkid/code/lynx-invalidcookiedomains.patch>

(It's about 16K, and this mail is long enough already.)

* de->bv has been made a bitmask, with corresponding #defines in LYCookie.h
* options and functions should freely be renamed to something better :)
* look at my FIXME line in LYHandleCookies() (I think) -- I'm not sure
  how those should be displayed.
* this will NOT change behavior from stock dev.12, but is a basis to begin
  changing behavior
* I haven't checked for memory leaks, but since 95% is cannibalized from
  earlier code w/o leaks, it should be okay
* the various tests/sets on de->bv have been hacked to grok a bitfield, but
  since some options are mutually exclusive, these should all be audited
* the new option hasn't been commented in lynx.cfg yet, or added to the
  forms/menu options code, or to .lynxrc-saving code.  Sorry.
* a couple typos that stuck out
* probably a couple other gotchas I'm not remembering :)

-- 
GPG & PGP public keys: <URL:http://www.psnw.com/~posterkid/keys/> 
PGP fingerprint: 42 57 B3 D2 39 8E 74 C3  5E 4D AC 43 25 D2 26 D4