[UMN_MAPSERVER-USERS] mapserver 5 expression

[Steve Lime]

Mapext has a validation pattern in that it must consist of 4 space
delimited doubles. Indirectly
the webObj minscaledenom and maxscaledenom parameters also serve  in
that capacity by
making sure folks can't zoom in or out too far. Still need something to
limit panning but that should
come to the CGI in 5.2 (already in mapscript).

Steve

>>> On 9/15/2007 at 9:55 AM, in message <46EBF273.5000006 at uva.nl>, Jan
Hartmann
<j.l.h.hartmann at UVA.NL> wrote:
> Hi Daniel,
> 
> For some reason your answer didn't make it to my mailbox (or I 
> overlooked it) . Anyway, what you say is perfectly reasonable, and I

> have no problem with using %variable% runtime substitions instead of
the 
> map_layer_class_expression syntax. I didn't know about the validation

> pattern either, but it looks like a good idea. That way you can
expose 
> only restricted parts of your maps, even with single files, and this

> gives some protection even without a regular database.
> 
> By the way, I sometimes want only to show only a particular *area* of

> the mapfile. Would it make sense to create a validation pattern for
the 
> "mapext" CGI-variable? Just a wild idea.
> 
> Thanks,
> 
> Jan
> 
> Thanks,
> 
> Jan
> 
> Jan,
> 
> --------------------------------------------------------------
> 
> Daniel's posting, sept. 5, 
>
http://lists.umn.edu/cgi-bin/wa?A2=ind0709&L=mapserver-dev&T=0&F=&S=&P=2148

> 
> Sorry for replying so late to this thread, but I'm not sure to fully
> understand all the implications of what is being discussed, that's
why I
> didn't reply earlier. We are talking about being able to update
CLASS
> EXPRESSIONs and not the LAYER DATA statement, right? (Wondering why
the
> DATA statement came up in this thread)
> 
> What Steve proposes is that you use %variable% runtime substitutions
to
> update your CLASS EXPRESSIONs. Does that not work for you?
> 
> We could possibly consider re-enabling update CLASS EXPRESSIONs via
URL
> syntax like "map.layer[fastvisa].class[0].EXPRESSION=(...)" but that
> would just be an alternate mechanism to do the same thing as
variable
> substitutions, except that variable substitutions allows you to set
a
> "variablename_validation_pattern" metadata to restrict the possible
> values of %variablename%, so it's actually safer. (I learned about
that
> validation pattern only a few minutes ago).
> 
> What this means is that if you use this mechanism you can restrict
the
> possible values that a user can pass to an expression. Maybe the risk
of
> SQL injection in CLASS EXPRESSIONs is close to none, but allowing
> URL-setting of arbitrary values in CLASS EXPRESSIONs via URLs has
the
> potential to expose some data that you didn't intend to expose
(because
> you thought your class expressions as written in the mapfile would
> filter out those shapes wiht sensitive info for instance).
> 
> Maybe that's not a high risk, but if there is an alternate and safer
> mechanism that keeps the class expressions locked by default then
why
> not use it? That's my understanding of Steve's explanation anyway...
> hopefully I am not just adding more confusion.
> 
> Daniel
> 
> 
> Jan Hartmann wrote:
>> I didn't get any follow-up on this, so I am wondering what people
think 
>> of it. If the reasoning is valid, and there are no other security
issues 
>> with the expression statement, I would propose to return to version
4 
>> and make it possible again to access the expression-statement in 
>> MapServer CGI from the URL. That's really an important issue for
me.
>> 
>> Thanks,
>> 
>> Jan
>> 
>> Jan Hartmann wrote:
>>> I don't mind rewriting my applications if the syntax is better,
which 
>>> it probably is. I *do* mind giving up an essential MapServer 
>>> functionality for the CGI version. I don't know much about
security, 
>>> but I don't see why you should build an extra security layer in the

>>> DATA statement for expressions. The DATA statement is closed off, 
>>> unless you set it open via DATAPATTERN, and the SQL expressions (I

>>> guess that's where the pain really is) can only get at that part of

>>> your database system that has been opened by the CONNECTION
parameter. 
>>> If you let people connect to your whole database with read and
write 
>>> rights, well I suppose you could get into trouble then. But that is

>>> not necessary: you can create a user within your database system
with 
>>> only those rights and accesses you really want to expose, and
specify 
>>> that user in the CONNECTION line. No one will be able to get past
that 
>>> user's rights. Am I missing something here?
>>>
>>> Jan
>>>
>>> Steve Lime wrote:
>>>> You are correct. Even if we re-enabled that functionality
applications
>>>> will
>>>> break because of the syntax change in how URL configuration is
handled.
>>>> The migration guide talks about these changes.
>>>>
>>>> I agree that EXPRESSIONs are not as likely to suffer from
security
>>>> problems
>>>> although I don't like the idea of allowing it since there is no
way to
>>>> validate
>>>> an expression without evaluating it. No security problems with
that
>>>> functionality
>>>> have been reported. I still prefer using the runtime subs where
you can
>>>> apply
>>>> your own checks. You can substitute entire expressions that way
too.
>>>>
>>>> Cc'ing mapserver-dev
>>>>
>>>> Steve
>>>>
>>>>>>> Jan Hartmann <j.l.h.hartmann at uva.nl> 08/31/07 7:31 AM >>>
>>>> Am I right that expressions could be changed by URLS in version 4
and 
>>>> cannot be changed any more in version 5? In that case I would 
>>>> strongly propose to reintroduce that possibility. It would break
many 
>>>> of my applications, and I would need to use MapScript for those. 
>>>> Generally I only use CGI, because not all webservers I have to
write 
>>>> for support MapScript. It's really a big restriction on MapServer
CGI
>>>>
>>>> If there are security problems, I would like to see examples of 
>>>> those. Perhaps  more specific solution can be found then. Anayway,

>>>> the DATA statement is protected by the DATAPATTERN statement in
the 
>>>> mapfile, so if someone sets that open, he takes a risk anayway. 
>>>> Prohibiting changes to expressions in that situation is overkill
IMO.
>>>>
>>>> Jan
>>>>
>>>> Steve Lime wrote:
>>>>> Expressions are not changable via URL configuration, at least not
in
>>>>> their entirety like
>>>>> you are doing. I took a conservative approach to exposing
parameters
>>>> to
>>>>> URL when
>>>>> that support was re-written for 5.0. I was concerned that
unchecked
>>>>> manipulation of
>>>>> expressions and filters *could* be a security problem, so that
is
>>>>> unavailable.
>>>>>
>>>>> What do folks think?
>>>>>
>>>>> Note that it is easy to re-enable. Just change line 162 in
maplexer.l:
>>>>>
>>>>> from <INITIAL>expression ...
>>>>> to <INITIAL,URL_STRING>expression ...
>>>>>
>>>>> You can also work around this using runtime substitution.
Presumably
>>>>> you'd write the mapfile
>>>>> entry like so:
>>>>>
>>>>>   LAYER
>>>>>     NAME 'fastvisa'
>>>>>     ...
>>>>>     CLASS
>>>>>         EXPRESSION ([FNR]=%myid%)
>>>>>     END
>>>>>   END
>>>>>
>>>>> and would have a URL like ...&myid=210176493&...
>>>>>
>>>>> The advantage here is the you make the decision to enable that
level
>>>> of
>>>>> configuration, plus you
>>>>> can apply a regex filter to the value passed in from the URL and
if
>>>> the
>>>>> value doesn't match that
>>>>> pattern then no substitution is made:
>>>>>
>>>>>   LAYER
>>>>>     NAME 'fastvisa'
>>>>>     ...
>>>>>     METADATA
>>>>>        myid_validation_pattern   '^\d{9}$'
>>>>>     END
>>>>>     CLASS
>>>>>         EXPRESSION ([FNR]=%myid%)
>>>>>     END
>>>>>   END
>>>>>
>>>>> In this example the input value for myid must consist of exactly
9
>>>>> digits.
>>>>>
>>>>> Steve
>>>>>
>>>>>>>> On 8/29/2007 at 7:28 AM, in message
>>>>> <BAY116-F20CE60F662031E0BD05A8182CC0 at phx.gbl>, Lars-Göran Edholm
>>>>> <lged_morris at HOTMAIL.COM> wrote:
>>>>>> Hi again!
>>>>>> Tried with
>>>>>> &map.layer[fastvisa].class[0]=EXPRESSION+([FNR]=210176493)
>>>>>> gives the error:
>>>>>> loadClass(): Unknown identifier. Parsing error near
>>>>> (EXPRESSION):(line 1)
>>>>>> with
>>>>>> &map.layer[fastvisa].class[0].EXPRESSION=([FNR]=210176493)
>>>>>> i get
>>>>>> loadClass(): Unknown identifier. Parsing error near (():(line
1)
>>>>>>
>>>>>> Seems that there is something with Expression that is wrong.
>>>>>> Lars-Göran Edholm
>>>>>>
>>>>>>
_________________________________________________________________
>>>>>> Upptäck kärleken på MSN 
>>>>>> http://match.se.msn.com/channel/index.aspx?trackingid=1002962 
>>>>
>>>
>>