Thursday, October 23, 2014

Don't use ESAPI encoders in ColdFusion/Railo!

We came across this issue awhile ago at my place of work and I never posted anything about it.  I recently saw Jason Dean's notes from CFSummt about using ESAPI4CF for CF8/9 and it reminded me that I should point this out.

I do not recommend using the encoders in ESAPI or ESAPI4CF on ColdFusion 8.  This version of CF Server includes ESAPI v1.4.4 which had a documented concurrency issue around the encoders.  The encoder library was rewritten for ESAPI v2.x so I believe this was addressed.

We personally experienced this concurrency issue under ColdFusion 8 at my place of work.  The issue can arise is high volume applications and causes the thread to hang.  The only way we could find to recover from this hung thread was a CF server restart.

In the end, we ended up switching all of our encoder logic over to the OWASP Java Encoder project and have not had any issues with it.

So my recommendation - don't use ESAPI or ESAPI4CF encoders for CF8.

While we are on the subject I wanted to bring up the use of the ESAPI encoders for any CF/Railo version and yes, I am including the native encodeFor* functions added in CF10.  I say again, don't use them!  They are performance hogs!

While I was testing the Java Encoder alternative I did some performance testing comparing the ESAPI encoders to the Java Encoders.  Huge difference!  Now I will make it known that the Java Encoders are not as strict on HTML encoding everything outside of the low ASCII range, in fact it encodes very few characters.  But I put my trust in this project (which is an active project unlike ESAPI) that they know what they are doing and only encode what is necessary to ensure a safe browsing experience.  With that said, the numbers do not lie.  The Java Encoders were way faster than the ESAPI encoders in the majority of cases.

Keep in mind that the native encodeFor* functions added in CF10 and Railo are simply using the ESAPI encoders under the hood.  I performance tested against the native encoders as well and came away with the same results as testing directly against the ESAPI encoders - they are SLOW!  I am quite sure it is due to the excessive amount of characters it is attempting to encode OR that the library has not been maintained in quite awhile as no one is improving it.

Regardless of the reason, my recommendation on ESAPI encoders overall - don't use them!  Choose the OWASP Java Encoder project as an alternative.

UPDATE 2015-03-30: The ESAPI for CFML project will be including a setting to allow you to use the Java Encoder project instead of the ESAPI encoders in the 2.x version which is still in development.  This will give you the flexibility to choose which encoder solution works best for your project.