<br><font size=2 face="sans-serif">I think" validation patterns"
are a real solution to the problem and minimizing access-priviliges is
not.</font>
<br>
<br><font size=2 face="sans-serif">When filter with URL-substitution is
used without validation patterns, one relies to heavily on the security-system
of postgres. </font>
<br><font size=2 face="sans-serif">This is acceptable in most intranets
but hazardous in the internet.</font>
<br><font size=2 face="sans-serif">Look for example at http://www.postgresql.org/support/security.html
to see, what can be done with even a minimal-postgres-login.</font>
<br>
<br><font size=2 face="sans-serif">But again: Everything's fine with "validation
patterns" ...</font>
<br>
<br><font size=2 face="sans-serif">Ciao</font>
<br><font size=2 face="sans-serif">Benedikt</font>
<br>
<br><font size=2 face="sans-serif">Extract of the http://www.postgresql.org/support/security.html</font>
<br><font size=2 face="sans-serif">* </font><font size=3>Three vulnearbilities
in the regular expression handling libraries can be exploited to cause
a backend crash, infinite loops or memory exhaustion. This vulnearbility
can be exploited through frontend applications that allow unfiltered regular
expressions to be passed in queries. </font>
<br><font size=2 face="sans-serif">* </font><font size=3>A bug in the handling
of SET ROLE allows escalation of privileges to any other database user,
including superuser. A valid login is required to exploit this vulnerability
</font>
<br><font size=2 face="sans-serif">* </font><font size=3>Calling COALESCE()
with two NULL parameters would cause the current backend to crash, causing
a denial of service. A valid login is required to exploit this vulnerability.
</font>
<br><font size=2 face="sans-serif">* </font><font size=3>Public EXECUTE
access is given to certain character conversion functions that are not
designed to be safe against malicious arguments. This can cause at least
a denial of service. A valid login is required to exploit this vulnerability
</font>
<br>
<br>
<br><tt><font size=2>"Steve Lime" <Steve.Lime@dnr.state.mn.us>
schrieb am 26.01.2009 21:29:52:<br>
<br>
> In addition, one can and should apply validation patterns to variables<br>
> used in SQL. That way MapServer<br>
> can test the input data before handing off to PostGIS or whatever.<br>
> <br>
> These patterns are set in LAYER metadata. For example:<br>
> <br>
> LAYER<br>
> ...<br>
> DATA"'the_geom FROM (SELECT the_geom FROM my_table WHERE
ID = '%id%')<br>
> as foo USING UNIQUE OID" <br>
> METADATA<br>
> id_validation_pattern '^[0-9]{3}$'<br>
> END<br>
> END<br>
> <br>
> This tells the CGI to test the request parameter against the regex<br>
> '^[1-9]{3}$'. The regex says that the value<br>
> of the id variable must be an number exactly 3 digits long with no<br>
> zeros. Any attempt to send a value other<br>
> than that will generate an error message. The CGI code does not force<br>
> the use of validation.<br>
> <br>
> Validation like this will be further expanded in 5.4 with the addition<br>
> of a new validation object. So you'd see <br>
> something like:<br>
> <br>
> LAYER<br>
> ...<br>
> VALIDATION<br>
> 'id' '^[0-9]{3}$<br>
> END<br>
> END<br>
> <br>
> Steve<br>
> <br>
> >>> On 1/26/2009 at 8:47 AM, in message<br>
> <6246727221874A4FB8D3F9BBC37D9BD5056DA174@s-sp22.pca.state.mn.us>,<br>
> "Fawcett,<br>
> David" <David.Fawcett@state.mn.us> wrote:<br>
> > Of course, part of security is also having your application hit
your<br>
> database <br>
> > as a user that only has the rights that it needs. If your
user only<br>
> has <br>
> > select rights on only the data that you want to expose, that
should<br>
> help <br>
> > limit some of these issues.<br>
> > <br>
> > -----Original Message-----<br>
> > From: mapserver-users-bounces@lists.osgeo.org <br>
> > [mailto:mapserver-users-bounces@lists.osgeo.org] On Behalf Of
<br>
> > umn-ms@hydrotec.de <br>
> > Sent: Monday, January 26, 2009 4:43 AM<br>
> > To: MapServer<br>
> > Subject: Re: [mapserver-users] Dynamin SQL with
mapserver CGI?<br>
> > <br>
> > <br>
> > <br>
> > > Not any great hazard, I believe, ... <br>
> > <br>
> > Mmh. I'd be cautious. <br>
> > <br>
> > Example: <br>
> > * Mapfile: <br>
> > DATA "the_geom from buildings"<br>
> > <br>
> > * Set Filter via URL to this: <br>
> > 1=1);DELETE FROM OTHERTABLE; DECLARE X BINARY
CURSOR FOR<br>
> SELECT * from <br>
> > buildings WHERE (1=1 <br>
> > <br>
> > I think Mapserver will create the following statements:
(I've<br>
> added <br>
> > newlines) <br>
> > DECLARE mycursor BINARY CURSOR FOR SELECT the_geom
from<br>
> buildings WHERE <br>
> > (1=1); <br>
> > DELETE FROM OTHERTABLE; <br>
> > DECLARE X BINARY CURSOR FOR SELECT * from buildings
WHERE (1=1)<br>
> and (%s && <br>
> > setSRID( ...) ) <br>
> > <br>
> > Mapserver calls PQExec with these statements. PQExec
will<br>
> execute every <br>
> > statement and will return <br>
> > the results of the last one. <br>
> > <br>
> > Bye <br>
> > Benedikt Rothe <br>
> > <br>
> > <br>
> > "Rahkonen Jukka" <Jukka.Rahkonen@mmmtike.fi>
schrieb am<br>
> 26.01.2009 09:34:31:<br>
> > <br>
> > > Hi, <br>
> > > <br>
> > > Not any great hazard, I believe, if it means
that user can<br>
> normally <br>
> > > get all the features, but only a subset when
filter is set. <br>
> It is <br>
> > > different case if DATA clause is manipulated,
and therefore<br>
> that <br>
> > > must be connected to DATAPATTERN. <br>
> > > <br>
> > > -Jukka Rahkonen- <br>
> > > <br>
> > > Lähettäjä: mapserver-users-bounces@lists.osgeo.org
[mailto:<br>
> > > mapserver-users-bounces@lists.osgeo.org] Puolesta<br>
> umn-ms@hydrotec.de <br>
> > > Lähetetty: 26. tammikuuta 2009 10:03<br>
> > > Vastaanottaja: MapServer<br>
> > > Aihe: Re: [mapserver-users] Dynamin SQL with
mapserver CGI?<br>
> > <br>
> > > <br>
> > > Hi <br>
> > > <br>
> > > > You can use a replaceable parameter in
the FILTER clause if<br>
> all you ... <br>
> > > This introduces the hazard of SQL-Injection,
doesn't it? <br>
> > > <br>
> > > Bye <br>
> > > Benedikt Rothe <br>
> > > <br>
> > > mapserver-users-bounces@lists.osgeo.org schrieb
am 24.01.2009<br>
> 14:04:42:<br>
> > > <br>
> > > > On Sat, Jan 24, 2009 at 3:18 AM, Saka
Royban<br>
> <srph124@yahoo.com> wrote:<br>
> > > > > Hi all<br>
> > > > > I'm looking for a way to change SQL
dynamically via URL<br>
> parameters. it<br>
> > > > > sounds from doc that changing DATA
element in map file is<br>
> impossible. Is<br>
> > > > > there any other way?<br>
> > > > <br>
> > > > You can use a replaceable parameter in
the FILTER clause if<br>
> all you<br>
> > > > want to do is alter the WHERE clause.
So for example:<br>
> > > > FILTER "%criteria%"<br>
> > > > and<br>
> > > > criteria=id='value'<br>
> > > > would work with a database like Postgres.<br>
> > > > <br>
> > > > When working with a database you put the
whole SQL WHERE<br>
> clause in the<br>
> > > > FILTER, whereas with shapefiles or ORG
data sources you use<br>
> the<br>
> > > > FILTERITEM and FILTER.<br>
> > > > <br>
> > > > -- <br>
> > > > Richard Greenwood<br>
> > > > richard.greenwood@gmail.com <br>
> > > > www.greenwoodmap.com <br>
> > > > _______________________________________________<br>
> > > > mapserver-users mailing list<br>
> > > > mapserver-users@lists.osgeo.org <br>
> > > > http://lists.osgeo.org/mailman/listinfo/mapserver-users<br>
</font></tt>