ESAPI.securityConfiguration().setResourceDirectory(...) not considered anymore in loading of configuration via classloader

[nettermensch]

We set the directory for locating the ESAPI.properties within our resources in the following way.

String rd = findConfigurationDirectory(...); // <== result e.g. is "esapi/v25/" ESAPI.securityConfiguration().setResourceDirectory(rd);

Using ESAPI <= version 2.1 this perfectly worked fine. It does not work from ESAPI >= 2.2 on.
After scanning the code of "DefaultSecurityConfiguration" I see the following difference in method "loadConfigurationFromClasspath":

Version 2.1
in = currentLoader.getResourceAsStream(this.resourceDirectory + "/" + fileName);
Version >= 2.2
in = currentLoader.getResourceAsStream(DefaultSearchPath.RESOURCE_DIRECTORY.value() + fileName);

So the resource directory that is set by "ESAPI.securityConfiguration().setResourceDirectory(...);" is not considered anymore. To me this seems like a bug.(?) Why is it not possible anymore to locate the ESAPI,properties resource file by defining the resource directory?

(Maybe you want to know why we do need this: our library has to work with different ESAPI releases, so we analyse which ESAPI version is loaded within the runtime environment and then decide if to use the one or the other ESAPI.properties file by setting the correpsonding direcotry.)

Thanks + Regards!

[jeremiahjstacey]

It does appear that uses of the reference resourceDirectory are interpreted relative to an assumed directory on the path named "resources"

From what I can tell from the workflow you've provided, the runtime is expecting your content to be located at resources/esapi/v25/

We will most likely need to look at the commits around this work to determine if this was a deliberate change, or a bug that will need to be addressed.

Possible Quickfix
Based on what I think I'm seeing in the current form of DefaultSecurityConfiguration, if you are able to update the return from your findConfigurationDirectory method from esapi/v25/ to just v25/ then I believe the desired behavior would be restored.

That should fall into the workflow for the " // try esapi folder (new directory)" in the block just above the resourceDirectory check in loadConfigurationFromClasspath (lines 827 - 831 below)

 // try esapi folder (new directory)
                    if (in == null) {
                        currentClasspathSearchLocation = "esapi/";
                        in = currentLoader.getResourceAsStream(DefaultSearchPath.ESAPI.value() + fileName);
                    }

[jeremiahjstacey]

If I'm tracking this correctly, these changes came in PR 541, fixing issue 310

https://github.com/ESAPI/esapi-java-legacy/pull/541/files#diff-c81f967b75902f58647012b1bb9d7b029798354277ac7635193f7f9c87ecc78f

Further investigation still needed, just narrowing down the field.

[nettermensch]

Thanks for picking this up "immediately" - very impressive!

Your Possible Quickfix - from "esapi/v25/" to just "v25/" - this does not help... - because still the path for accessing the class loader is built in a fix way.

FYI: While debugging through this issue, I now found a workaround for me by explicitly passing the properties in the following way:

            String propertiesContentString = (new ClassloaderReader(true)).readUTF8File(rd+"/ESAPI.properties",true);
            ByteArrayInputStream bis = new ByteArrayInputStream(propertiesContentString.getBytes("UTF-8"));
            properties.load(bis);
            bis.close();
            ESAPI.override(new DefaultSecurityConfiguration(properties));

So I use the override method to create an own DefaultSecurityConfiguration. This works nicely.

[jeremiahjstacey]

@nettermensch - Thanks for the update, I'm glad you were able to find a solution that will work for you.

@kwwall @xeno6696 , I'd appreciate your input on this when you have time.

Issue #310 was a fix to adjust the lookup for antisamy from classpaths. The change to prefix the resources directory was a part of that refactoring, but I'm not seeing any specific callout to that intention.

At this point I think this may be a bug that altered a previously untested path in the baseline.

[jeremiahjstacey]

More evidence this may be a bug in the javadoc for SecurityConfiguration.setResourceDirectory

    /**
     * Sets the ESAPI resource directory.
     *
     * @param dir The location of the resource directory.
     */
    void setResourceDirectory(String dir);

The current implementation of DefaultSecurityProvider does not fulfill this contract, as it is defined.

[kwwall]

@nettermensch - I'm have not yet researched why we changed this, but if since we have accidentally made SecurityConfiguration.setResourceDirectory() ineffective, I'd say that definitely is a bug because it is used in the (presumably rarely used) org.owasp.esapi.filters.ESAPIFilter class, which means we broke that, too.

Please go ahead and create a GitHub issue for this. (If you wish, you can just create it with a Summary title and reference this discussion for details.)

As for a temporary workaround, I might suggest setting the System property "org.owasp.esapi.resources" to the directory of interest. That ought to work for 2.2 and later. (Not as sure about 2.1.)

Note: We do not back-port bug fixes to previous minor versions (we just don't have the bandwidth), so we will only fix this in the latest version. So, if you are, as you said, trying to support different ESAPI releases in this manner, that's still going to be a problem, so setting the System property is probably going to be your best bet.

[kwwall]

FYI - I found the original commit for this , but that commit was fixed some years later. This commit however, was associated with PR #393 that was GitHub issue #316, which really seems to have nothing to do with this change or DefaultSecurityConfiguration class in general. So, perhaps it was just some general code clean-up that was being made. I do think it should be easy enough to fix though. I will see if I can get a PR to address this by the weekend.

[nettermensch]

Thanks for your update + for taking care! ;-)