On our server we are getting errors when using ESAPI functions such as encodeforHTML (randomly, more or less once a week, restarting the server helps as a workaround)
The error message is: java.lang.reflect.InvocationTargetException SecurityConfiguration class (org.owasp.esapi.reference.DefaultSecurityConfiguration) CTOR threw exception.
I attached a screenshot from the stack trace which indicates that there is a problem loading the standard Lucee ESAPI.properties file
org.owasp.esapi.errors.ConfigurationException: ESAPI.properties could not be loaded by any means.
Fail. at org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfiguration(DefaultSecurityConfiguration.java:443) at org.owasp.esapi.reference.DefaultSecurityConfiguration.<init>(DefaultSecurityConfiguration.java:226) at
org.owasp.esapi.reference.DefaultSecurityConfiguration.getInstance(DefaultSecurityConfiguration.java:67) ... 58 more Caused by: java.lang.IllegalArgumentException: Failed to load ESAPI.properties as a classloader resource. at
org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfiguration(DefaultSecurityConfiguration.java:440) ... 61 more
So how can I make sure that ESAPI.properties is always loaded?
Lucee 220.127.116.11 on Ubuntu 18.04 LTS
ESAPI Extension 18.104.22.168 (also tried 22.214.171.124-SNAPSHOT, no difference)
I was tried encodeforhtml(),ESAPIEncode() & ESAPIDecode() in lucee 126.96.36.199 with the ESAPI Extension 188.8.131.52. Both of them works & doesn’t throw any error. I made this check in Windows 10 & my java version is 1.8.0_212 (Oracle Corporation) 64bit. Once i got a issue I’ll post it here.
As I wrote, this happens only from time to time, more or less once a week, my java version is 1.8.0_202 (AdoptOpenJdk) 64bit btw. Thanks for keeping an eye on this
We have that on our servers… I believe it’s because it’s an extension now. In our case, we have a CFC that on init runs
If this runs before an encodeForX() runs, then we get these errors.
Our fix at the moment is that the healthcheck that runs to set the server up, specifically calls encodeForHTML() to output something; this then allows our CFC to init and for other calls to encodeForHTML() to work.
Thanks for your reply, which might be helpful because we had some old code similar to yours in some CFCs which maybe got called once a week…
<cfset esapi = CreateObject("java", "org.owasp.esapi.ESAPI")>
Luckily we are able to get rid of this code and will see what happens.
Had the same issue with fresh install of Windows Server 2019, Lucee 184.108.40.206, ESAPI 220.127.116.11-SNAPSHOT.
To fix I copied ESAPI.properties & validation.properties from a working Coldfusion install into “\lucee\tomcat\lib”
could you add a comment to the above bug? I have just added your affected versions
Did you use the Lucee installer? are you using IIS?
Yes, used the Lucee Windows Installer & Running IIS 10
the problem is that extensions are lazy loaded
are you calling
the workaround is just to call
didn’t resolve the issue in my case.
I’ve now added a comment to the bug from above as well. Hope this helps.
lol, after a many restarts, scratching my head, scouring the internet, Downgrading the ESAPI extension, re-upping the extension.
Determined that if the error stated that it couldn’t read the property files I’d check to see how ACF uses them and where they’re stored and copied them over. Reverted my code to the same state that works in ACF restarted Tomcat and voila success; working assess to the ESAPI encoder methods.
That worked for me, but damn, why is this bug still marked as New and why is it still not fixed 3 years after it was reported?
Just because it hasn’t be resolved yet, doesn’t mean we haven’t been trying to. It’s a difficult bug