java.lang.ExceptionInInitializerError in 2.0 version

[meg23]

From lake...@gmail.com on November 23, 2009 21:07:54

What steps will reproduce the problem? 1. Running a simple test found here: https://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/test/java/org/owasp/esapi/reference/EncoderConcurrencyTest.java?spec=svn408&r=408 with new 2.0rc4 version. What is the expected output? What do you see instead? It should encode the javascript. I see this exception stack trace instead. What version of the product are you using? On what operating system? ESAPI-2.0-rc4.zip on Windows XP. Please provide any additional information below. Exception in thread "Thread-0" Exception in thread "Thread-1" java.lang.Exceptio nInInitializerError at EncoderConcurrencyTest.run(EncoderConcurrencyTest.java:19) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.NullPointerException at java.util.Properties$LineReader.readLine(Properties.java:365) at java.util.Properties.load(Properties.java:293) at org.owasp.esapi.reference.DefaultSecurityConfiguration.loadProperties FromStream(DefaultSecurityConfiguration.java:370) at org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfigurat ion(DefaultSecurityConfiguration.java:507) at org.owasp.esapi.reference.DefaultSecurityConfiguration.(Default SecurityConfiguration.java:207) at org.owasp.esapi.ESAPI.(ESAPI.java:87) ... 2 more java.lang.NoClassDefFoundError at EncoderConcurrencyTest.run(EncoderConcurrencyTest.java:19) at java.lang.Thread.run(Thread.java:595)

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=61

[meg23]

From chrisisbeef on December 01, 2009 23:39:29

This test was replaced with testConcurrency() in EncoderTest.

Status: WontFix

[meg23]

From kevin.w.wall@gmail.com on December 02, 2009 17:39:39

I don't agree with the "WontFix" status. We should either delete the test or minimally use the Junit 4 '@Ignore' annotation before the test case so that the test is not executed. However, I think either approach is an acceptable "fix" if you will.

Summary: java.lang.ExceptionInInitializerError in 2.0 version
Cc: chrisisbeef

[meg23]

From lake...@gmail.com on December 06, 2009 19:50:06

The issue seems to occur with my application too. I'm using DefaultEncoder class to encode javascript in the tag class which would output the result on the jsp. I'm seeing the exact same exception (java.lang.Exceptio nInInitializerError) and stack trace. I tried using JavaScriptCodec directly and it works just fine.

Is this a known issue? This issue never occurred with older version of the jar.

Please help. Thank you.

[meg23]

From chrisisbeef on December 06, 2009 20:30:27

Can you attach a code sample of how you are using the encoder?

Status: Accepted
Owner: chrisisbeef

[meg23]

From lake...@gmail.com on December 07, 2009 17:47:24

Unfortunately, I can't provide the actual code due to licensing reasons. But, I'm just instantiating DefaultEncoder object much like in the test case and calling encodeForJavaScript method on it.

StringBuffer output = new StringBuffer(); Encoder encoder = new DefaultEncoder(); .... .... output.append(encoder.encodeForJavaScript("some text"));

[meg23]

From lake...@gmail.com on December 07, 2009 18:23:11

Here's a small simple test I just wrote...hope this helps.

import org.owasp.esapi.Encoder; import org.owasp.esapi.reference.DefaultEncoder;

public class SimpleEncoderTest {

public static void main(String[] args) {

    String text = "My funds @ St. Paul's Bank";
    Encoder encoder = new DefaultEncoder();
    System.out.println(encoder.encodeForJavaScript(text));
}

}

Here's the output when I run it with ESAPI-2.0-rc4.zip

Exception in thread "main" java.lang.ExceptionInInitializerError at org.owasp.esapi.reference.DefaultEncoder.(DefaultEncoder.java:6 0) at SimpleEncoderTest.main(SimpleEncoderTest.java:9) Caused by: java.lang.NullPointerException at java.util.Properties$LineReader.readLine(Properties.java:365) at java.util.Properties.load(Properties.java:293) at org.owasp.esapi.reference.DefaultSecurityConfiguration.loadProperties FromStream(DefaultSecurityConfiguration.java:370) at org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfigurat ion(DefaultSecurityConfiguration.java:507) at org.owasp.esapi.reference.DefaultSecurityConfiguration.(Default SecurityConfiguration.java:207) at org.owasp.esapi.ESAPI.(ESAPI.java:87) ... 2 more

Here's the output when I run it with earlier version of the jar - ESAPI-2.0rc2.jar(which doesn't exist on the downloads section anymore, I downloaded it when it was available)

My\x20funds\x20\x40\x20St.\x20Paul\x27s\x20Bank

[meg23]

From planetlevel on December 07, 2009 19:47:16

This looks like the ESAPI.properties file can't be found on the classpath.

[meg23]

From chrisisbeef on December 07, 2009 21:19:32

Beat me to the punch here.

The problem here is the following line:

private final Logger logger = ESAPI.getLogger("Encoder");

This requires that ESAPI.properties be loadable from the classpath. Please also note that the ESAPI.properties file is no longer archived inside of the jar, the distribution comes with the "default" ESAPI.properties in the configuration/.esapi directory.

This exception is not an issue with the code itself, but perhaps this is a documentation issue?

[meg23]

From planetlevel on December 08, 2009 05:56:25

At a minimum, we need a better error message. If possible, should we deploy with a minimal default safe ESAPI.properties inside the jar? Or should we make it operate without an ESAPI.properties if none of the functions called really require it?

[meg23]

From chrisisbeef on December 08, 2009 14:52:14

I think allowing the ESAPI to be used in an un-initialized state creates a couple of problems, namely a significant amount of "defensive-code" spread throughout the codebase to account for the ability of the ESAPI to be in an uninitialized state.

I can definately look into the error messaging for this case. Changing the logger to be initialized in a static block with a try...catch... should allow us to alter the error messaging such that it will be clearer what the problem is.

I am not sure if this will make it into the 2.0-final release at this point. This seems like a pretty low-priority issue compared to some of the other last minute things that need to be dealt with. This is also something that can be fixed as part of a minor or patch release.

This should be scheduled for 2.0.2 or a later patch revision

Labels: -Priority-Medium Priority-Low OpSys-All Component-Logic Usability

[meg23]

From lake...@gmail.com on December 08, 2009 18:09:20

Thanks for all the info guys. I agree with @planetlevel that it'd be convenient if ESAPI.properties can be bundled with jar.

With that said, how/where do I include this properties file to run this successfully? I'd appreciate it if you can explain the steps.

Also, what's the target date for final 2.0 release?

Thank you again for all your help.

[meg23]

From chrisisbeef on December 08, 2009 20:14:24

Originally we included the "default" ESAPI.properties in the jar, but we removed it from the jar and instead included it in the distribution ZIP.

@lakers8 (love the twitterification of the internet) - here are some links: http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/reference/DefaultSecurityConfiguration.html Also, the latest RC can be downloaded which includes documentation and installation instructions: https://code.google.com/p/owasp-esapi-java/downloads/list

[meg23]

From kevin.w.wall@gmail.com on May 08, 2010 19:20:51

Two things to note. One it was decided not to include a default ESAPI.properties file in the ESAPI jar because (among other reasons), this no longer made sense when we stopped shipping ESAPI.properties file with default values for Encryptor.MasterKey and Encryptor.MasterSalt.

Secondly, has anyone ever checked this since Jim rewrote how the ESAPI.properties file is found in DefaultSecurityConfiguration? It may still be blowing up with an ExceptioninInIntializerError, but we should at least be getting something logged.

Since one would see that this problem could happen for almost any reference model class if ESAPI.properties can't be found (since almost all of them try to create a Logger outside of any sort of try / catch block) if an object of an reference implementation class is created like in the example code in Comment 6 by lakers8, we should really encourage people not to create classes in this manner. I'm pretty sure (but have not tried it) that creating an Encoder object via

Encoder encoder = ESAPI.encoder();

rather than via Encoder encoder = new DefaultEncoder(); will shown a more reasonable Exception if we slightly tweak ObjectFactory.make() so that it catches (at least) ExceptionInInitializerError. It would then rethrow this as an ConfigurationException (which is what it truly is) [note: ConfigurationException is an unchecked exception] with ExceptionInInitializerError associated as the 'cause'. That would be a very simple addition, but if would do nothing for cases where people are directly initializing things via the reference model CTORs as was shown in laker8's sample code. Hence it should also include a documentation note somewhere in the ESAPI Developer's Guide.

[meg23]

From lake...@gmail.com on May 25, 2010 17:17:23

Interesting observation folks. I tested this w/out setting ESAPI.properties and it works fine. It seems like all the exceptions are being swallowed, just logging them.

I'm using 1.4.4 version and I'm not using any ESAPI.properties(not even a blank file, file DOES NOT exist) and not seeing any exceptions! Can you guys confirm?

[meg23]

From manico.james@gmail.com on October 31, 2010 23:05:28

Ping. Thoughs on this?

Labels: Milestone-Release2.0

[meg23]

From chrisisbeef on November 01, 2010 00:11:37

If exceptions are indeed being swallowed - this is no bueno. ESAPI should not be allowed to execute code paths in an unconfigured state. I will try to look into it this week.

[meg23]

From kevin.w.wall@gmail.com on February 12, 2011 00:35:46

Chris, have you had a chance to look at this?

Meanwhile, since it is rated as a low priority, I am changing it to the 2.1 milestone.

Labels: -Milestone-Release2.0 Milestone-Release2.1

[meg23]

From kevin.w.wall@gmail.com on September 22, 2014 18:44:57

Labels: FirstBug

[xeno6696]

Had to have been fixed in the intervening years. I cannot reproduce it.

[kwwall]

Bootstrapping the ESAPI logger related properties has long been an iffy proposition, but this probably got ixed when Manico rewrote the DefaultSecurityConfiguration class and since we never had a test case for it, no one (including myself) ever noticed it was fixed. Anyway, I'm good with closing it.