[Geoserver-users] GeoServer CQL Filter access to Oracle -- returned ORA-01722 invalid number

Hi,

The service exceptions may also contain messages from the java code for example NPE messages or something like this

<?xml version="1.0" ?>

<ServiceExceptionReport

version=“1.2.0”

xmlns=“http://www.opengis.net/ogc

xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance

xsi:schemaLocation=“http://www.opengis.net/ogc http://schemas.opengis.net/wfs/1.0.0/OGC-exception.xsd”>

java.lang.RuntimeException: Parsing failed for DIAMETRE: java.lang.NumberFormatException

Parsing failed for DIAMETRE: java.lang.NumberFormatException

null

In this case the content of the message may be as WFS 1.0.0 standard puts it “The content of the element is an exception message

that the service wished to convey to the client application”.

-Jukka Rahkonen-

···

Jody Garnett wrote:

In a perfect world the ServiceException would only return information when the client has made the mistake incorrectly, in this case the ServiceException looks to be due to a configuration problem with your data store?

That is a tricky one, you can cut down on the information returned during server configuration

There are a couple global settings about service exception here:about).

Try that, if your admin is still not satisfied you will need to do a code audit of the “JDBC DataStore” code and submit a patch masking any SQL Exception information that is passed back:

If have you a team in place to do the work we would love the participation, if not check out the commercial support page.

a) The formal approach would be to introduce strict error codes (also used for translation) and provide a “minimal” translation of the error codes for use in production.

b) The quick band-aid would be to patch where GeoServer produces a ServiceException document and force it to provide no details of the mistake.

Normally a web service service would return an HTTP 500 Internal Server Error or something. An OGC WebService can actually return a HTTP 200 OK response that contains a ServiceException document.

Jody Garnett

On Thu, Jun 5, 2014 at 5:58 AM, Aijun Chen <aijunchen@…84…> wrote:

Hi,

We are using GeoServer WFS to serve Vector Data that are stored in Oracle Database in backend.

The WFS request directly returned errors that produced by Oracl DB to final users.

For example, when we submitted below WFS request to any GeoServer instance:

http://geoserver.domain.name/GeoServer/wfs?service=WFS&version=1.0.0&request=GetFeature&outputFormat=json&srsName=EPSG:4326&typeName=YOUR_LAYERNAME&cql_filter=1='string

The GeoServer returned below errors to final users if backend database is Oracle (I did not have a chance to test PostGIS as backend database):

java.lang.RuntimeException: java.io.IOException java.io.IOException null ORA-01722: invalid number

This error directly discloses backend database information to final users.

Our security guys think that this is a secure vulnerability and we need fix it.

Considering that this error is directly returned by GeoServer.

I am seeking any comments/suggestion/advises from users and developers from GeoServer community to see if there is any way that we can fix this issue.

Any responses are highly appreciated!

Anderson Chen,


Learn Graph Databases - Download FREE O’Reilly Book
“Graph Databases” is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech


Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

On Thu, Jun 5, 2014 at 11:50 AM, Rahkonen Jukka (Tike) <
jukka.rahkonen@anonymised.com> wrote:

Hi,

The service exceptions may also contain messages from the java code for
example NPE messages or something like this

<?xml version="1.0" ?>

<ServiceExceptionReport

   version="1.2.0"

   xmlns="http://www.opengis.net/ogc&quot;

   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;

   xsi:schemaLocation="http://www.opengis.net/ogc
http://schemas.opengis.net/wfs/1.0.0/OGC-exception.xsd&quot;&gt;

   <ServiceException>

      java.lang.RuntimeException: Parsing failed for DIAMETRE:
java.lang.NumberFormatException

Parsing failed for DIAMETRE: java.lang.NumberFormatException

null

</ServiceException></ServiceExceptionReport>

In this case the content of the message may be as WFS 1.0.0 standard puts
it “The content of the element is an exception message

that the service wished to convey to the client application”.

Unfortunately many exceptions are not classified in a way that lets the
code know if the issue was a user problem or
an internal error, so all we can do to hide the details without significant
refactoring is to tell the user "something went wrong" ...
which of course would not be that useful.

Cheers
Andrea

--

Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

Yep, hence the (admittedly massive) amount of work to bust out formal error messages for ServiceException. GeoServer would then be stuck only returning the “cleaned” messages provided by an official ServiceException, or doing the stack trace thing showing the initial cause if “verbose” exceptions was turned on.

There is no easy way to turn off these messages (that reveal details of your database or the structure of the geoserver app). We know what to do from a project standpoint, but lack funds/mandate to make it happen. Incidentally this is the same approach used by the darn oracle driver which makes Java developers uncomfortable every time they catch an oracle exception and have to look up the ORA number to decide how to react.

TLDR: Your security guys won’t be happy, but you turn off verbose logging for a small improvement

···

Jody Garnett

On Thu, Jun 5, 2014 at 8:06 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:


Learn Graph Databases - Download FREE O’Reilly Book
“Graph Databases” is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech


Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

On Thu, Jun 5, 2014 at 11:50 AM, Rahkonen Jukka (Tike) <jukka.rahkonen@anonymised.com> wrote:

Hi,

The service exceptions may also contain messages from the java code for example NPE messages or something like this

<?xml version="1.0" ?>

<ServiceExceptionReport

version=“1.2.0”

xmlns=“http://www.opengis.net/ogc

xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance

xsi:schemaLocation=“http://www.opengis.net/ogc http://schemas.opengis.net/wfs/1.0.0/OGC-exception.xsd”>

java.lang.RuntimeException: Parsing failed for DIAMETRE: java.lang.NumberFormatException

Parsing failed for DIAMETRE: java.lang.NumberFormatException

null

In this case the content of the message may be as WFS 1.0.0 standard puts it “The content of the element is an exception message

that the service wished to convey to the client application”.

Unfortunately many exceptions are not classified in a way that lets the code know if the issue was a user problem or
an internal error, so all we can do to hide the details without significant refactoring is to tell the user “something went wrong” …
which of course would not be that useful.

Cheers
Andrea

==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


On Thu, Jun 5, 2014 at 12:24 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

Yep, hence the (admittedly massive) amount of work to bust out formal
error messages for ServiceException. GeoServer would then be stuck only
returning the "cleaned" messages provided by an official ServiceException,
or doing the stack trace thing showing the initial cause if "verbose"
exceptions was turned on.

One observation, there is a still somewhat small but growing set of
ServiceException that are thrown setting
the locator and code, those could be already be classfied in some way,
e.g., if I see the code is InvalidSRS then
I know the error message is likely safe to return, whilst if the code is
"internalError" or not available at all,
the message might contain some information that ought to be restricted (or
maybe not... the large refactor would
indeed have to be done in order to make sure the code is available for all
exceptions, and we have a way to
know if a certain code represents a user error, or an internal error)

Cheers
Andrea

--

Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------