[Esapi-user] Question about ESAPI jar being too noisy

Kevin W. Wall kevin.w.wall at gmail.com
Thu Feb 11 00:56:33 UTC 2016


Rakesh,


Hope you don't mind posting this to the ESAPI-User list. (I've BCC'd your
email address and obscured your address in the response just in case.)

On Wed, Feb 10, 2016 at 2:37 PM, Rakesh Kunnumakkra
<rr............. at gmail.com> wrote:
> Hi Chris & Kevin,
>
> The esapi jar 2.0 which we are using is having some sys outs in it.
>
> Any idea when will these will be removed from the esapi jar?

They haven't been as of 2.1.0.1 and it's possible that they never will.

> Kindly let me know if it is already removed.
>
>
> Attempting to load ESAPI.properties via file I/O.
> Attempting to load ESAPI.properties as resource file via file I/O.
> Not found in 'org.owasp.esapi.resources' directory or file not readable:
> /tbx_dirs13/mpt/common_apps/devV2/apps/batch/deploy/ESAPI.properties
> Not found in SystemResource Directory/resourceDirectory:
> .esapi/ESAPI.properties
> Not found in 'user.home' (/app_dirs/mpt) directory:
> /app_dirs/mpt/esapi/ESAPI.properties
> Loading ESAPI.properties via file I/O failed. Exception was:
> java.io.FileNotFoundException
> 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 file I/O.
> Attempting to load validation.properties as resource file via file I/O.
> Not found in 'org.owasp.esapi.resources' directory or file not readable:
> /tbx_dirs13/mpt/common_apps/devV2/apps/batch/deploy/validation.properties
> Not found in SystemResource Directory/resourceDirectory:
> .esapi/validation.properties
> Not found in 'user.home' (/app_dirs/mpt) directory:
> /app_dirs/mpt/esapi/validation.properties
> Loading validation.properties via file I/O failed.
> Attempting to load validation.properties via the classpath.

This is really somewhat of a catch-22 situation. This verbose output that you
refer to comes from the DefaultSecurityConfiguration class as it is
searching for the correct ESAPI.properties and validation.properties files
to use. The catch-22 is that ESAPI can use either log4j or java.util.logging,
but it doesn't know which is being used until if finds and parses the
ESAPI.properties file (which can be located in many different places).

Thus we can't make these "debug" or less verbose logging because as people
using ESAPI, especially for the first time, often have problems with
ESAPI either
not being able to find their ESAPI.properties file or having it locate and use a
different on than what they intended. In particular, we can't rely on using the
logger that ESAPI specifies because that information may not have been
parsed yet in the ESAPI.properties file. (Also, doing so would more tightly
couple the ESAPI logger to the ESAPI configuration, something that we
would like to avoid.

Probably about the best we could do in this case would be to NOT output
these messages if some System property was set, e.g., if the property

    esapi.configuration.errormessages

were set to "quiet" or "off", etc. then we could refrain from outputting this.
Alternately, we could provide a static method on DefaultSecurityConfiguration
that disables the special logging.

But given the trouble that people have with getting their intended
ESAPI.properties
file used out-of-the-box, I would definitely want to keep the DEFAULT so that
it prints these messages.

BTW, I will write up these ideas in the GitHub issue # 198 that deals
with it. If anyone has any better ideas, feels free to contribute ideas at:
https://github.com/ESAPI/esapi-java-legacy/issues/198. Also feel
free to contribute a pull request that addresses this. No guarantees
that we will accept it, but if someone helps out, it is more likely to get
attention than if not.

Best regards,
-kevin
--
NSA: All your crypto bit are belong to us.
Blog: http://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall


More information about the Esapi-user mailing list