[mapserver-dev] Re: MapServer security issue
jhart at frw.uva.nl
Tue Nov 19 07:25:19 EST 2002
Well, I was very short I'm afraid, but it was Saturday afternoon and I
wanted to see the entry of St. Nicholas ("Santa Claus") in Amsterdam.
I'll try to sum up in more detail.
The security problem with MapServer CGI is that requests for maps can
contain pathnames to files anywhere on the WebServer's filesystem. These
requests can be scripted by external browsers, so in theory everyone on
the net has some sort of read access to all vector and raster files on
the Webserver's hard disk. Steve's proposal was to add the variables
DATAPATTERN and FILEPATTERN to the Mapfile. These should contain a
regular expression that would be used to restrict every further DATA or
FILE access by scripting. That way you can be sure that only those files
can be read that match the regular expression and nothing else.
This way the contents of the Mapfile are shielded. However, the Mapfile
as a whole still remains visible to the whole world. To see why this is
a security leak, imagine someone with a public WWW MapServer and a
MapFile accessing certain GIS-files on his hard disk. In addition, he
has lots of other GIS files on that same hard disk to be used with
private MapScript applications, which also have their own MapFiles. With
Steve's solution, the second group of GIS files are impossible to access
for the public MapServer. However, the Mapfiles used by the MapScript
applications can be accessed. Everyone can send URLs to the public
Mapserver like "http://.../mapserv?map=<any file>". The pathname of the
mapfile is relative to the MapServer script directory, and can cover the
whole hard disk. A MapFile cannot be shielded with a variable within
that same MapFile (at least I can't imagine how). This way the public
MapServer can make visible maps that are meant only for private use and
there is no protection against it. Of course, you need to know the
actual filename of the MapFile, and you can hide this very deep.
However, you can not guarantee that it will never be found.
A solution would be to add an environmental variable (called e.g.
MS_MAPFILE_PATTERN), with a regular expression which restricts the
possible range of MapFiles. This is exactly the same mechanism as
DATAPATTERN and FILEPATTERN above; the only difference is that it is not
in the MapFile, but in the environment. The two other environment
mechanisms mentioned by Steve can remain as they are; they are very
handy, and they can hide the MapFiles very effectively, but they cannot
make them completely impossible to access.
Hope this is clearer.
Steve Lime wrote:
> Too much running through my head these days. Can you sum up the map
> hole? I tried wading through this thread and thought I'd just ask. At
> the moment
> you can set a mapfile by:
> - setting the MS_MAPFILE env variable
> - setting parameter map to some file
> - setting parameter map to some env variable (i.e. COMPASS_MAPFILE)
> In any case, the file name is checked against a regex and that file is
> never returned
> to the user. I use the last option all the time to hide mapfile
> locations and to make
> application management easier.
> Stephen Lime
> Data & Applications Manager
> Minnesota DNR
> 500 Lafayette Road
> St. Paul, MN 55155
>>>>Jan Hartmann <jhart at frw.uva.nl> 11/16/02 08:13AM >>>
> On second thougthts:
> To allow for multiple MapFiles to be accessed from URL's, MS_MAPFILE
> could be a colon-separated list of allowed mapfiles
> (file1:file2:file3:...). Each of those could be accessed via the normal
> ?map=mapfile.parameter. The first one could be the default map. Coming
> to think of it, you could just as well do this with a regex. And to
> protect people against themselves, you could make MS_MAPFILE
> Jan Hartmann wrote:
>>Just one final loophole, mentioned by Daniel: the mapfile from the
>>calling URL. This can come anywhere in the filesystem and you cannot
>>shield that with a regular expression within the mapfile (would be
>>circular, wouldn't it?). His solution (adding an environment variable
>>MS_MAPFILE that can override the map-URL parameter) looks fine to
More information about the mapserver-dev