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.
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.
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
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.
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
It turned out that we don’t have time to fix this issue right now.
Our security manager flaged the application unsafe that used GeoServer to access background spatial database and displayed maps to Web users.
Now, I have few questions for you/GeoServer development team as below:
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.
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?
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."
This transmission is intended for the named addressee(s) only and may contain confidential, sensitive or personal information and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.
···
Hi Aijun,
Now, I have few questions for you/GeoServer development team as below:
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.