search

andytanoko / owasp-esapi-java

Automatically exported from code.google.com/p/owasp-esapi-java
0 stars 0 forks source link

java.lang.ExceptionInInitializerError in 2.0 version #61

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Running a simple test found here:
http://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.<init>(Default
SecurityConfiguration.java:207)
        at org.owasp.esapi.ESAPI.<clinit>(ESAPI.java:87)
        ... 2 more
java.lang.NoClassDefFoundError
        at EncoderConcurrencyTest.run(EncoderConcurrencyTest.java:19)
        at java.lang.Thread.run(Thread.java:595)

Original issue reported on code.google.com by lake...@gmail.com on 24 Nov 2009 at 2:07

GoogleCodeExporter commented 8 years ago 
This test was replaced with testConcurrency() in EncoderTest.

Original comment by chrisisbeef on 2 Dec 2009 at 7:39

GoogleCodeExporter commented 8 years ago 
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.

Original comment by kevin.w.wall@gmail.com on 3 Dec 2009 at 1:39

GoogleCodeExporter commented 8 years ago 
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.

Original comment by lake...@gmail.com on 7 Dec 2009 at 3:50

GoogleCodeExporter commented 8 years ago 
Can you attach a code sample of how you are using the encoder?

Original comment by chrisisbeef on 7 Dec 2009 at 4:30

GoogleCodeExporter commented 8 years ago 
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"));

Original comment by lake...@gmail.com on 8 Dec 2009 at 1:47

GoogleCodeExporter commented 8 years ago 
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.<init>(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.<init>(Default
SecurityConfiguration.java:207)
        at org.owasp.esapi.ESAPI.<clinit>(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

Original comment by lake...@gmail.com on 8 Dec 2009 at 2:23

GoogleCodeExporter commented 8 years ago 
This looks like the ESAPI.properties file can't be found on the classpath.

Original comment by planetlevel on 8 Dec 2009 at 3:47

GoogleCodeExporter commented 8 years ago 
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?

Original comment by chrisisbeef on 8 Dec 2009 at 5:19

GoogleCodeExporter commented 8 years ago 
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?

Original comment by planetlevel on 8 Dec 2009 at 1:56

GoogleCodeExporter commented 8 years ago 
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

Original comment by chrisisbeef on 8 Dec 2009 at 10:52

GoogleCodeExporter commented 8 years ago 
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.

Original comment by lake...@gmail.com on 9 Dec 2009 at 2:09

GoogleCodeExporter commented 8 years ago 
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/refe
rence/DefaultSecurityConfiguration.html

Also, the latest RC can be downloaded which includes documentation and 
installation
instructions:
http://code.google.com/p/owasp-esapi-java/downloads/list

Original comment by chrisisbeef on 9 Dec 2009 at 4:14

GoogleCodeExporter commented 8 years ago 
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<T>.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.

Original comment by kevin.w.wall@gmail.com on 9 May 2010 at 2:20

GoogleCodeExporter commented 8 years ago 
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?

Original comment by lake...@gmail.com on 26 May 2010 at 12:17

GoogleCodeExporter commented 8 years ago 
Ping. Thoughs on this?

Original comment by manico.james@gmail.com on 1 Nov 2010 at 6:05

GoogleCodeExporter commented 8 years ago 
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.

Original comment by chrisisbeef on 1 Nov 2010 at 7:11

GoogleCodeExporter commented 8 years ago 
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.

Original comment by kevin.w.wall@gmail.com on 12 Feb 2011 at 8:35

GoogleCodeExporter commented 8 years ago

Original comment by kevin.w.wall@gmail.com on 23 Sep 2014 at 1:44