It’s getting to the point where people who’re looking at this must be saying: “Man, this is getting really embarrassing for Adobe”.
There’s another (unspecified) security hole that users were made aware of May 8, 2013. The patch was then announced for and released on May 14, 2013, for the days in-between there was only the recommendation to lock away most of /CFIDE (that’s what you essentially should do anyway imho):
/CFIDE/administrator
/CFIDE/adminapi
/CFIDE/gettingstarted
Here are some relevant links:
http://blogs.adobe.com/psirt/2013/05/security-advisory-for-coldfusion-apsa13-03.html
http://www.adobe.com/support/security/advisories/apsa13-03.html
http://helpx.adobe.com/coldfusion/kb/coldfusion-security-hotfix-apsb13-13.html
http://blog.edgewebhosting.net/2013/05/0-day-exploit-for-coldfusion/
Adobe seriously needs to get their act together, the amount of holes and leaks in the whole /CFIDE subsystem is getting way out of hand. They need to urgently rearchitect this part of the CF server.
Without going into details – there should be a clear separation between the “administrator” area/functionality and “stuff” that’s needed for certain tags to function. The latter would be for instance the various .js files for client-side validation, files needed for cfgraph/cfchart and some others. I the recent series of security issues and hacks leads to some rethinking on how this has being built on Adobe’s end. I’d be more than happy to give up one or more of the canonical “new features that demo well but hardly anyone ever uses” for some serious work going into this pain point.
Just saying, YMMV.
You might remember that I’ve blogged about the differences between Railo and ColdFusion in the past. Here’s another one to look out for – this popped up on the railo mailing list the other day.
A poster was asking about some Adobe CF-specific code that was used to retrieve a list of datasources (working on Adobe CFMX 6.1):
<cfset var dsService = CreateObject("java", "coldfusion.server.ServiceFactory").DataSourceService />
<cfset var sDatasources = dsService.getDatasources() />
The question was: How do you make this work on Railo? The direct and short answer is: you can’t (at least not directly). The above code is essentially using a kind-of undocumented feature in Adobe ColdFusion that’s provided through an internal, but exposed Java class called coldfusion.server.ServiceFactory. I’ve blogged about similar issues in the past.
What’s the problem with this? This class being exposed unofficially, it’s nothing one can rely on. You might say: “But this has been working in Adobe Cold Fusion since version {6|7|8|…}”, and you’re right. It has. But it might not work in Adobe ColdFusion 10.something or 11 or 12 etc. I guess you get the idea here. Relying on those kinds of features might be fine for a while but it’s not ok doing so in general and the grand scheme of things. It can be taken away from you within the few seconds it takes to install a security hotfix… cough… cough, let’s not go there maybe… 
For this specific issue – retrieving the datasources – there’s a built-in solution: <cfadmin> with action=”getDatasources” will do the trick nicely. If one was trying to write a codebase that works across Railo and Adobe ColdFusion, this would most likely require conditional coding though.
