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.

Wednesday, April 2, 2014

My thoughts on the inevitable ESAPI demotion

So I have taken a few days to think about the upcoming demotion of ESAPI as an OWASP flagship project - see here.  Now I am not sure if my thoughts on this are based from what I read in the announcement and email threads or if I came to this thought on my own.  Regardless, I'm not looking for credit, just wanted to express my thoughts and how this may effect ESAPI4CF.

I feel ESAPI is still a viable project for sure.  It packages the tools to secure your web application in a nice and tidy bundle so everything is at your disposal.  It integrates some of the modules, particularly the Authenticator/CurrentUser with the Logger and each module uses the Logger therefore logging not only the security message, but the user data along with it - this is one of my favorite parts of it.

However, perhaps ESAPI bit off more than it could chew.  Each module of ESAPI tends to have a different focus from authentication, access control, encoding, encryption, logging, etc.  Each of these areas tends to have a different knowledge expert.  Security is far too important to be addressing all of these areas as a "jack of all trades, master of none".  The masters are the ones that need to be involved with each module.

I did see the idea somewhere in that news of splitting the viable ESAPI modules off into their own OWASP projects.  I believe the term that was used was "salvaging" ESAPI - possibly applicable.  I see this as a great idea!  There is already the Java Encoder and Java HTML Sanitizer projects and these could both easily be used in place of the ESAPI Encoder and the ESAPI Validator is/getValidSafeHTML() pieces respectively.  This, I know, was mentioned in the threads somewhere.

However, let's take a another look here.  I agree that breaking the ESAPI modules off into their own projects, with each their own leads, contributors, knowledge experts, is a great idea.  They will each get the focus they well deserve.  But let's not disregard ESAPI itself.  It brings all the security tools together and I don't think that should change.  What I am saying is, instead of the ESAPI project creating each module as part of its project, change ESAPI to include other projects as part of its library.  ESAPI could then focus on integrating the modules and providing the pieces which are not in individual projects.  It could be the glue that brings the OWASP projects together.

ESAPI essentially does this already with the Validator is/getValidSafeHTML() methods which leverage AntiSamy under the hood.  So replacing this one should be fairly straightforward - rip out AntiSamy and replace with the HTML Sanitizer.

As for the Java Encoder, the underlying classes to the ESAPI Encoder module could all be dropped and the DefaultEncoder guts replaced with calls to the Java Encoder.  Easy enough!

In fact, ESAPI was architected to provide "DEFAULT" implementations of the interfaces, so you don't even have to wait for the project to do this - create your own implementation doing exactly this!

Encryption is a big one and I did see it mentioned how this should become its own OWASP project and I wholeheartedly agree with that statement.  That is a complex beast best left to the masters. I welcome seeing this as its own project if it is not already (in case I missed that announcement).

Now there are modules like the Authenticator and AccessController that I don't really see being their own projects which is also fine.  I could be wrong, perhaps there is justification for them being a separate project but I'll leave that decision to those smarter than myself.  Even without their own project, these could still be key components to the ESAPI project and the integration with the other modules.

Anyway, just my thoughts on the announcement.  Personally, I feel that I may not wait for a decision or direction.  I will most likely move forward with changing ESAPI4CF's Encoder module and Validator is/getValidSafeHTML() methods over to the Java Encoder/Sanitzer projects in the next development cycle.  Why?  Cause I think its a great idea and will only help make the ESAPI4CF project better.

Saturday, March 29, 2014

Off-the-Wall Security: ESAPI No Longer an OWASP Flagship Project

Off-the-Wall Security: ESAPI No Longer an OWASP Flagship Project: I read the news today oh, boy… By now, you’ve probably heard about several of the OWASP board members (and perhaps, some bored members...