Thanks for the research, I hope folks will take it to heart and use the validation options. That's why they're there. Of course, one needs to write good patterns. I'm planning a how-to accompanying the new validation support in 5.4.
Steve >>> <[email protected]> 01/27/09 2:20 AM >>> I think" validation patterns" are a real solution to the problem and minimizing access-priviliges is not. When filter with URL-substitution is used without validation patterns, one relies to heavily on the security-system of postgres. This is acceptable in most intranets but hazardous in the internet. Look for example at http://www.postgresql.org/support/security.html to see, what can be done with even a minimal-postgres-login. But again: Everything's fine with "validation patterns" ... Ciao Benedikt Extract of the http://www.postgresql.org/support/security.html * 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. * 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 * 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. * 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 "Steve Lime" <[email protected]> schrieb am 26.01.2009 21:29:52: > In addition, one can and should apply validation patterns to variables > used in SQL. That way MapServer > can test the input data before handing off to PostGIS or whatever. > > These patterns are set in LAYER metadata. For example: > > LAYER > ... > DATA"'the_geom FROM (SELECT the_geom FROM my_table WHERE ID = '%id%') > as foo USING UNIQUE OID" > METADATA > id_validation_pattern '^[0-9]{3}$' > END > END > > This tells the CGI to test the request parameter against the regex > '^[1-9]{3}$'. The regex says that the value > of the id variable must be an number exactly 3 digits long with no > zeros. Any attempt to send a value other > than that will generate an error message. The CGI code does not force > the use of validation. > > Validation like this will be further expanded in 5.4 with the addition > of a new validation object. So you'd see > something like: > > LAYER > ... > VALIDATION > 'id' '^[0-9]{3}$ > END > END > > Steve > > >>> On 1/26/2009 at 8:47 AM, in message > <[email protected]>, > "Fawcett, > David" <[email protected]> wrote: > > Of course, part of security is also having your application hit your > database > > as a user that only has the rights that it needs. If your user only > has > > select rights on only the data that you want to expose, that should > help > > limit some of these issues. > > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of > > [email protected] > > Sent: Monday, January 26, 2009 4:43 AM > > To: MapServer > > Subject: Re: [mapserver-users] Dynamin SQL with mapserver CGI? > > > > > > > > > Not any great hazard, I believe, ... > > > > Mmh. I'd be cautious. > > > > Example: > > * Mapfile: > > DATA "the_geom from buildings" > > > > * Set Filter via URL to this: > > 1=1);DELETE FROM OTHERTABLE; DECLARE X BINARY CURSOR FOR > SELECT * from > > buildings WHERE (1=1 > > > > I think Mapserver will create the following statements: (I've > > > DELETE FROM OTHERTABLE; > > DECLARE X BINARY CURSOR FOR SELECT * from buildings WHERE (1=1) > and (%s && > > setSRID( ...) ) > > > > Mapserver calls PQExec with these statements. PQExec will > execute every > > statement and will return > > the results of the last one. > > > > Bye > > Benedikt Rothe > > > > > > "Rahkonen Jukka" <[email protected]> schrieb am > 26.01.2009 09:34:31: > > > > > Hi, > > > > > > Not any great hazard, I believe, if it means that user can > normally > > > get all the features, but only a subset when filter is set. > It is > > > different case if DATA clause is manipulated, and therefore > that > > > must be connected to DATAPATTERN. > > > > > > -Jukka Rahkonen- > > > > > > Lähettäjä: [email protected] [mailto: > > > [email protected]] Puolesta > [email protected] > > > Lähetetty: 26. tammikuuta 2009 10:03 > > > Vastaanottaja: MapServer > > > Aihe: Re: [mapserver-users] Dynamin SQL with mapserver CGI? > > > > > > > > Hi > > > > > > > You can use a replaceable parameter in the FILTER clause if > all you ... > > > This introduces the hazard of SQL-Injection, doesn't it? > > > > > > Bye > > > Benedikt Rothe > > > > > > [email protected] schrieb am 24.01.2009 > 14:04:42: > > > > > > > On Sat, Jan 24, 2009 at 3:18 AM, Saka Royban > <[email protected]> wrote: > > > > > Hi all > > > > > I'm looking for a way to change SQL dynamically via URL > parameters. it > > > > > sounds from doc that changing DATA element in map file is > impossible. Is > > > > > there any other way? > > > > > > > > You can use a replaceable parameter in the FILTER clause if > all you > > > > want to do is alter the WHERE clause. So for example: > > > > FILTER "%criteria%" > > > > and > > > > criteria=id='value' > > > > would work with a database like Postgres. > > > > > > > > When working with a database you put the whole SQL WHERE > clause in the > > > > FILTER, whereas with shapefiles or ORG data sources you use > the > > > > FILTERITEM and FILTER. > > > > > > > > -- > > > > Richard Greenwood > > > > [email protected] > > > > www.greenwoodmap.com > > > > _______________________________________________ > > > > mapserver-users mailing list > > > > [email protected] > > > > http://lists.osgeo.org/mailman/listinfo/mapserver-users _______________________________________________ mapserver-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapserver-users
