RFC 31: Loading MapServer Objects from Strings

[Steve Lime]

Oh, I agree that there should be more to this than simply hiding behind a parameter. I think
forcing users to activate a feature like this makes sense as an initial hoop. It's better than
letting them shoot themselves in the foot without doing anything.

The CGI parameter processing code has some built in checks to guard big buffer or lot's of 
variable type attacks.

Beyond that I'm proposing that we be very explicit about what parameters are touchable via
URL configuration. This can be done through the tokenizer and has been in place to date. Each
parameter exposed should be scrutinized from a URL setting point of view.

We could also consider some sort of pattern-based checks that are required for changing
templates or data values via URL (e.g. DATAPATTERN, TEMPLATEPATTERN). We could also
make those required patterns to set. (that goes for runtime subs too)...

Steve


>>> On 6/16/2007 at 5:50 AM, in message
<75b4b93e0706160350u296e54ddk2591f24ee4c63070 at mail.gmail.com>, "Umberto
Nicoletti" <umberto.nicoletti at gmail.com> wrote:
> 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
>>