ESAPI error after 5.3.9.133 update

[Julian_Halliwell]

OS: Win10
Java Version: 11.0.15 (Eclipse Adoptium) 64bit
Tomcat Version: 9.0.62
Lucee Version: 5.3.9.133

Just updated (via the admin) a local dev 5.3.8.206 Tomcat install to 5.3.9.133 and immediately got an error with this simple line of code:

dump( EncodeForHtml( "test" ) )

java.lang.reflect.InvocationTargetException Encoder class (org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception.

Stack trace

lucee.runtime.exp.NativeException: java.lang.reflect.InvocationTargetException Encoder class (org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception.
 	at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:129)
 	at org.owasp.esapi.ESAPI.encoder(ESAPI.java:99)
 	at org.lucee.extension.esapi.functions.ESAPIEncode.encode(ESAPIEncode.java:63)
 	at org.lucee.extension.esapi.functions.ESAPIEncode.encode(ESAPIEncode.java:56)
 	at org.lucee.extension.esapi.functions.EncodeForHTML.call(EncodeForHTML.java:29)
 	at org.lucee.extension.esapi.functions.EncodeForHTML.call(EncodeForHTML.java:33)
 	at org.lucee.extension.esapi.functions.EncodeForHTML.invoke(EncodeForHTML.java:37)
 	at lucee.runtime.functions.FunctionHandlerPool.invoke(FunctionHandlerPool.java:40)
 	at index_cfm$cf.call(/index.cfm:2)
...[snip]
Caused by: org.owasp.esapi.errors.ConfigurationException: java.lang.reflect.InvocationTargetException Encoder class (org.owasp.esapi.reference.DefaultEncoder) CTOR threw exception.
 	... 43 more
 Caused by: java.lang.reflect.InvocationTargetException
 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
 	at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:86)
 	... 42 more
 Caused by: org.owasp.esapi.errors.ConfigurationException: java.lang.ClassNotFoundException: org.lucee.extension.esapi.log.LogFactoryImpl not found by org.lucee.esapi [62] LogFactory class (org.lucee.extension.esapi.log.LogFactoryImpl) must be in class path.
 	at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:108)
 	at org.owasp.esapi.ESAPI.logFactory(ESAPI.java:137)
 	at org.owasp.esapi.ESAPI.getLogger(ESAPI.java:154)
 	at org.owasp.esapi.reference.DefaultEncoder.<init>(DefaultEncoder.java:75)
 	at org.owasp.esapi.reference.DefaultEncoder.getInstance(DefaultEncoder.java:59)
 	... 47 more
 Caused by: java.lang.ClassNotFoundException: org.lucee.extension.esapi.log.LogFactoryImpl not found by org.lucee.esapi [62]
 	at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1597)
 	at org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
 	at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
 	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
 	at java.base/java.lang.Class.forName0(Native Method)
 	at java.base/java.lang.Class.forName(Class.java:315)
 	at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:74)
 	... 51 more

This trace seems to be identical to the one reported by Dave Stanley a few days ago in the comments of this ticket:

https://luceeserver.atlassian.net/browse/LDEV-2293

But unlike him downgrading the ESAPI extension from version 2.2.4.5 to the previous 2.2.0.1 version fixed it for me.

However, spinning up a command box server running 5.3.9.133 and ESAPI 2.2.4.5 the code runs just fine! So this must be some kind of edge case. Anyone else seen it?

[Julian_Halliwell]

Tried updating the lucee loader jar to the latest but that hasn’t helped. Only downgrading the ESAPI extension works for now.

[Niltwo]

We encounter the same issue. No matter what string we provide, encodeForHTML() causes the same error as mentioned above. We’ll try downgrading ESAPI now.

[bdw429s]

What’s interesting is I received the COTR error a few times recently, but on 5.3.8 and updating to the 5.3.0 snapshot was actually the fix. I don’t really know what the error means though and when I posted it in the #Lucee channel on CFML Slack a couple times, no one really had heard of it so I assumed it was just me.

[Julian_Halliwell]

https://luceeserver.atlassian.net/browse/LDEV-3975

[Niltwo]

I have tested “Julian_Halliwell”'s solution. It fixed the problem for me as well.

After the ESAPI downgrade from 2.2.4.5 to 2.2.0.1 however, I have upgraded ESAPI to 2.2.4.5 again. Now it works like a charm…

Sidenote: After every down-/upgrade I have restartet Lucee.

[Julian_Halliwell]

@Niltwo

I have upgraded ESAPI to 2.2.4.5 again. Now it works like a charm…

Interesting. I tried that but the error returned when I restarted Lucee.

[micstriit]

I’m not sure what constellation of upgrade/downgrade is causing this, but i will further investigate.
Problem is the file /lucee/temp/properties/ESAPI.properties that contains this line:

ESAPI.Logger=org.lucee.extension.esapi.log.LogFactoryImpl

We had to set this line so, the ESAPI library is not using log4j directly anymore, instead it is using our own factory that point to the Lucee core log framework (what is log4j2).

Problem for sure is, when you downgrade to an older version and you have this setting, you get this bug, because the older implementation simply does not have this class.

we did fix this by changing the location of that properties file to
/Lucee/temp/esapi224/ESAPI.properties, so every version has it’s own properties file and they no longer conflict.

As a workariund, simply delete the file /lucee/temp/properties/ESAPI.properties

[Julian_Halliwell]

@micstriit

As a workariund, simply delete the file /lucee/temp/properties/ESAPI.properties

Thanks, Micha, but I that didn’t work for me. I also tried deleting the entire contents of the temp/ directory but the error was still thrown. With each change I restarted Tomcat/Lucee before testing again.

Once again, downgrading to ESAPI 2.2.0.1 did fix it.

[Julian_Halliwell]

@micstriit

Problem for sure is, when you downgrade to an older version and you have this setting, you get this bug, because the older implementation simply does not have this class.

That would make sense if I had upgraded to ESAPI 2.2.4.5 and then (for some reason) downgraded again to 2.2.0.1.

But I didn’t. I’ve been testing with only the latest ESAPI extension installed. Surely that does have the org.lucee.extension.esapi.log.LogFactoryImpl class and the reference in the new esapi224/ESAPI.properties file should work?

[Julian_Halliwell]

Maybe this isn’t relevant but the following entry in my bundles listing looks suspicious:

This is after upgrading ESAPI to 2.2.4.5 and double-checking that the previous version bundles have gone from by bundles directory. In which case why is that older version still present and active? Where can it be coming from? Have searched my entire Tomcat/Lucee install folder but can’t locate it.

[Niltwo]

That’s interesting.
For comparison: I have only one version active.

[Julian_Halliwell]

@Julian_Halliwell

after upgrading ESAPI to 2.2.4.5 and double-checking that the previous version bundles have gone from by bundles directory

I should have triple-checked my tomcat\lucee-server\bundles folder. Found the offending file which was named org-lucee-esapi-2-1-0-1.jar with hyphens instead of dots. Deleted. Restarted. All working again

@micstriit So is this just a clean-up problem when the extension is upgraded?

[Julian_Halliwell]

@Julian_Halliwell

So is this just a clean-up problem when the extension is upgraded

…and why wouldn’t OSGi ensure the new jar is used even if the old one is still there?