ESAPI.properties not readable?

[Jeffrey Walton]

Hi Everyone,

I'm working on my minimal ESAPI test. I have ESAPI.properties
(downloaded from GitHub [1] using wget) in pwd. When I run the test
program, I see the message:

ESAPI: Not found in 'org.owasp.esapi.resources' directory or
file not readable: /home/jwalton/Desktop/ESAPI-Test/ESAPI.properties

I'm not sure why the file is not readable:

$ pwd
/home/jwalton/Desktop/ESAPI-Test

$ ls -Al ESAPI.properties
-rw-rw-r-- 1 jwalton jwalton 28600 Jul 9 17:01 ESAPI.properties

$ head -n 4 ESAPI.properties
#
# OWASP Enterprise Security API (ESAPI) Properties file --
PRODUCTION Version
#
# This file is part of the Open Web Application Security Project (OWASP)

Any ideas what might be wrong?

Thanks in advance.

-----

[1] https://raw.githubusercontent.com/ESAPI/esapi-java-legacy/develop/configuration/esapi/ESAPI.properties

-----

$ javac -cp esapi-2.5.2.0.jar ESAPITest.java && java -cp
"$(pwd):esapi-2.5.2.0.jar:esapi-2.5.2.0-configuration.jar" ESAPITest
"Hello World"
ESAPI: WARNING: System property [org.owasp.esapi.opsteam] is not set
ESAPI: WARNING: System property [org.owasp.esapi.devteam] is not set
ESAPI: Attempting to load ESAPI.properties via file I/O.
ESAPI: Attempting to load ESAPI.properties as resource file via file I/O.
ESAPI: Not found in 'org.owasp.esapi.resources' directory or file not
readable: /home/jwalton/Desktop/ESAPI-Test/ESAPI.properties
ESAPI: Not found in SystemResource Directory/resourceDirectory:
.esapi/ESAPI.properties
ESAPI: Not found in 'user.home' (/home/jwalton) directory:
/home/jwalton/esapi/ESAPI.properties
ESAPI: Loading ESAPI.properties via file I/O failed. Exception was:
java.io.FileNotFoundException
ESAPI: Attempting to load ESAPI.properties via the classpath.
ESAPI: SUCCESSFULLY LOADED ESAPI.properties via the CLASSPATH from '/
(root)' using current thread context class loader!
ESAPI: SecurityConfiguration for
Validator.ConfigurationFile.MultiValued not found in ESAPI.properties.
Using default: false
ESAPI: Attempting to load validation.properties via file I/O.
ESAPI: Attempting to load validation.properties as resource file via file I/O.
ESAPI: Not found in 'org.owasp.esapi.resources' directory or file not
readable: /home/jwalton/Desktop/ESAPI-Test/validation.properties
ESAPI: Not found in SystemResource Directory/resourceDirectory:
.esapi/validation.properties
ESAPI: Not found in 'user.home' (/home/jwalton) directory:
/home/jwalton/esapi/validation.properties
ESAPI: Loading validation.properties via file I/O failed.
ESAPI: Attempting to load validation.properties via the classpath.
ESAPI: validation.properties could not be loaded by any means. fail..
Caught java.lang.IllegalArgumentException; exception message was:
java.lang.IllegalArgumentException: Failed to load ESAPI.properties as
a classloader resource.
ESAPI: DefaultSecurityConfiguration: The code to print all the
properties is currently commented out
org.owasp.esapi.errors.ConfigurationException:
java.lang.reflect.InvocationTargetException Encoder class
(org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception.

[Kevin W. Wall]

Jeff,

That message:

ESAPI: Not found in 'org.owasp.esapi.resources' directory or file not readable: /home/jwalton/Desktop/ESAPI-Test/ESAPI.properties

is not intended as an error message, but rather as a informational message intended to assist developers to understand the various steps that ESAPI goes through to find your ESAPI.properties file.

If you haven't done a careful reading of how ESAPI locates its ESAPI.properties file, you should stop and do it now. Seriously; I'll wait. You can find it in the Javadoc for the DefaultSecurityConfiguration class at:

https://www.javadoc.io/static/org.owasp.esapi/esapi/2.5.2.0/org/owasp/esapi/reference/DefaultSecurityConfiguration.html

[Note: I have been meaning to redo those notes because it is missing some important information; specifically, it does not explicitly state that once ESAPI finds an ESAPI.properties file, that it stops looking--unless perhaps it encounters a call to ESAPI.override() [which I've seen either OpenSAML or Shibboleth do in the past; SMH], or perhaps a subsequent call to ESAPI.securityConfiguration().setResourceDirectory(), but I don't think the latter would affect that and cause ESAPI to continue searching. But much of DefaultSecurityConfiguration is a hack in my mind as it grew ad hoc without new design implications being thought out, It needs rewritten IMO and the ESAPI.override(), which was intended only for testing, needs burned to the ground. That method was necessitated by the "everything is a singleton" design pattern botch that just made certain types of testing otherwise extremely difficult. Regardless, it is what it is for now.]

It's rather complicated, but unless you understand those steps that ESAPI is following (considering the note above as well), it will be difficult to debug what's going on, unless you are very proficient with attaching a debugger to your JavaEE app server as it starts up and want to go that route. But that path is much more difficult.

The key thing to note is when ESAPI starts up (in version 2.2.0.0 and later), as long as the system property

org.owasp.esapi.logSpecial.discard

is not set to 'true' (the property is generally passed on the 'java' command-line, but it could be somewhere in your code or even the code of a dependency), then you out to see something like this output on stdout:

ESAPI: WARNING: System property [org.owasp.esapi.opsteam] is not set
ESAPI: WARNING: System property [org.owasp.esapi.devteam] is not set
ESAPI: Attempting to load ESAPI.properties via file I/O.
ESAPI: Attempting to load ESAPI.properties as resource file via file I/O.

ESAPI: Not found in 'org.owasp.esapi.resources' directory or file not readable: /home/wallk/work/esapi-work/kww-2.5.2.0-release/ESAPI.properties
ESAPI: Found in SystemResource Directory/resourceDirectory: /home/wallk/work/esapi-work/kww-2.5.2.0-release/target/test-classes/esapi/ESAPI.properties
ESAPI: Loaded 'ESAPI.properties' properties file

ESAPI: SecurityConfiguration for Validator.ConfigurationFile.MultiValued not found in ESAPI.properties. Using default: false
ESAPI: Attempting to load validation.properties via file I/O.
ESAPI: Attempting to load validation.properties as resource file via file I/O.

ESAPI: Not found in 'org.owasp.esapi.resources' directory or file not readable: /home/wallk/work/esapi-work/kww-2.5.2.0-release/validation.properties
ESAPI: Found in SystemResource Directory/resourceDirectory: /home/wallk/work/esapi-work/kww-2.5.2.0-release/target/test-classes/esapi/validation.properties
ESAPI: Loaded 'validation.properties' properties file

Note however, that even in this case, I still got the message (highlighted in orange) similar to what you noted, but ESAPI still found the ESAPI.properties (yellow highlight).

So, in reality, the "error" in your case is the exception that was thrown noting that ESAPI could not find it in your case. (If it had, you would have seen the message that I highlighted in yellow somewhere along the line.)

The best option, especially since it's the most straight forward is to add the argument:

for you is either to either call your test by adding

-Dorg.owasp.esapi.resources=/some-full-path-to-esapi-config-directory

when you execute the 'java' command. E.g., for the case where you already located, add this:

-Dorg.owasp.esapi.resources=$HOME/Desktop

Note that your 'validation.properties' file should be placed in the same directory.

Alternately, you could drop it under

3) Inside the System.getProperty( "user.home" ) + "/.esapi" directory (supported for backward compatibility) or inside the System.getProperty( "user.home" ) + "/esapi" directory.

(Step 3 from the Javadoc URL that I mentioned above.)

Hope that helps. If not, let me know.

-kevin

--
You received this message because you are subscribed to the Google Groups "ESAPI Project Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to esapi-project-u...@owasp.org.
To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/esapi-project-users/CAH8yC8mkbFgFqx3nqwq1x8TyFT39GkjUNKVxcugEbiAr6UYGvA%40mail.gmail.com.

--

Blog: https://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall | OWASP ESAPI Project co-lead
NSA: All your crypto bit are belong to us.

[Jeffrey Walton]

Thanks man!

I generally go back to the very first problem when working on an
issue. The first issue looked like the problem loading
ESAPI.properties.

I think ESAPI should adopt the "Dark and Silent Cockpit." It is making
too much noise, and it is confusing people. For example, me in the
question below and
https://knowledge.broadcom.com/external/article/222660/validatorconfigurationfile-not-found-in.html
.

Dark and Silent Cockpit is taken from aviation. A cockpit should be
dark and silent if there are no problems. A pilot knows there are no
problems when the cockpit is dark and silent. In contrast, if there is
a problem, then lights should illuminate and sounds should be made. A
pilot will know there is a problem when the darkness and silence is
breached.

If the user asks for verbose logging, then give it to them. I don't
believe that's the case here. I did not elevate logging.

I'm not a big fan of debug logging. I'm not interested in seeing the
debug logs in my terminal. The debug noise washes out important stuff.
Important stuff gets lost in the noise.

Jeff

[Kevin W. Wall]

If you want the "Dark and Silent" approach, add:

     -Dorg.owasp.esapi.logSpecial.discard=true 

to your 'java' command line. It's not the default because this is probably the most common source of confusion for new ESAPI users. So it is essentially debugging info for new users. It's only a warning (or error) if your intent was to use the System property 'org.owasp.esapi.resources' to locate your ESAPI.properties file an It's not there or it's there, but not readable. Most people set

  -Dorg.owasp.esapi.logSpecial.discard=true 

once they get it working, but since it's such a common source of confusion for those new to ESAPI, we decided not to make it the default.

Also, just so you know, you probably are going to have to add several other transitive dependencies (to you) to your class path. That is the reason for that runClass.sh script I previously mentioned. If you don't do that, either use -Dext.dirs or use Maven to simplify managing the claa path for you.

-kevin