Getting org.owasp.esapi.errors.ConfigurationException: java.lang.reflect.InvocationTargetException Encoder class (org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception. about esapi-java-legacy HOT 4 OPEN

Looking at the stack trace, and the implementation of the DefaultEncoder class, my guess is that you're missing a piece of configuration.

https://github.com/ESAPI/esapi-java-legacy/blob/develop/src/main/java/org/owasp/esapi/reference/DefaultEncoder.java
Line 118 is trying to iterate the values configured as the default canonicalization codecs (from line 109)

These will default to HTML, Percent, and Javascript unless overridden by the existing configuration:
https://github.com/ESAPI/esapi-java-legacy/blob/develop/src/main/java/org/owasp/esapi/reference/DefaultSecurityConfiguration.java (line 1060)

The property value that would override is "Encoder.DefaultCodecList"
https://github.com/ESAPI/esapi-java-legacy/blob/develop/src/main/java/org/owasp/esapi/PropNames.java (line 67)

My guess is that the ESAPI.properties file you're using has that property in it, and sets the entry to empty.

Please compare the ESAPI.properties file bundled with 2.5.3.1 against the file you're using to ensure you have all required values specified.
https://github.com/ESAPI/esapi-java-legacy/releases/download/esapi-2.5.3.1/esapi-2.5.3.1-configuration.jar

from esapi-java-legacy.

Also, it would be really useful if you could show us the call to ESAPI that you are doing. Like for instance are you calling something directly like:

    String safe = ESAPI.encoder().encodeForHTML( untrustedData )

or are you doing something more esoteric, like calling DefaultEncoder CTOR directly with a specific list of codecs? It looks like your exception is throwing a NPE at line 118 of DefaultEncoder, which means it is calling this CTOR. IIRC, that is not the usual one that folks call, but since there is no check there to see if the list of strings of codec names is null (maybe you could call that a bug, but it also may be considered a bug in the application code), so it would help us immensely if you can shed a few details onto what you are doing as well as any customization that you may have made to any of the ESAPI.properties file's properties.

from esapi-java-legacy.

We have not directly invoking ESAPI methods in our code, it is getting invoked through org.opensaml.
We already added below ESAPI.properties in our project, but not sure whether that ESAPI.properties is getting called or not.

ESAPI.properties.zip

from esapi-java-legacy.

@PriyatamaB and @jeremiahjstacey - I checked the ESAPI.properties file for the property Encoder.DefaultCodecList. As expected it was set as:

Encoder.DefaultCodecList=HTMLEntityCodec,PercentCodec,JavaScriptCodec

Now @PriyatamaB, you didn't mention what version of OpenSAML that you were using, but the last time I checked in 3Q2023, the latest version of OpenSAML was 2.6.4 and was released in 2015. (And the Maven Central repo entry for OpenSAML of https://mvnrepository.com/artifact/org.opensaml/opensaml seems to bear that out.) If that's the version that @PriyatamaB is using, my research done in 3Q2023 for a talk given at Columbus BSides and OWASP Global AppSec DC in the fall of 2023 shows that that particular version OpenSAML jar was using ESAPI 2.0.1 which was released 7/25/2011!!! The 2.0.1 release wasn't even the most recent ESAPI release in 2015. Furthermore, OpenSAML completely overwrote the ESAPI initialization normally done via ESAPI's DefaultSecurityConfiguration class, so I would say that all bets are off in terms of getting it to work with later versions of ESAPI without some extensive hacking to OpenSAML itself. For details, see the 2 OpenSAML Java source files org/opensaml/DefaultBootstrap.java and org/opensaml/ESAPISecurityConfig.java extracted from the source jar file at https://repo1.maven.org/maven2/org/opensaml/opensaml/2.6.4/opensaml-2.6.4-sources.jar.

Also, looking at the OpenSAML use of ESAPI's output encoder, it looks as though it is using Encoder.encodeForHTMLAttribute to encode URL endpoints, but URLs should really be encoded using Encoder.encodeForURL. (There is of course a partially misleading Stack Overflow post (the 2nd answer is correct) about this so perhaps this is not all their fault, but I think this predates Matt and my monitoring of SO for ESAPI related posts.)

Anyway, I suspect OpenSAML taking over the initialization of ESAPI is why ESAPI 2.5.3.1 and likely some more recent earlier versions as well is why ESAPI is failing. As I said, all bets are off when you are using ESAPI in this convoluted manner. In reality, it does look as though OpenSAML really is no longer (actively) supported, so if you really wish to fix this properly, I suspect that you may need to fork OpenSAML and fix things in your forked version. (And if you are going to do that, I personally would suggest replacing their use of ESAPI's Encoder with the OWASP Java Encoder project as it has far less dependencies and one needn't worry about intertwining ESAPI's Logger and initialization in there.)

I will give @PriyatamaB one last chance to reply, but I am inclined to close this as "Won't Fix" because I don't have any evidence that this is actually an ESAPI bug. I think it's an OpenSAML bug.

from esapi-java-legacy.