The description you found of how CQL is used is correct.
We actually have two control paths depending on how a filter is supplied:
- CQL parsed to a Filter (abstract symbol tree) then encoded as SQL using a
"dialect" specific to each supported Database
- OGC Filter (included in WFS request) parsed to a Filter (abstract symbol
tree) then encoded as SQL using a "dialect" specific to each supported
Database
There is one other avenue using SQL views (which an Administrator defines
as a fill in the blank SQL query - isolating parts of the query to be
supplied as a parameter). You will need to talk to another developer to
learn more about that one.
Jody Garnett
On Thu, Jul 24, 2014 at 10:35 AM, Jody Garnett <[email protected]>
wrote:
> Hey Aijun:
>
> You have some control over how much detail is returned to users (in the
> configuration you can ask for verbose messages or verbose exception
> reporting).
>
>
> http://docs.geoserver.org/stable/en/user/webadmin/server/globalsettings.html
>
> We may be aware of some of your concerns (based on an earlier email
> discussion) and have an interesting design in mind but lack funding to
> implement. The idea would be to introduce error codes for all GeoServer
> errors and uses the to look up an internationalised message. The separation
> between exception thrown and message returned would introduce an "air gap"
> addressing a wide range of security concerns. Note this approach is similar
> to the oracle exception and ORA error codes.
>
> Aside: You CQL example is a bit funny, we actually encode the CQL Filter
> INCLUDES as 1=1 in SQL so I was initially confused at what you were showing
> me.
>
> It looks like you hunted through the documentation and are aware you can
> configure GeoServer to use prepared statements (for safety) or use strings
> (speed).
>
> I expect you should contact one of the organisations on our commercial
> support <http://geoserver.org/support/> page to go through your concerns
> and address any issues directly with your security guys. Placing a team
> under contract is the most direct way to set scope and be assured the work
> shows up in a GeoServer release.
>
> You may also (this being open source) prepare a patch. In this case such a
> wide ranging change would be subject to our Request for Change process
> (called GSIP). Basically you would make a proposal (with any design
> documents) subject to community review prior to starting work. This limits
> your development risk, and is the same process a commercial support vendor
> goes through.
>
> For short term communication (sounds like you have a report?) you may
> contact any members of the GeoServer project steering committee
> <http://docs.geoserver.org/latest/en/developer/policies/psc.html>, or
> attend one of our bi-weekly Skype meetings to raise your concerns to a more
> limited audience.
>
> Cheers, and thanks for contacting us in a sensible manner.
>
> Jody Garnett
>
>
> On Thu, Jul 24, 2014 at 5:11 AM, Aijun Chen <[email protected]> wrote:
>
>> Dear GeoServer developers,
>>
>> 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.
>>
>> Also, I have few questions as below:
>> 1. Is there a core GeoServer development team that we can contact to
>> provide more details about this vulnerability for further
>> discussion/solutions? We don't want to send our vulnerability scan report
>> to the whole GeoServer community.
>> 2. Did GeoServer development team verify and agree with this
>> vulnerability? If yes, do you have any solutions and/or any plans to fix it
>> in the near future? If you verified, but thought this vulnerability is not
>> critical, can you please provide some details to explain why this
>> vulnerability is not critical?
>> 3. I read following comments from GeoServer Community, did you agree with
>> it? Does GeoServer team take it as an explaination to CQL vulnerability?
>> ~~~~~~~~~~~~~~~~~~~
>> "In GeoServer's implementation, each filter expression is fully parsed
>> into an abstract syntax tree and then partially or fully converted to
>> native queries in a database-specific manner - PostGIS can take advantage
>> of SQL syntax and functions unique to that database, while Shapefiles
>> use a fallback that fully interprets filters in GeoServer/GeoTools code.
>> As such, it's not susceptible to traditional SQL injection attacks
>> since the user input is never directly sent to the underlying database.
>>
>> I guess it might be possible in theory to perform an injection attack by
>> some clever escaping - using "' -- DELETE TABLE important_data;" as a
>> property name. But GeoServer validates that filters reference only
>> properties that are actually present, so this would not be feasible through
>> WFS. And CQL does not support comments, further complicating any
>> potential injection attacks.
>>
>> Furthermore,Geoserver jdbc by default uses prepared statements
>> where possible for both performance and security. Prepared statements are
>> a strong protection against SQL injection because the injected value
>> is not evaluated as SQL code."
>> ~~~~~~~~~~~~~~~~~~~~
>>
>> Thanks,
>>
>> Aijun,
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Geoserver-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
