RFC 31: Loading MapServer Objects from Strings

[Steve Lime]

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.

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