Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

java.lang.ExceptionInInitializerError in 2.0 version #71

Closed
meg23 opened this issue Nov 13, 2014 · 20 comments
Closed

java.lang.ExceptionInInitializerError in 2.0 version #71

meg23 opened this issue Nov 13, 2014 · 20 comments

Comments

@meg23
Copy link

meg23 commented Nov 13, 2014

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
Copy link
Author

meg23 commented Nov 13, 2014

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

This test was replaced with testConcurrency() in EncoderTest.

Status: WontFix

@meg23
Copy link
Author

meg23 commented Nov 13, 2014

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
Copy link
Author

meg23 commented Nov 13, 2014

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
Copy link
Author

meg23 commented Nov 13, 2014

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
Copy link
Author

meg23 commented Nov 13, 2014

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
Copy link
Author

meg23 commented Nov 13, 2014

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
Copy link
Author

meg23 commented Nov 13, 2014

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

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

@meg23
Copy link
Author

meg23 commented Nov 13, 2014

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
Copy link
Author

meg23 commented Nov 13, 2014

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
Copy link
Author

meg23 commented Nov 13, 2014

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
Copy link
Author

meg23 commented Nov 13, 2014

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
Copy link
Author

meg23 commented Nov 13, 2014

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
Copy link
Author

meg23 commented Nov 13, 2014

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
Copy link
Author

meg23 commented Nov 13, 2014

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
Copy link
Author

meg23 commented Nov 13, 2014

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

Ping. Thoughs on this?

Labels: Milestone-Release2.0

@meg23
Copy link
Author

meg23 commented Nov 13, 2014

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
Copy link
Author

meg23 commented Nov 13, 2014

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
Copy link
Author

meg23 commented Nov 13, 2014

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

Labels: FirstBug

@xeno6696
Copy link
Collaborator

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

@kwwall
Copy link
Contributor

kwwall commented Jul 20, 2017

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.

@kwwall kwwall removed the FirstBug label Dec 30, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants