[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev form options
From: |
Leonid Pauzner |
Subject: |
Re: lynx-dev form options |
Date: |
Thu, 3 Sep 1998 13:12:58 +0400 (MSD) |
> 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