So there has been yet another 0-day found that can exploit ColdFusion by not having directories within CFIDE properly secured as noted in APSA13-03 from Adobe. If you haven’t properly secured CFIDE that is public facing, it is only a matter of time until it gets hacked. The previous two that were found in January and April of this year should have been motivation enough.
Unofficial Updater 2 has been updated (April 11th) to now apply the latest ColdFusion security hotfix APSB13-10 that was released on April 9th.
Stay on top of the patching since on April 10th a Metasploit exploit was released that exploits the previous security hotfix APSB13-03. It is only a matter of time until there is an exploit that goes after the latest security hotfix or the next unknown one.
So last week the ColdFusion product team announced a survey to get selected into the pre-release program for the next version of ColdFusion (refuse to call it by the code name since all I think of is Splenda). A lot of this has been rolling around in my head since they published the roadmap last August and really need to get this out before there is a possibility of being included in the pre-release and the requisite NDA.
So if you have been following things, Adobe released cumulative hotfixes to allow for Java 7 support and to update <cfmap> to use Google Maps API v3 instead of v2. Only problem is along the way they have had to update them a few times. It is exactly this situation which drove me to create Unofficial Updater 2 originally.
Frankly, the entire past 2 weeks should not have occurred. This really shines a light on how poorly thought out the Adobe ColdFusion update product teams’s release process is. And this is not the first time they have had to do multiple re-releases of hot fixes. APSB11-04 once, APSB11-14 twice, APSB12-06 once for CF801 only and pulled Update 3 for CF10. That track record does not inspire confidence.
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.