[Geoserver-devel] Bug with single quote in feature fields?

GeoServer GeoServer Developer
,
1

Hello Geoserver developers,

When modifying a feature element (text field) with a single quote in it, the following error is logged:

  08-Nov-2007 09:05:11 org.geotools.data.postgis.PostgisFeatureStore modifyFeatures
  WARNING: Some sort of database connection error: ERROR: syntax error at or near "t"

The WFS-T request is:

  <wfs:Transaction xmlns:wfs="http://www.opengis.net/wfs&quot; service="WFS" version="1.0.0">
    <wfs:Update typeName="west:features">
      <ogc:Filter xmlns:ogc="http://www.opengis.net/ogc&quot;&gt;
        <ogc:FeatureId fid="features.588" />
      </ogc:Filter>
      <wfs:Property>
        <wfs:Name>west:name</wfs:Name>
        <wfs:Value>test</wfs:Value>
      </wfs:Property>
      <wfs:Property>
        <wfs:Name>west:geoLocation</wfs:Name>
        <wfs:Value>
          <gml:Point xmlns:gml="http://www.opengis.net/gml&quot; srsName="http://www.opengis.net/gml/srs/epsg\.xml\#4326&quot;&gt;
            <gml:coordinates decimal="." cs="," ts="">1.5,55.2625</gml:coordinates>
          </gml:Point>
        </wfs:Value>
      </wfs:Property>
      <wfs:Property>
        <wfs:Name>west:text</wfs:Name>
        <wfs:Value>don't panic</wfs:Value>
      </wfs:Property>
    </wfs:Update>
  </wfs:Transaction>

The response is:

  <wfs:WFS_TransactionResponse version="1.0.0" xmlns:wfs="http://www.opengis.net/wfs&quot; xmlns:ogc="http://www.opengis.net/ogc&quot; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xsi:schemaLocation="http://www.opengis.net/wfs http://localhost:8080/geoserver/schemas/wfs/1.0.0/WFS-transaction.xsd&quot;&gt; <wfs:TransactionResult> <wfs:Status> <wfs:FAILED/> </wfs:Status> <wfs:Message>Some sort of database connection error: ERROR: syntax error at or near &quot;t&quot;</wfs:Message> </wfs:TransactionResult></wfs:WFS_TransactionResponse>

The feature definition in PostGIS is:

                                                  Table "public.features"
                 Column | Type | Modifiers
  ------------------------------------+--------------------------+------------------------------------------------------
   oid | integer | not null default nextval('features_oid_seq'::regclass)
   name | character varying |
   geoLocation | geometry |
   text | character varying |
  Indexes:
      "features_pkey" PRIMARY KEY, btree (oid)
  Check constraints:
      "enforce_dims_geoLocation" CHECK (ndims("geoLocation") = 2)
      "enforce_geotype_geoLocation" CHECK (geometrytype("geoLocation") = 'POINT'::text OR "geoLocation" IS NULL)
      "enforce_srid_geoLocation" CHECK (srid("geoLocation") = 4326)

Is this a known bug?

Regards,
--
-- Gertjan van Oosten, gertjan@anonymised.com, West Consulting B.V., +31 15 2191 600

2

As quoted from Gertjan van Oosten <gertjan@anonymised.com>:

When modifying a feature element (text field) with a single quote in it, the following error is logged:

  08-Nov-2007 09:05:11 org.geotools.data.postgis.PostgisFeatureStore modifyFeatures
  WARNING: Some sort of database connection error: ERROR: syntax error at or near "t"

[...]

Is this a known bug?

Forgot to mention: this is with geoserver-1.5.4a.

Regards,
--
-- Gertjan van Oosten, gertjan@anonymised.com, West Consulting B.V., +31 15 2191 600

3

Hi Gertjan,

unfortunately it seems like a silly bug. At some point I hope jdbc datastores
to use jdbc prepared statements to properly set query parameters instead of
the scary encoding to a plain select string, though not sure if there's a
reason not to have done it so far.

The best you could do is to throw a jira bug report for the "data postgis"
module http://jira.codehaus.org/browse/GEOT so the module maintainer catches
it up and don't forget.

Cheers,

Gabriel.

On Thursday 08 November 2007 10:17:09 am Gertjan van Oosten wrote:

Hello Geoserver developers,

When modifying a feature element (text field) with a single quote in it,
the following error is logged:

  08-Nov-2007 09:05:11 org.geotools.data.postgis.PostgisFeatureStore
modifyFeatures WARNING: Some sort of database connection error: ERROR:
syntax error at or near "t"

The WFS-T request is:

  <wfs:Transaction xmlns:wfs="http://www.opengis.net/wfs&quot; service="WFS"
version="1.0.0"> <wfs:Update typeName="west:features">
      <ogc:Filter xmlns:ogc="http://www.opengis.net/ogc&quot;&gt;
        <ogc:FeatureId fid="features.588" />
      </ogc:Filter>
      <wfs:Property>
        <wfs:Name>west:name</wfs:Name>
        <wfs:Value>test</wfs:Value>
      </wfs:Property>
      <wfs:Property>
        <wfs:Name>west:geoLocation</wfs:Name>
        <wfs:Value>
          <gml:Point xmlns:gml="http://www.opengis.net/gml&quot;
srsName="http://www.opengis.net/gml/srs/epsg.xml#4326&quot;&gt; <gml:coordinates
decimal="." cs="," ts="">1.5,55.2625</gml:coordinates> </gml:Point>
        </wfs:Value>
      </wfs:Property>
      <wfs:Property>
        <wfs:Name>west:text</wfs:Name>
        <wfs:Value>don't panic</wfs:Value>
      </wfs:Property>
    </wfs:Update>
  </wfs:Transaction>

The response is:

  <wfs:WFS_TransactionResponse version="1.0.0"
xmlns:wfs="http://www.opengis.net/wfs&quot;
xmlns:ogc="http://www.opengis.net/ogc&quot;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
xsi:schemaLocation="http://www.opengis.net/wfs
http://localhost:8080/geoserver/schemas/wfs/1.0.0/WFS-transaction.xsd&quot;&gt;
<wfs:TransactionResult> <wfs:Status> <wfs:FAILED/> </wfs:Status>
<wfs:Message>Some sort of database connection error: ERROR: syntax error at
or near &quot;t&quot;</wfs:Message>
</wfs:TransactionResult></wfs:WFS_TransactionResponse>

The feature definition in PostGIS is:

                                                  Table "public.features"
                 Column | Type |
            Modifiers
------------------------------------+--------------------------+-----------
------------------------------------------- oid
  | integer | not null default
nextval('features_oid_seq'::regclass) name |
character varying | geoLocation | geometry
             | text | character varying
| Indexes:
      "features_pkey" PRIMARY KEY, btree (oid)
  Check constraints:
      "enforce_dims_geoLocation" CHECK (ndims("geoLocation") = 2)
      "enforce_geotype_geoLocation" CHECK (geometrytype("geoLocation") =
'POINT'::text OR "geoLocation" IS NULL) "enforce_srid_geoLocation" CHECK
(srid("geoLocation") = 4326)

Is this a known bug?

Regards,

4

Hi Gabriel,

As quoted from Gabriel Roldán <gabriel.roldan@anonymised.com>:

unfortunately it seems like a silly bug. At some point I hope jdbc datastores
to use jdbc prepared statements

What?!? It's been a while since I looked at the code, but do you mean
to say it's not using PreparedStatement? Unbelievable!

The best you could do is to throw a jira bug report for the "data postgis"
module http://jira.codehaus.org/browse/GEOT so the module maintainer catches
it up and don't forget.

Done as http://jira.codehaus.org/browse/GEOT-1573
Since I have no clue which version of gt2 is used by GeoServer 1.5.4a
(seems to be 2.3.5 but I am not sure), I did not fill in the affected
version (nor the fix version), just as a reminder filled in "GeoServer
1.5.4a" in the environment. Someone needs to complete that.

Regards,
--
-- Gertjan van Oosten, gertjan@anonymised.com, West Consulting B.V., +31 15 2191 600

5

On Friday 09 November 2007 03:48:03 pm Gertjan van Oosten wrote:

Hi Gabriel,

As quoted from Gabriel Roldán <gabriel.roldan@anonymised.com>:
> unfortunately it seems like a silly bug. At some point I hope jdbc
> datastores to use jdbc prepared statements

What?!? It's been a while since I looked at the code, but do you mean
to say it's not using PreparedStatement? Unbelievable!

I went quickly through the code before stating that and that was my
impression, though I might be wrong. Postgis anyone?

> The best you could do is to throw a jira bug report for the "data
> postgis" module http://jira.codehaus.org/browse/GEOT so the module
> maintainer catches it up and don't forget.

Done as http://jira.codehaus.org/browse/GEOT-1573
Since I have no clue which version of gt2 is used by GeoServer 1.5.4a
(seems to be 2.3.5 but I am not sure), I did not fill in the affected
version (nor the fix version), just as a reminder filled in "GeoServer
1.5.4a" in the environment. Someone needs to complete that.

done. thanks for reporting.

Gabriel.

Regards,

6

On Fri, November 9, 2007 3:58 pm, Gabriel Roldán wrote:

On Friday 09 November 2007 03:48:03 pm Gertjan van Oosten wrote:

Hi Gabriel,

As quoted from Gabriel Roldán <gabriel.roldan@anonymised.com>:

unfortunately it seems like a silly bug. At some point I hope jdbc
datastores to use jdbc prepared statements

What?!? It's been a while since I looked at the code, but do you mean
to say it's not using PreparedStatement? Unbelievable!

I went quickly through the code before stating that and that was my
impression, though I might be wrong. Postgis anyone?

I can confirm that. Only the Oracle data store uses prepared statements,
and only to set the geometry (the other parameters are still set in the
query manually).

There have been talks about switching to prepared statement usage but
since that would be a major change it would require some sponsoring...

Cheers
Andrea

7

As quoted from aaime@anonymised.com:

On Fri, November 9, 2007 3:58 pm, Gabriel Roldán wrote:
> On Friday 09 November 2007 03:48:03 pm Gertjan van Oosten wrote:
> > What?!? It's been a while since I looked at the code, but do you mean
> > to say it's not using PreparedStatement? Unbelievable!
>
> I went quickly through the code before stating that and that was my
> impression, though I might be wrong. Postgis anyone?

I can confirm that.

Some remarks:

1. Note to self: check out the source and do an svn blame to see who was
   the one to decide not to use PreparedStatement and put them on our
   list of programmers not to hire.

2. At geoserver-1.5 this bug is still present. Scary. This can mean
   several things:
   a. GeoTools/GeoServer is hardly used;
   b. nobody uses a real database as a feature store;
   c. nobody has ever tried using single quotes in one of their feature
      elements.

Especially 2c I can hardly believe; I myself was born in a city that has
a single quote in its name (yes, we get those in the Netherlands, like
's-Gravenhage); does *nobody* store this stuff inside a real database?

Enjoy your weekend all. :wink:

--
-- Gertjan van Oosten, gertjan@anonymised.com, West Consulting B.V., +31 15 2191 600

8

Gertjan van Oosten ha scritto:

As quoted from aaime@anonymised.com:

On Fri, November 9, 2007 3:58 pm, Gabriel Roldán wrote:

On Friday 09 November 2007 03:48:03 pm Gertjan van Oosten wrote:

What?!? It's been a while since I looked at the code, but do you mean
to say it's not using PreparedStatement? Unbelievable!

I went quickly through the code before stating that and that was my
impression, though I might be wrong. Postgis anyone?

I can confirm that.

Some remarks:

1. Note to self: check out the source and do an svn blame to see who was
   the one to decide not to use PreparedStatement and put them on our
   list of programmers not to hire.

Ha, bold statement. That decision was not taken yesterday, more like 5
years ago. Maybe if you were on board helping we would not have made
that mistake :slight_smile:

2. At geoserver-1.5 this bug is still present. Scary. This can mean
   several things:
   a. GeoTools/GeoServer is hardly used;
   b. nobody uses a real database as a feature store;
   c. nobody has ever tried using single quotes in one of their feature
      elements.

Especially 2c I can hardly believe; I myself was born in a city that has
a single quote in its name (yes, we get those in the Netherlands, like 's-Gravenhage); does *nobody* store this stuff inside a real database?

Evidently GeoServer is not very used in Netherlands. We have plenty of
users around the world and your issue is not a common complaint.
I fully agree it's a bug and it should be fixed, and I also agree when
you say prepared statement should be used, but who's gonna pay for
those changes? (both making them and fixing the bugs that arise after
the change?).

I understand your frustration, but this attitude of yours is not really
making it easy to go and try to fix the issue right away.

Cheers
Andrea

9

Hi Andrea,

Quite lenghty reply and slightly digressing from the original issue;
none of this is in any way a personal attack on anyone in particular.
Please spray liberally with freshly ground sea salt. :slight_smile:

As quoted from Andrea Aime <aaime@anonymised.com>:

> 1. Note to self: check out the source and do an svn blame to see who was
> the one to decide not to use PreparedStatement and put them on our
> list of programmers not to hire.

Ha, bold statement. That decision was not taken yesterday, more like 5
years ago. Maybe if you were on board helping we would not have made
that mistake :slight_smile:

I'll take that in the spirit in which it was meant. :wink:
But seriously, I recall from ca. 1997/1998 discussions on why you should
use PreparedStatement, so by 2002 this was already widely known I guess.

Evidently GeoServer is not very used in Netherlands. We have plenty of
users around the world and your issue is not a common complaint.

That's what surprises me, because if you use an SQL datastore, and have
a text field in your feature type, and want to enter a single quote in
such a field, you would most likely hit upon the bug.
As a software architect and consultant such information is important to
me. It allows me to better decide what the strengths and, unfortunately,
weaknesses of GeoServer are, and when it is (in)appropriate to use it in
a project.

I fully agree it's a bug and it should be fixed,

I don't doubt that.

and I also agree when you say prepared statement should be used, but
who's gonna pay for those changes?

Well, I haven't yet had a chance to look at the source code, but my gut
feeling is that it could quite possibly be serious: GeoServer could have
a security hole of the SQL injection type. That's bad. Asking for
sponsoring to have that fixed might be considered by some to be somewhat
of a brutality. But I get your point, there's always a trade-off.[*]

(both making them and fixing the bugs that arise after the change?).

And hope you have unit tests that catch them...

I understand your frustration, but this attitude of yours is not really
making it easy to go and try to fix the issue right away.

I'm guessing you read more into my words than I put into them, but such
is the nature of e-mail, alas. My natural attitude tends to be on the
constructive side (as I hope shows through on other posts to this list).
And myself and the company that employs me can hardly be called leeches;
we have been into open source from when the term hadn't been invented
yet and it was still called comp.sources.unix. :wink:

[*] On a related subject: I have recently been trying to convince people
    that the CMMI process area Supplier Agreement Management applies to
    open source as well, especially in the view of sponsored development.
    Hopefully this catches on and people start reserving some project
    money for getting things done on open source software. For
    instance, you could conceivably choose between a. paying a group of
    open source developers for a certain feature or b. sending all your
    money to a commercial vendor of a similar tool.

Kind regards,
--
-- Gertjan van Oosten, gertjan@anonymised.com, West Consulting B.V., +31 15 2191 600

10

On Friday 09 November 2007 16:08:58 aaime@anonymised.com wrote:

On Fri, November 9, 2007 3:58 pm, Gabriel Roldán wrote:
> On Friday 09 November 2007 03:48:03 pm Gertjan van Oosten wrote:
>> Hi Gabriel,
>>
>> As quoted from Gabriel Roldán <gabriel.roldan@anonymised.com>:
>>> unfortunately it seems like a silly bug. At some point I hope
>>> jdbc datastores to use jdbc prepared statements
>>
>> What?!? It's been a while since I looked at the code, but do you
>> mean to say it's not using PreparedStatement? Unbelievable!
>
> I went quickly through the code before stating that and that was my
> impression, though I might be wrong. Postgis anyone?

I can confirm that. Only the Oracle data store uses prepared
statements, and only to set the geometry (the other parameters are
still set in the query manually).

There have been talks about switching to prepared statement usage but
since that would be a major change it would require some
sponsoring...

Changing the code to properly escape strings may well be achievable
though, and probably should be done ASAP. As Gertjan said, this sounds
like an SQL injection attack waiting to happen.

Lourens
--
ir. Lourens Veen University of Amsterdam - IBED
Nieuwe Achtergracht 166
Scientific Software Engineer 1018 WV Amsterdam, The Netherlands
EcoGRID-GAN t: +31 20-5257453 f: +31 20-5257431

11

Lourens Veen ha scritto:

On Friday 09 November 2007 16:08:58 aaime@anonymised.com wrote:

On Fri, November 9, 2007 3:58 pm, Gabriel Roldán wrote:

On Friday 09 November 2007 03:48:03 pm Gertjan van Oosten wrote:

Hi Gabriel,

As quoted from Gabriel Roldán <gabriel.roldan@anonymised.com>:

unfortunately it seems like a silly bug. At some point I hope
jdbc datastores to use jdbc prepared statements

What?!? It's been a while since I looked at the code, but do you
mean to say it's not using PreparedStatement? Unbelievable!

I went quickly through the code before stating that and that was my
impression, though I might be wrong. Postgis anyone?

I can confirm that. Only the Oracle data store uses prepared
statements, and only to set the geometry (the other parameters are
still set in the query manually).

There have been talks about switching to prepared statement usage but
since that would be a major change it would require some
sponsoring...

Changing the code to properly escape strings may well be achievable though, and probably should be done ASAP. As Gertjan said, this sounds like an SQL injection attack waiting to happen.

Agreed. Yet this has to be fixed in all databases, so it's no piece
of cake either, especially given two of them (oracle, mysql) are in unmantained state, the postgis mantainer is in (well deserved) vacation
and the db2 mantainer has to be contacted before any change is made.
Are you sure escaping the single quote would prevent sql injection
attacks? Here is some description of the issue (with some comments
about escaping quotes):
http://ocliteracy.com/techtips/sql-injection.html

We'll see what we can do. The problem has been known for quite
a bit of time now, the reason it hasn't been addressed it's that
fixing this in all jdbc datastores is not easy, doing that without introducing side effects is non trivial either (our test suites
are in place, but they do usually catch some bugs, not all conceivable ones), and up until a couple of months ago it would have had quite
a performance impact too (prepared statements are either cached
and reused or in most dbs take a performance hit because there is
a first round trip to the db to check the sql is correct and to
setup the plan, and then another one to actually execute the
statement. We introduced a connection pool library that can cache
prepared statements only during the summer). See also:
http://jira.codehaus.org/browse/GEOS-597
http://jira.codehaus.org/browse/GEOT-219

Cheers
Andrea

12

Gertjan van Oosten ha scritto:

and I also agree when you say prepared statement should be used, but
who's gonna pay for those changes?

Well, I haven't yet had a chance to look at the source code, but my gut
feeling is that it could quite possibly be serious: GeoServer could have
a security hole of the SQL injection type. That's bad. Asking for
sponsoring to have that fixed might be considered by some to be somewhat
of a brutality. But I get your point, there's always a trade-off.[*]

Well, switching to prepared statements may require one week of work (maybe more). If nobody (including OpenPlans) is sponsoring that as real "work time", then it means some developer has to do it during the weekend, which means one month worth of weekends (or more). Would you
go to your family and say you're off limit for one month long because
"you got a bug to fix"? :slight_smile:
Cheers
Andrea

13

andrea++
I'm sure Gertjan has all the experience in the field he says to have and thus
I'm sure he didn't meant to be rude, and also I'm sure for that same bunch of
years of experience he has black sheeps of his own. Difference with open
source being they're not hidden and patches speak more than words.
So please let us keep the discussion technical and be sure we would be happy
to review and eventually apply any patch you might send, Gertjan.

Cheers,

Gabriel

On Saturday 10 November 2007 11:49:28 pm Andrea Aime wrote:

Gertjan van Oosten ha scritto:
>> and I also agree when you say prepared statement should be used, but
>> who's gonna pay for those changes?
>
> Well, I haven't yet had a chance to look at the source code, but my gut
> feeling is that it could quite possibly be serious: GeoServer could have
> a security hole of the SQL injection type. That's bad. Asking for
> sponsoring to have that fixed might be considered by some to be somewhat
> of a brutality. But I get your point, there's always a trade-off.[*]

Well, switching to prepared statements may require one week of work
(maybe more). If nobody (including OpenPlans) is sponsoring that as real
"work time", then it means some developer has to do it during the
weekend, which means one month worth of weekends (or more). Would you
go to your family and say you're off limit for one month long because
"you got a bug to fix"? :slight_smile:
Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

14

Gertjan van Oosten wrote:

Hi Andrea,

Quite lenghty reply and slightly digressing from the original issue;
none of this is in any way a personal attack on anyone in particular.
Please spray liberally with freshly ground sea salt. :slight_smile:

As quoted from Andrea Aime <aaime@anonymised.com>:

1. Note to self: check out the source and do an svn blame to see who was
   the one to decide not to use PreparedStatement and put them on our
   list of programmers not to hire.

Ha, bold statement. That decision was not taken yesterday, more like 5
years ago. Maybe if you were on board helping we would not have made
that mistake :slight_smile:

I'll take that in the spirit in which it was meant. :wink:
But seriously, I recall from ca. 1997/1998 discussions on why you should
use PreparedStatement, so by 2002 this was already widely known I guess.

Yeah, I think the developers at the time, of whom I was one, just weren't advanced JDBC coders. There were other silly mistakes, like rolling our own connection pooling code, when there were some open source projects. Some of those silly mistakes have been fixed over time, some haven't. Someone did point out the sql injection thing, and the prepared statement fix awhile ago. I got some patches working, but just against PostGIS, and all the changes need to go in the abstract classes that are inherited from. So I didn't want to do this big set of changes on a stable branch, and GeoServer usually is on a pretty stable branch.

So I keep scheduling the work to be done, but then other priorities take over, sexier ones that people will definitely go for. To be honest your raising the issue is definitely making me want to prioritize more. The weird thing is that very very few people have raised this issue. I'm not sure why. We are branching trunk soon, so that would be a good time to get this fix in.

Of course any volunteer time or funding to help test / code would be much appreciated, since at this point there are a lot of things that are higher on the priority for developers and organizations involved. I think my organization could put in significant inkind time if someone else were interested enough to get started.

best regards,

Chris

15

On Saturday 10 November 2007 23:43:25 you wrote:

Lourens Veen ha scritto:
> On Friday 09 November 2007 16:08:58 aaime@anonymised.com wrote:
>> On Fri, November 9, 2007 3:58 pm, Gabriel Roldán wrote:
>>> On Friday 09 November 2007 03:48:03 pm Gertjan van Oosten wrote:
>>>> Hi Gabriel,
>>>>
>>>> As quoted from Gabriel Roldán <gabriel.roldan@anonymised.com>:
>>>>> unfortunately it seems like a silly bug. At some point I hope
>>>>> jdbc datastores to use jdbc prepared statements
>>>>
>>>> What?!? It's been a while since I looked at the code, but do
>>>> you mean to say it's not using PreparedStatement? Unbelievable!
>>>
>>> I went quickly through the code before stating that and that was
>>> my impression, though I might be wrong. Postgis anyone?
>>
>> I can confirm that. Only the Oracle data store uses prepared
>> statements, and only to set the geometry (the other parameters are
>> still set in the query manually).
>>
>> There have been talks about switching to prepared statement usage
>> but since that would be a major change it would require some
>> sponsoring...
>
> Changing the code to properly escape strings may well be achievable
> though, and probably should be done ASAP. As Gertjan said, this
> sounds like an SQL injection attack waiting to happen.

Agreed. Yet this has to be fixed in all databases, so it's no piece
of cake either, especially given two of them (oracle, mysql) are in
unmantained state, the postgis mantainer is in (well deserved)
vacation and the db2 mantainer has to be contacted before any change
is made. Are you sure escaping the single quote would prevent sql
injection attacks? Here is some description of the issue (with some
comments about escaping quotes):
http://ocliteracy.com/techtips/sql-injection.html

Looking at the "mitigation" section of that page, a few things:

Sanitize the input: works nicely for email adresses, but we're talking
about generic strings that can in principle contain anything here. So
this doesn't apply. And if you are storing an integer type in a way
that allows it to contain "23 OR 1=1" then you have bigger problems (or
a non-typesafe language, which is such a problem :-), and then you do
have to check manually).

Escape/Quotesafe the input: right, jdbc.quote is your friend it seems.

We'll see what we can do. The problem has been known for quite
a bit of time now, the reason it hasn't been addressed it's that
fixing this in all jdbc datastores is not easy,

I understand that. The problem is that right now there's probably a
vulnerability in Geoserver, and the data I'm serving (or rather the
fine if it gets out unintended) is a bit too expensive to just ignore
that.

I've got it noted as something that needs fixing before I deliver the
product, and if noone else gets to it in the mean time I will probably
try to fix it locally at least for PostGIS.

Lourens

--
ir. Lourens Veen University of Amsterdam - IBED
Nieuwe Achtergracht 166
Scientific Software Engineer 1018 WV Amsterdam, The Netherlands
EcoGRID-GAN t: +31 20-5257453 f: +31 20-5257431