[UMN_MAPSERVER-USERS] mapserver 5 expression
Jan Hartmann
j.l.h.hartmann at UVA.NL
Sat Sep 15 10:55:47 EDT 2007
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
>>>
>>
>
More information about the mapserver-dev
mailing list