[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