Details
Bug
Closed
Critical
Description
If no SPI data access factory can be found, the connection parameters, including password, are included in the WFS ows:ExceptionReport. This gives an end user access to confidential information.
<?xml version="1.0" encoding="UTF-8"?> <ows:ExceptionReport version="1.0.0" xsi:schemaLocation="http://www.opengis.net/ows http://localhost:8080/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows"> <ows:Exception exceptionCode="NoApplicableCode"> <ows:ExceptionText>Error occurred getting features Cannot find a DataAccess for parameters {user=test, passwd=s3cr3t, host=name.changed.to.protect.the.innocent, port=1521, database=test, dbtype=Ooracle}</ows:ExceptionText> </ows:Exception> </ows:ExceptionReport>
Activity
Hide
Note that the dbtype parameter is misspelled ("Ooracle"), so the request never gets deep enough to require any Oracle jars.
I went hunting ... the exception is thrown in GT app-schema AppSchemaDataAccessConfigurator.aquireSourceDatastores. You are going to reassign this one to me, aren't you? 
Before you do, it would be good to check what the core code does when a bad dbtype causes no DataAccessfactory to be found. If passwd is not revealed, then this bug is app-schema specific.
Caused by: org.geotools.data.DataSourceException: Cannot find a DataAccess for parameters {user=pirsa, passwd=XXXXXXXX, host=wsrv1.arrc.csiro.au, schema=pirsa, port=1521, database=wsrv1, dbtype=oracleng}
at org.geotools.data.complex.config.AppSchemaDataAccessConfigurator.aquireSourceDatastores(AppSchemaDataAccessConfigurator.java:517)
at org.geotools.data.complex.config.AppSchemaDataAccessConfigurator.buildMappings(AppSchemaDataAccessConfigurator.java:170)
at org.geotools.data.complex.config.AppSchemaDataAccessConfigurator.buildMappings(AppSchemaDataAccessConfigurator.java:147)
at org.geotools.data.complex.AppSchemaDataAccessFactory.createDataStore(AppSchemaDataAccessFactory.java:68)
at org.vfny.geoserver.util.DataStoreUtils.getDataAccess(DataStoreUtils.java:97)
at org.geoserver.catalog.ResourcePool.getDataStore(ResourcePool.java:220)
at org.geoserver.catalog.ResourcePool.getFeatureSource(ResourcePool.java:496)
at org.geoserver.catalog.impl.FeatureTypeInfoImpl.getFeatureSource(FeatureTypeInfoImpl.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.geoserver.catalog.impl.ModificationProxy.invoke(ModificationProxy.java:98)
at $Proxy16.getFeatureSource(Unknown Source)
at org.geoserver.wfs.GetFeature.run(GetFeature.java:170)
... 66 more
Show
Ben Caradoc-Davies
added a comment - - edited Note that the dbtype parameter is misspelled ("Ooracle"), so the request never gets deep enough to require any Oracle jars.
I went hunting ... the exception is thrown in GT app-schema AppSchemaDataAccessConfigurator.aquireSourceDatastores. You are going to reassign this one to me, aren't you?
Before you do, it would be good to check what the core code does when a bad dbtype causes no DataAccessfactory to be found. If passwd is not revealed, then this bug is app-schema specific.
Caused by: org.geotools.data.DataSourceException: Cannot find a DataAccess for parameters {user=pirsa, passwd=XXXXXXXX, host=wsrv1.arrc.csiro.au, schema=pirsa, port=1521, database=wsrv1, dbtype=oracleng}
at org.geotools.data.complex.config.AppSchemaDataAccessConfigurator.aquireSourceDatastores(AppSchemaDataAccessConfigurator.java:517)
at org.geotools.data.complex.config.AppSchemaDataAccessConfigurator.buildMappings(AppSchemaDataAccessConfigurator.java:170)
at org.geotools.data.complex.config.AppSchemaDataAccessConfigurator.buildMappings(AppSchemaDataAccessConfigurator.java:147)
at org.geotools.data.complex.AppSchemaDataAccessFactory.createDataStore(AppSchemaDataAccessFactory.java:68)
at org.vfny.geoserver.util.DataStoreUtils.getDataAccess(DataStoreUtils.java:97)
at org.geoserver.catalog.ResourcePool.getDataStore(ResourcePool.java:220)
at org.geoserver.catalog.ResourcePool.getFeatureSource(ResourcePool.java:496)
at org.geoserver.catalog.impl.FeatureTypeInfoImpl.getFeatureSource(FeatureTypeInfoImpl.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.geoserver.catalog.impl.ModificationProxy.invoke(ModificationProxy.java:98)
at $Proxy16.getFeatureSource(Unknown Source)
at org.geoserver.wfs.GetFeature.run(GetFeature.java:170)
... 66 more
Hide
Ben Caradoc-Davies
added a comment -
Thanks, it is good to know that the core code path is not insecure.
And on a personal note, there is nothing more satisfying than assigning a bugreport back to the original reporter. I hope you enjoyed it as much as would have.
Show
Ben Caradoc-Davies
added a comment - Thanks, it is good to know that the core code path is not insecure.
And on a personal note, there is nothing more satisfying than assigning a bugreport back to the original reporter. I hope you enjoyed it as much as would have.
we have the DataAccessFactory.Param.isPassword() convenience method to help here. This will imply a little more work than Map.toString for the exception report thoug, but an easy fix.