3

I have two modules that will use ESAPI with the same properties files (ESAPI and validation.properties).

These modules output to wars that are contained in an ear.

I have the properties files inside one of the war files, where they are found at server start. The other war file seems to work fine and does not complain that it can't find the properties files in the log.

I am using ESAPI to sanitize html and url parameters - I wonder if I even need these property files to be accessible to the second module, or either one since there is no configuration and everything is being done with defaults.

davidjmcclelland
  • 430
  • 9
  • 20

3 Answers3

6

First, let me describe how ESAPI 2.x goes about finding its ESAPI.properties file.

The reference implementation class for ESAPI's SecurityConfiguration interface is

org.owasp.esapi.reference.DefaultSecurityConfiguration

With this default implementation, resources like ESAPI.properties and Validation.properties can be put in several locations, which are searched in the following order:

1) Inside a directory set with a call to SecurityConfiguration.setResourceDirectory(). E.g.,

ESAPI.securityConfiguration().setResourceDirectory("C:\myApp\resources");

Of course, if you use this technique, it must be done before any other ESAPI calls are made that use ESAPI.properties (which are most of them).

2) Inside the directory defined by the System property "org.owasp.esapi.resources". You can set this on the java command line as follows (for example):

java -Dorg.owasp.esapi.resources="C:\temp\resources" ...

You may have to add this to the start-up script that starts your web server. For example, for Tomcat, in the "catalina" script that starts Tomcat, you can set the JAVA_OPTS variable to the '-D' string above.

3) Inside the

System.getProperty( "user.home" ) + "/.esapi"

directory (supported for backward compatibility) or inside the

System.getProperty( "user.home" ) + "/esapi"

4) The first ".esapi" or "esapi" directory encountered on the classpath. Note this may be complicated by the fact that Java uses multiple class loaders and if you are have multiple applications in a given application server, they may be using different classpaths. For this reason, this option is not generally recommended, but is offered for reasons of backward compatibility with earlier ESAPI 1.4.x versions.

Once ESAPI finds a valid property file (e.g., ESAPI.properties) that it can read, it stops searching for others.

Now, that said, if you want to share a single ESAPI.properties file across all of your .war files, I would recommend going with option #2 and set the System property "org.owasp.esapi.resources" to some common secured directory that both of them can access. Also, you should use a full path name.

Kevin W. Wall
  • 1,347
  • 7
  • 7
0

The answer was to place the esapi directory containing the properties files in

src/main/application

in one of the modules. This path puts it's contents at the root of the ear.

davidjmcclelland
  • 430
  • 9
  • 20
  • 1
    In Javaland, I would probably recommend putting it into src/main/resources if you're holding to typical standards. – avgvstvs Dec 13 '16 at 18:23
0

I'm running ESAPI on a maven project with java 1.8.0_71. I've put ESAPI.properties and validation.properties in

src/main/resources

This worked for me:

Attempting to load ESAPI.properties via the classpath. SUCCESSFULLY LOADED ESAPI.properties via the CLASSPATH from '/ (root)' using current thread context class loader!

Attempting to load validation.properties via the classpath. SUCCESSFULLY LOADED validation.properties via the CLASSPATH from '/ (root)' using current thread context class loader!

Francesco Sanseverino
  • 1