RFC 31: Loading MapServer Objects from Strings

[Umberto Nicoletti]

On 6/15/07, Steve Lime <Steve.Lime at dnr.state.mn.us> wrote:
> I'm fine with having to enable the feature, that is a good idea regardless. I'm not suggesting
> much in new functionality with regards to URL processing just re-packaging how it happens. I
> think with URL specific tokenizing and the explicit need to turn the feature on that we can
> be reasonably secure.

I don't like the idea of letting someone shoot himself in the foot by
turning on a 'feature': most users will just skip through the README
hunting for the text to cut and paste or are simply unable to
understand 'security'.

Servers I run have been hacked because of poorly conceived
applications and god knows how much I hate wasting time recovering,
reinstalling and cleaning up.

You can't do security in 'a mad rush'.

Umberto

>
> Steve
>
> >>> On 6/15/2007 at 10:32 AM, in message <4672B0F5.3030507 at mapgears.com>, Daniel
> Morissette <dmorissette at MAPGEARS.COM> wrote:
> > Steve Lime wrote:
> >> There is a comment on security in the RFC. The current code severely hobbles
> > what can and
> >> cannot be changed via URL. The RFC proposes doing the same.
> >>
> >
> > I saw that, but there may be combinations of parameters that seem safe
> > at first sight and that could be used remotely in a harmful way.
> > Security flaws are not in stuff the developer could think of, I think
> > most of the time they happen in areas of the software where the
> > developers didn't think there might be a problem otherwise.
> >
> > It's for the reasons we cannot think of today that I wanted to suggest
> > that URL updates be disabled by default, to protect all those who don't
> > care or don't know about this feature... and those who choose to enable
> > the feature explicitly in their mapfile would have to understand that by
> > doing so they accept a potential security risk.
> >
> >> Note that runtime substitutions probably pose a bigger threat. I added a
> > pattern matching
> >> capability to 4.10 to help with that so a developer could, say, limit values
> > to a 3 digit integer.
> >>
> >
> > Agreed runtime %var% substitution can be dangerous, but at least it's
> > not enabled by default and without the user knowing about it: it kicks
> > in only *if* someone uses it and chooses to assume the risk. (Actually
> > does the doc make any mention of the potential risk in using this feature?)
> >
> >> We need a security how-to...
> >>
> >
> > Agreed... and all those potential risks should be documented there.
> >
> > Daniel
>