lynx-dev
[Top][All Lists]
Advanced

[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: Mon, 31 Aug 1998 20:39:35 +0400 (MSD)

>      * From: address@hidden (Mike Castle)
>      * Date: Sat, 29 Aug 1998 19:05:20 -0500 (CDT)
>      * Reply-To: address@hidden
>      * Sender: address@hidden

> Picture this:  someone generates a fake web page that looks like a lynx
> options form.  When submitted, this externally generated web page submits
> all the information to the internal handler.  Now, what if this was an
> anonymous site that doesn't want a lot of features turned on (ie, editors
> for sending mail, etc); and the user of the anonymous site somehow managed
> to get to this bogus fake web page (turning off 'g'oto isn't very secure if
> one can get out to any search engine).

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.

Leonid.

>
> And I'm not even sure what other options have been put into the form since
> I did the original design.
>
> But I do have major concerns about the security aspect of the option form
> and, especially at the stage when I initially submitted it, would NEVER
> use it on an anonymous site.
>
> 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.
>
> When I did the original design, I put stubs in for the "secure" input
> field.  As I've said, I've not had time to even look at the code lately;
> I'm not sure if it's still there or if anyone has followed up on my lead
> and indeed implemented some remedial security there.  Or if, perhaps
> elsewhere, someone has taken the effort to verify that a LYNXOPTIONS: url
> cannot originate from a non-local source, or whatever else is necessary.
>
> In my skimming of recent articles, I've not seen any explicit discussion
> about the security of the form options code.  Perhaps I missed it.  There
> certainly needs to be some, especially with input from those who run lynx
> on anonymous servers.
>
> Until the security can be validated, I would definitely NOT put form
> options as default for the upcoming final release.  I think it would be too
> tempting for anonymous sites to use; possibly with major consequences.
>
> Of course, if I have indeed missed out on anything here, please feel free
> to enlighten me.  I wish I had more time recently to follow up on what I
> started; however, having recently "gotten a life," I am now only spending
> about 50hours/week in front of a computer rather than 110+, and those at
> work where I can't really do all the things I want to do.  :->
>
> At anyrate, I hope some thought gets put into the security aspects of the
> form options code before it's made the default in a production release.
>
> Thanks,
> mrc
> --
>        Mike Castle       Life is like a clock:  You can work constantly
>   address@hidden  and be right all the time, or not work at all



reply via email to

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