[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