Front and center: ColdFusion.
I've been picking on ColdFusion-built apps again a bit lately, and one of my observations has been that consistently, if mismanaged, the verbose error reporting features in ColdFusion can be really problematic.
HIO-2008-0713 JOBBEX JobSite SQLi & XSS
HIO-2008-0729 BookMine SQLi & XSS
Recently, I stumbled on an example of way too much information disclosure in a few sites running a ColdFusion-built CMS. The error reporting was so verbose it included the base path, data source name, database username, and yes, the database password.
I've cleaned it up for the protection of all involved, but here's a screen shot of only 1/4 of the details this site coughed up when I tweaked the input to a calendar date variable.
When I reached out to the developers of this app (always and immediately responsive), they assured me that this was not due to a flaw in the app, but that the "information should be protected, and is by default for our installations" and that the client disabled the security check and turned debugging on. I accept this explanation entirely, but it leads to the classic debate around the dangers of mismanaged debugging features, be they developer added or ColdFusion feature driven. Stupid user tricks are always an issue, but how much rope should they be given to hang themselves? Does error reporting really need to include the database username and password?
Allow me to present a few different perspectives.
First, rvdh's take on Attacking ColdFusion. Developers can learn a lot from this post, if only in that it precisely points out attack vectors. Ronald sums up my concerns aptly:
"As we know, error messages are important. Especially error messages generated by database software we want to inject. This, is useful for obtaining information about table structures that can be a real time-saver for attackers. If the right information is available, attackers do not have to guess database tables and fields anymore, nor having to brute force them. I have never seen so much information regarding the site's structure, used database, table names, drivers, server setup and other information useful for attackers that those of ColdFusion. It almost says: Please Hack Me!"
As I can't presume to improve on this stance, I won't. Well said.
Next, a developer's take on the issue from Joshua Cyr, who has declared it Check Your Error Output Day. Joshua highlights two key points:
1) Do NOT enable the robust errors setting in CF Administrator.
2) Don't forget to remove debugging dump code.
Heed this advice, ColdFusion fans!
One destination that all "secure" ColdFusion paths should lead to is the use of cfqueryparam. Ronald spells it out well mid way through his discussion, and so do the following resources:
coldfusionjedi
Coldfusion Muse
Further excellent resources for ColdFusion security issues:
SQL Injection Part II (Make Sure You Are Sitting Down)
12Robots.com
In closing, security and convenience needn't always be at odds, but often allowing for both requires a higher state of awareness for developers and end-users. Let common sense prevail; perhaps it'll give me less to do in the way of research. ;-)
del.icio.us | digg
1 comment:
Post a Comment