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:
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."
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).
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 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, 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.
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:
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."
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
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.
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).
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 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, 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.
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:
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."
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