GeoServer
  1. GeoServer
  2. GEOS-2972

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

        Hide
        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
        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
        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
        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
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: