[mapserver-dev] Re: MapServer security issue

Steve Lime steve.lime at dnr.state.mn.us
Fri Nov 8 15:42:10 EST 2002


I like this idea, but how to implement. I assume you'd have to look
at the referer which I thought was a bit inconsistant between
browser vendors. Thoughts?

What about a PATH variable at the LAYER level, which if defined
would limit where DATA could be found. With out a limiting PATH
we could disable changing of the DATA property. Same thing
could apply to HTML templates.

Steve

Stephen Lime
Data & Applications Manager

Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937

>>> Jan Hartmann <jhart at frw.uva.nl> 11/06/02 06:46AM >>>
Another approach could be to look for the origin of the calling URL. If

that has same as the HTTP-address as the MapServer CGI, everything
could 
be allowed. If not, no scripting should be possible. Javascript uses
the 
same sort of security: if you load a webpage into a subframe of your 
browser, the other frames can only modify (or even read) its variables

if it comes from the same server; else it can only be displayed. You
can 
use the "document.domain" variable to widen the number of permitted
hosts.

I wouldn't like to have a totally unscriptable "DATA" statement. It is

very usable when having lots of data files with only minor differences.

Without scripting "DATA" you would have to produce immense MapFiles. Of

course everything can be done be MapScript, but many applications don't

need all that horse power. Besides, many peope aren't able or permitted

to use PHP or Perl on their server.

A last argument for keeping MapServer CGI as scriptable as possible is

the power of the new W3C JavaScript/DOM standard. You can produce 
complete client-side Web applications (even for IE) without using any 
HTML at all, just using the DOM interface. I have found this a very 
valuable addition to MapServer's Perl/PHP/Java scripting.

Jan Hartmann





More information about the mapserver-dev mailing list