<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.16788" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=524104114-27012009><FONT face=Arial color=#0000ff
size=2>Right. </FONT></SPAN></DIV>
<DIV><SPAN class=524104114-27012009><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=524104114-27012009><FONT face=Arial color=#0000ff size=2>I
believe that several layers to the onion are good. </FONT></SPAN></DIV>
<DIV><SPAN class=524104114-27012009><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=524104114-27012009><FONT face=Arial color=#0000ff size=2>In
other words, I wouldn't have my Web application logging into my db as the admin
user even if I was using validation on my input.</FONT></SPAN></DIV>
<DIV><SPAN class=524104114-27012009><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=524104114-27012009><FONT face=Arial color=#0000ff
size=2>David.</FONT></SPAN></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B>
mapserver-users-bounces@lists.osgeo.org
[mailto:mapserver-users-bounces@lists.osgeo.org] <B>On Behalf Of
</B>umn-ms@hydrotec.de<BR><B>Sent:</B> Tuesday, January 27, 2009 2:14
AM<BR><B>To:</B> MapServer<BR><B>Cc:</B> Steve Lime; David
Fawcett<BR><B>Subject:</B> RE: [mapserver-users] Dynamin SQL with mapserver
CGI?<BR><BR></FONT></DIV><BR><FONT face=sans-serif size=2>I think validation
patterns are a real solution to the problem and minimizing access-priviliges
is not.</FONT> <BR><BR><FONT face=sans-serif size=2>When filter with
URL-substitution is used without validation patterns, one relies on the
security-system of postgres. </FONT><BR><FONT face=sans-serif size=2>This is
acceptable in most intranets but hazardous in the internet.</FONT> <BR><FONT
face=sans-serif size=2>Look for example at
http://www.postgresql.org/support/security.html what can be done with even a
minimal-postgres-login</FONT> <BR><BR><FONT face=sans-serif size=2>Ciao</FONT>
<BR><FONT face=sans-serif size=2>Benedikt</FONT> <BR><BR><FONT face=sans-serif
size=2>Extract of the http://www.postgresql.org/support/security.html</FONT>
<BR><FONT face=sans-serif size=2>* </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 face=sans-serif size=2>*
</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 face=sans-serif
size=2>* </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 face=sans-serif
size=2>* </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></BLOCKQUOTE></FONT></TT></BODY></HTML>