Security

Better XSS Protection for CFML

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.

File Integrity Checking CFIDE

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.