Re: lynx-dev form options

[Leonid Pauzner]

> Amazingly enough Leonid Pauzner said:
> > >      * From: address@hidden (Mike Castle)
> > One security item:
> > Some options may be disabled in gen_options() by "if (!no_dots)" etc.,
> > but this is still open in postoptions() for those who change options's HTML
> > manually, so we should merge restrictions from gen_options() to 
> > postoptions()
> > and keep this invariant clear.
> > I think no more security problems here.
>
> This is *precisely* what I was referring to here:
Yes, and I sent a patch to Tom.
>
> > > I wanted to avoid excessively complicating the backend processing of the
> > > posted form input.  I wanted to have one location to check for the
> > > security/validity of enabling certain features; specifically when the html
> > > is generated.  I know the difficulty of having to keep mulitple sections 
> > > of
> > > code in sync, and trying to maintain any security aspects where both the
> > > html is generated and the posted data is processed will be a nightmare.
> > > Sure, when adding new features, care can be taken.  But somewhere down the
> > > line, one part will be enhanced and the other missed; someone will exploit
> > > it.
>
>
> Like I said:  I think trying to handle it in both locations is an extremely
> bad idea.  Because someone will eventually mess up and forget to modify
> both sections of code and somewhere along the line open up a hole.

I think not, there are only 4 or 5 options with a restrictions check,
why not to read the comment in function header before modifying it?
Lynx have a _LOT_ of places where we should maintain changes in
four or more locations (undocumented) in sync,
so it is not a problem for options.

>
> The only proper way that I can see to close this up is to generate a one
> shot item each time get_options is called (the "secure" input field), and
> when postoption processes it, verifies it.  Also, \ rendering should be
> disabled for this page (otherwise when using an anon account, one can
> figure out what the oneshot passcode is, and spoof it).

>From the other hand, disable \ (yes, and download option, hystory page,
temp HTML file etc.) may be a problem and unwanted complication.

Leonid.

>
> Once "secure" is working, then there is no longer any need to keep other
> security aspects in both gen_options() and postoptions() in sync.
>
> mrc
> --
>        Mike Castle       Life is like a clock:  You can work constantly