> > I've got bad news for you. Stick this in Google: > > [product] default vulnerability > > and prepare to be amazed. Some suggestions: PHP, IIS, Apache. Not all > > allow remote users to execute arbitrary code, but plenty do. > > I get it. Because other technologies and applications are bad it's fine for > CF to be bad, too. Regardless of how much we have to pay for it.
I don't think those other technologies and applications are bad. I do think that the very act of exposing a service that lets anybody in the world execute code on my server is inherently dangerous - because it is. Let's assume, for the sake of argument, that CF 11 comes out with absolutely no vulnerabilities in the CF Administrator. Would you then think it's ok to expose it to the public? Because it's not. It's a management console. You don't expose management consoles to the public. But it's also a web application - it has to be deployed on your web server. I trust myself to configure that web server. I don't trust Adobe to have the magical install settings to do that for me, while not interfering with other things I'm using that web server for. > > I submit to you that it should not be surprising that products explicitly > > designed for security purposes, like firewalls and VPNs, will be expected to > > be secure by default. > > "I submit to you", LOL. Awesome. So, a business invests in all of the > security available, such as firewalls, only to have CF open the gates What > a brilliant piece of logic. I submit to you, that's screwed up. If you think that just buying products without learning how to use them is equal to "invests in all the security available", you are wrong. Security is people and processes, not just products. If you could just buy security as a product, there would be at least one very rich company selling that product. > > > The notion that it's the sys admins fault if a product installs in an > > > unsecure way beggers belief. > > > > No, that's not the sysadmins' fault. But leaving a product at the default > > install state on an untrusted network - that IS the sysadmins' > > fault. How is a sysadmin going to make sure that the developers' > > applications are secured properly, if he doesn't know enough to secure the > > one web application that's packaged with the product? > > The long list of security measures that have to take place after a standard > CF install are ridiculous. Believe it or not, sys admins have better things > to do with their time. The long list of security measures is a list rather than an automated script because not everything in that list applies to every install. If your job is to administer a given system, you do not have anything better to do with your time than to learn how that system works. That is your job. > Dave, I suggest you wander down to your corporate IT department and offer to > help them out for a few days so you get a taste of reality. Reality, like good ale, is often bitter. My reality is that I work with corporate IT departments around the world helping them to deploy their systems - some CF, and many others as well. And deploying these systems is often difficult and complicated. Security is difficult. That's the way it is. If you're exposing an application server to an untrusted network, that should scare the living shit out of you. It scares me every time. An application server is explicitly designed to allow remote code execution on your system. This is inherently dangerous. If you honestly think it should be point and click and walk away, you are in the wrong business. If you can't be bothered to learn how to secure the one web application that ships with CF - the one that is used to manage CF, and by default requires a simple password for access - how are you going to secure the applications your developers build? It's not like securing this web application is very hard, either - but there are enough variations in how you might do it that it's unreasonable to expect Adobe to do it for you. For example, I typically do it by following a simple four-step process: 1. install using the built-in web server on the non-standard port it uses by default 2. connect the "real" web server after the install using wsconfig 3. configure that web server to disallow requests to URLs containing /CFIDE/administrator/ 4. limit access to the non-standard port (maybe using network access controls, maybe by configuring the built-in web server to only allow connections from specific IP addresses, maybe both) But that approach isn't going to work for all installs. Dave Watts, CTO, Fig Leaf Software 1-202-527-9569 http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:358234 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
