GeoServer

SQL query is shown in WFS response on error

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: 1.7.3
  • Fix Version/s: None
  • Component/s: Oracle, WFS
  • Labels:
    None
  • Environment:
    WFS and Oracle
  • Number of attachments :
    0

Description

I created a view in the database and created a feature type for that view.
After that I deleted the view.
When performing a WFS request on that feature type, instead of getting a (generic) error, I get an error with the precise SQL query that was being performed!

Why does an error in the backend result in the backend being exposed in the front-end!
This is a serious security bug and should never have allowed to happen!
When an error occurs on the backend, it should be logged and the requester (client) should be notified with an (nice) error message of geoserver (a code with/out a description) that briefly describes the kind of error that has occured, but not the actual error.

So I would like to see 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">
<ServiceException>
error:GEOS12345: Could not request the data from the system
</ServiceException></ServiceExceptionReport>

Instead of the current response:

<?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">
<ServiceException>
error:Translator error
Translator error
Error reading Features
Could not aquire feature:org.geotools.data.DataSourceException: Error Performing SQL query: SELECT &quot
;NAME", "CENTRE" FROM "VIEW" WHERE "NAME" = &apos
;GEM_CENTRE'
Error Performing SQL query: SELECT "NAME", "CENTRE" FROM "VIEW
" WHERE "NAME" = 'GEM_CENTRE'
ORA-00942: Tabel of view bestaat niet.

</ServiceException></ServiceExceptionReport>

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrea Aime added a comment - - edited

This cannot be critical for the project as a whole, since you're the only one that reported it in years, and error reporting has always been like this.
I understand it's critical for you, in that case if you need a swift fix either provide it, or have someone code a fix for you. I won't be easy, since there is no way to tell, given an exception, what the contents of the message might be. An easy solution would be to raise a flag that just reports back a generic error message, without telling the user what was wrong (invalid query, uknown feature type, and so on).
A slightly better patch could check the chain of causes in the exception and avoid reporting the problem if a SQLException is in the mix.

Show
Andrea Aime added a comment - - edited This cannot be critical for the project as a whole, since you're the only one that reported it in years, and error reporting has always been like this. I understand it's critical for you, in that case if you need a swift fix either provide it, or have someone code a fix for you. I won't be easy, since there is no way to tell, given an exception, what the contents of the message might be. An easy solution would be to raise a flag that just reports back a generic error message, without telling the user what was wrong (invalid query, uknown feature type, and so on). A slightly better patch could check the chain of causes in the exception and avoid reporting the problem if a SQLException is in the mix.
Hide
Permalink
Ben Caradoc-Davies added a comment -

The current behaviour is very useful for troubleshooting, so I would be reluctant to see it removed.

Optional sanitisation of exceptions would be OK, and would help reduce information available to attackers trying to inject SQL.

Show
Ben Caradoc-Davies added a comment - The current behaviour is very useful for troubleshooting, so I would be reluctant to see it removed. Optional sanitisation of exceptions would be OK, and would help reduce information available to attackers trying to inject SQL.
Hide
Permalink
Andrea Aime added a comment -

Oracle and Postgres JDBC-NG datastores are using prepared statements by default, this makes, to my knoledge, sql-injection attack impossible, thought there is a heavy performance price to pay if the tables are not organised on the spatial index and the requests tend to extract full(ish) data dumps. There is a 2-4 times slowdown compared to issuing a straight sql request (non prepared).
Anyways, even in the old ones, there is escaping in place, some have attempted to generate a sql injection attack but so far no one managed to make a working one.

Show
Andrea Aime added a comment - Oracle and Postgres JDBC-NG datastores are using prepared statements by default, this makes, to my knoledge, sql-injection attack impossible, thought there is a heavy performance price to pay if the tables are not organised on the spatial index and the requests tend to extract full(ish) data dumps. There is a 2-4 times slowdown compared to issuing a straight sql request (non prepared). Anyways, even in the old ones, there is escaping in place, some have attempted to generate a sql injection attack but so far no one managed to make a working one.
Hide
Permalink
Justin Deoliveira added a comment -

Closing this as won't fix. Could perhaps an alternative be to turn off verbose exceptions?

Show
Justin Deoliveira added a comment - Closing this as won't fix. Could perhaps an alternative be to turn off verbose exceptions?
Hide
Permalink
Andrea Aime added a comment -

Mass closing all issues that have been in "resolved" state for 2 months or more without any feedback or update

Show
Andrea Aime added a comment - Mass closing all issues that have been in "resolved" state for 2 months or more without any feedback or update

People

  • Assignee:
    Andrea Aime
    Reporter:
    Simon Peter Haverdings
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: