I am trying to use OWASP ESAPI for validating strings in a spring mvc project.
So far I have done:
1-
<dependency>
<groupId>org.owasp.esapi</groupId>
<artifactId>esapi</artifactId>
<version>2.1.0.1</version>
</dependency>
2- Added ESAPI.properties and validation.properties in the resources as:
myproject/src/resources/esapi/ESAPI.properties
myproject/src/resources/esapi/validation.properties
3- Added my own validation to the validation.properties
4- In my application.properties I set the org.owasp.esapi.resources
org.owasp.esapi.resources=classpath:esapi/ESAPI.properties
And I have the following line in a method
boolean isValid = ESAPI.validator().isValidInput("user id", userID, "USERID", 20, false);
The validation works, but I get the following notifications printed out in stdout:
System property [org.owasp.esapi.opsteam] is not set
System property [org.owasp.esapi.devteam] is not set
How do I fix this?
I Also get several lines as:
Not found in 'org.owasp.esapi.resources' directory or file not readable: /usr/local/apache-tomcat-8.0.28/bin/ESAPI.properties
Not found in SystemResource Directory/resourceDirectory: .esapi/ESAPI.properties
SUCCESSFULLY LOADED ESAPI.properties via the CLASSPATH from 'esapi/' using current thread context class loader!
And several others.
How do I get rid of these lines?
I Also have written a test. After running the test I get the almost same comments as in production code except for the SUCCESS part, in addition I get the following:
Not found in 'org.owasp.esapi.resources' directory or file not readable: /Users/me/dev/myproject/validation.properties
Found in SystemResource Directory/resourceDirectory: /Users/me/dev/myproject/target/classes/esapi/validation.properties
Loaded 'validation.properties' properties file
So the validation and tests all work but I get all these notifications which I would like to get rid of!
What do I miss in the configurations or elsewhere?
Answer
These are standard warnings that occur during the bootstrapping of org.owasp.esapi.reference.DefaultSecurityConfiguration, when it is first loaded. Because the ESAPI logging facility is configurable and the DefaultSecurityConfiguration is search for the ESAPI.properties that will tell it which logger to use, the DefaultSecurityConfiguration cannot use the preferred ESAPI logging facility. (If could guess, but what if it were to guess wrong?) So instead, it resorts to using System.out.println() to print messages to stdout.
Early on, we experimented with eliminating these messages completely, but then we started to get lots of complaints about people not being able to figure out where to put their ESAPI.properties file or having ESAPI use a different one than they thought it should be using. While these messages are not foolproof, they were better than the alternative of firing up a debugger and attaching it to your application server just so you can figure out why ESAPI can't find your ESAPI.properties file.
The bottom line is you pretty much can't pick something that everyone will be happy with. In this particular case, in order to avoid a catch-22 situation with the ESAPI logging facility not yet being configured (that's part of what this tries to do), the only logical alternatives were to output to stdout, output to stderr, or output to some pre-specified file. The latter was quickly dismissed because we couldn't decide on a universal place where we could create said file that was portable across all OSes and that we would be guaranteed to have write permission to it. And it was argued that stderr was wrong because these were not really ERROR messages per se. And since other application servers often write start-up messages to stdout and most operations redirect already redirect that to a file somewhere that they know they can create, stdout seemed like a natural choice. In hindsight, the algorithm for locating your ESAPI.properties file is admittedly overly complex, but that is largely because of backward compatibility issues and it does give you extreme flexibility in terms of choices.
So the bottom line is you can't get rid of these completely. You can set certain properties such as the 2 mentioned or org.owasp.esapi.resources and make some of them go away though.
For more details, see: https://static.javadoc.io/org.owasp.esapi/esapi/2.1.0.1/org/owasp/esapi/reference/DefaultSecurityConfiguration.html and https://github.com/ESAPI/esapi-java-legacy/tree/master/documentation/ESAPI-configuration-user-guide.md for a discussion of those properties and what they mean / do.
-kevin