So like quite a few others, I have been working with Groovy and Grails much more. I’m not going to go into how much better or more joyful it is to work with than CFML but to take ideas from it and lobby to get them implemented in Adobe ColdFusion and Railo.

The ESAPI encoders are now baked into the language for both Adobe ColdFusion 10 and Railo 4 and can help prevent XSS by using the proper encoder depending upon output context, EncodeForHTML(string) [ACF, Railo] or ESAPIEncode("HTML", string) [Railo] in most cases. It is possible to get the same functionality in older versions using ESAPI4CF or CFBackPort. But the problem is to fully protect against XSS you need to go through all the code in an application that renders output and modify it to use the proper encoder.

I had intended to get this posting out earlier when I updated Unofficial Updater 2 on the 16th. Here are the changes that were made with the latest release UU2.

• Now works with all releases of ColdFusion 9. (9.0.0, 9.0.1, and 9.0.2)
• Applies APSB13-03
• New website to download https://www.uu-2.download, since github ended support for uploads

So with the most recent attack on ColdFusion (detailed by Charlie Arehart, Part #1, Part #2) there was a comment left on the post that got me a bit concerned where the comment said all you had to do is search for h.cfm to remove the file placed by the attacker. My experience has been if an attacker has had access to the server there is no absolute way of knowing what they might have done, even with good log reconstruction. As I noted in my comment in one instance I have previously encountered a situation where an attacker put a file called fck_dialog_common.cfm into CFIDE/scripts/ajax/FCKeditor/editor/dialog/common. At first glance of the directory it looks right, but inactuallity it a file that was buried and hidden so the attacker could come back through it instead of the original entry point. 

The only way to know is to have a way of doing file integrity checks against a good known source. The initial attack that was posted to the Adobe forum was found because an intrustion detection system (IDS) alerted the administrator that a file had been written to CFIDE that was called h.cfm.

Well, the long nightmare known as patching Adobe ColdFusion 8.0.1 is now over. With the release of APSB12-21 last week and core support ending on July 31 for ColdFusion 8 there will be no more security hot fixes released for it (noted at the bottom of the technote).

So if you didn’t see it via the ColdFusion Blog or by the new indicator inside ColdFusion Administrator, the first update for ColdFusion 10 dropped on August 31st.

First, I have to say “Thank You” to the ColdFusion Team. FINALLY there is an easy way to patch ColdFusion and I can get out of the business of building a patch tool for ColdFusion. The other good thing is that the TechNote actually links the bug IDs back to the ColdFusion bugbase.