how to check if a remote file exists
hi, i have w2k3 server that holds a text file, say x.txt, generated by an VFP9 app., on a separate server i have a cf9 app. that needs to check for file x, if it exists get a copy of it and merge it with another text file that is generated by the app. well, how can i do the checking part? ~| 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:358220 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: how to check if a remote file exists
You can use fileExists w/ a URL but unfortunately, if the server has a 404 handler than it will return true even when the 404 handler fires. cfif fileExists(http://www.raymondcamden.com/index2332.cfm;) yes /cfif cfhttp url=http://www.raymondcamden.com/index2332.cfm; cfdump var=#cfhttp# If a 404 handler isn't there, then this would have worked. On Sat, Mar 29, 2014 at 2:19 AM, safo 2000 safokas...@hotmail.com wrote: hi, i have w2k3 server that holds a text file, say x.txt, generated by an VFP9 app., on a separate server i have a cf9 app. that needs to check for file x, if it exists get a copy of it and merge it with another text file that is generated by the app. well, how can i do the checking part? ~| 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:358221 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: The long tail of ColdFusion fail
So cost has nothing to do with it. How enlightening, as ever. -Original Message- From: Dave Watts [mailto:dwa...@figleaf.com] Sent: 28 March 2014 17:52 To: cf-talk Subject: Re: The long tail of ColdFusion fail sure something may break by being locked down, but as I said earlier, you have 2 choices.. 1. out of the box install, not secure, but your site works just fine.. So nothing to learn unless you choose to. User continues in blissful ignorance. 2. out of the box, locked down and secure, but site may break, so you have to learn something about CF security to get it working. Learning is required and not optional, user has now learnt something new and has a secure system. surely this is a no brainier. This explains why absolutely no one uses Windows web servers. After all, that's how Unix web servers always worked, pretty much. You had to know what you were doing to get them working. I can see now why Windows never got any market share. (note: this is not an endorsement of one or the other, just an observation) 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:358222 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: The long tail of ColdFusion fail
Dave, I am curious. Have you ever, even once, changed your mind because of what someone has told you? -Original Message- From: Dave Watts [mailto:dwa...@figleaf.com] Sent: 28 March 2014 18:07 To: cf-talk Subject: Re: The long tail of ColdFusion fail if you think no-one uses Windows web servers then you are wrong, very wrong. Uh, yeah, I know that. That was my point. It would seem you also think that Windows is not locked down by default, that may have been true once upon a time, but is no longer the case and hasn't been for many years.Certainly since Windows Server 2008, you must specifically choose which roles to install, everything is not installed by default, the firewall is also installed and enabled by default with only the basic required services allowed through and networking is also disabled. I guess you can interpret many years however you like, but the simple fact is, from the beginning and through the majority of the lifespan of Windows servers, this was not the default. And I don't think Windows would have been nearly as popular for servers if it had started out that way. The fact that things worked by default gave Windows market share. 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:358223 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: The long tail of ColdFusion fail
From what I have learnt from this thread so far, Adobe has actually got worse. -Original Message- From: Claude Schnéegans schneeg...@internetique.com [mailto:=?ISO-8859-1?Q?Claude_Schn=E9egans schneegans@interneti=71?= =?ISO-8859-1?Q?ue.com=3E?=] Sent: 28 March 2014 18:10 To: cf-talk Subject: Re: The long tail of ColdFusion fail It's Microsoft's approach ... now. But it took them a long time to get there. You're probably right. The point here is that it is taking even a longer time to Adobe. ~| 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:358224 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: The long tail of ColdFusion fail
-Original Message- From: Dave Watts [mailto:dwa...@figleaf.com] Sent: 28 March 2014 18:41 To: cf-talk Subject: Re: The long tail of ColdFusion fail 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 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. 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. 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. -- I am using the free version of SPAMfighter. SPAMfighter has removed 10680 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len Do you have a slow PC? Try a Free scan http://www.spamfighter.com/SLOW-PCfighter?cid=sigen ~| 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:358225 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: The long tail of ColdFusion fail
+1 -Original Message- From: Russ Michaels [mailto:r...@michaels.me.uk] Sent: 28 March 2014 20:42 To: cf-talk Subject: Re: The long tail of ColdFusion fail A locked door is useless if you leave the windows open. Russ Michaels www.michaels.me.uk cfmldeveloper.com cflive.net cfsearch.com On 28 Mar 2014 19:09, Dave Watts dwa...@figleaf.com wrote: I also once had a client who did this, they were Linux heads who thought that hiding the sucky insecure windows/cf server behind a linux server and doing a reverse proxy would make it secure. There is no such thing as make it secure, of course. But it is more secure. It solves one specific security problem - preventing executable code from being directly accessed from an untrusted network. But of course it didn't as everything still works the same way, the SQL injections still got through, the insecure file upload forms still allowed files to be uploaded, which could then be executed as they had cfexecute and cfregistry enabled. So what you're saying is that, despite the fact that the environment was (more) secure by default, developers accidentally wrote exploitable code? I have the feeling there's some lesson to be drawn from this. I wonder what it is? 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:358226 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: The long tail of ColdFusion fail
Yeah, Dave Haven¹t you ³learnt² anything? On 3/29/14, 8:38 AM, Jenny Gavin-Wear jenn...@fasttrackonline.co.uk wrote: Dave, I am curious. Have you ever, even once, changed your mind because of what someone has told you? -Original Message- From: Dave Watts [mailto:dwa...@figleaf.com] Sent: 28 March 2014 18:07 To: cf-talk Subject: Re: The long tail of ColdFusion fail if you think no-one uses Windows web servers then you are wrong, very wrong. Uh, yeah, I know that. That was my point. It would seem you also think that Windows is not locked down by default, that may have been true once upon a time, but is no longer the case and hasn't been for many years.Certainly since Windows Server 2008, you must specifically choose which roles to install, everything is not installed by default, the firewall is also installed and enabled by default with only the basic required services allowed through and networking is also disabled. I guess you can interpret many years however you like, but the simple fact is, from the beginning and through the majority of the lifespan of Windows servers, this was not the default. And I don't think Windows would have been nearly as popular for servers if it had started out that way. The fact that things worked by default gave Windows market share. 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:358227 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: The long tail of ColdFusion fail
Dave, I am curious. Have you ever, even once, changed your mind because of what someone has told you? Since you ask, sure, all the time. I respond to evidence and logic. I just don't think those two things support your position as strongly as you think they do. 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:358228 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: The long tail of ColdFusion fail
I also once had a client who did this, they were Linux heads who thought that hiding the sucky insecure windows/cf server behind a linux server and doing a reverse proxy would make it secure. There is no such thing as make it secure, of course. But it is more secure. It solves one specific security problem - preventing executable code from being directly accessed from an untrusted network. But of course it didn't as everything still works the same way, the SQL injections still got through, the insecure file upload forms still allowed files to be uploaded, which could then be executed as they had cfexecute and cfregistry enabled. So what you're saying is that, despite the fact that the environment was (more) secure by default, developers accidentally wrote exploitable code? I have the feeling there's some lesson to be drawn from this. I wonder what it is? A locked door is useless if you leave the windows open. I think we might be in agreement! But maybe for different reasons. Setting up application servers to be secure is hard. Ensuring that application code doesn't contain vulnerabilities is hard. And you're not going to be able to solve security problems with an installer. People need to know what they're doing. They need to have a base level of competence at their jobs. No installer in the world is going to idiot-proof web applications. 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:358229 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: how to check if a remote file exists
You can use fileExists w/ a URL but unfortunately, if the server has a 404 handler than it will return true even when the 404 handler fires. cfif fileExists(http://www.raymondcamden.com/index2332.cfm;) yes /cfif cfhttp url=http://www.raymondcamden.com/index2332.cfm; cfdump var=#cfhttp# If a 404 handler isn't there, then this would have worked. If you're building a 404 handler, you should actually make sure it returns a 404 status code. You can do this easily enough with CFHEADER. The page can contain whatever HTML you want to present to the user, still. I run into this quite a bit working with the Google Search Appliance. The GSA relies on status codes by default to identify which pages to index. While it's possible to give it a way to identify soft 404s (http://en.wikipedia.org/wiki/HTTP_404#Soft_404), it's much easier just to have real 404s in the first place. 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:358230 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: how to check if a remote file exists
Oh good point there. So - ignoring my server where I don't have a proper 404 (grin), this should work for you: cfhttp url=http://www.cnn.com/index2332.cfm; cfif cfhttp.responseheader.status_code is 200 good /cfif On Sat, Mar 29, 2014 at 9:38 AM, Dave Watts dwa...@figleaf.com wrote: You can use fileExists w/ a URL but unfortunately, if the server has a 404 handler than it will return true even when the 404 handler fires. cfif fileExists(http://www.raymondcamden.com/index2332.cfm;) yes /cfif cfhttp url=http://www.raymondcamden.com/index2332.cfm; cfdump var=#cfhttp# If a 404 handler isn't there, then this would have worked. If you're building a 404 handler, you should actually make sure it returns a 404 status code. You can do this easily enough with CFHEADER. The page can contain whatever HTML you want to present to the user, still. I run into this quite a bit working with the Google Search Appliance. The GSA relies on status codes by default to identify which pages to index. While it's possible to give it a way to identify soft 404s (http://en.wikipedia.org/wiki/HTTP_404#Soft_404), it's much easier just to have real 404s in the first place. 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:358231 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: how to check if a remote file exists
Oh good point there. So - ignoring my server where I don't have a proper 404 (grin), this should work for you: cfhttp url=http://www.cnn.com/index2332.cfm; cfif cfhttp.responseheader.status_code is 200 good /cfif Your original point is perfectly valid, though - lots of people don't return proper status codes. So it is useful to have some additional logic to deal with soft 404s if you're testing against unfamiliar servers. 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:358232 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: The long tail of ColdFusion fail
I don;t think anyone has said that the Cf installer should magically secure their applications, this is a whole different issue and no blame can be laid at Adobe's feet or the installer for poorly written code. On Sat, Mar 29, 2014 at 2:23 PM, Dave Watts dwa...@figleaf.com wrote: I also once had a client who did this, they were Linux heads who thought that hiding the sucky insecure windows/cf server behind a linux server and doing a reverse proxy would make it secure. There is no such thing as make it secure, of course. But it is more secure. It solves one specific security problem - preventing executable code from being directly accessed from an untrusted network. But of course it didn't as everything still works the same way, the SQL injections still got through, the insecure file upload forms still allowed files to be uploaded, which could then be executed as they had cfexecute and cfregistry enabled. So what you're saying is that, despite the fact that the environment was (more) secure by default, developers accidentally wrote exploitable code? I have the feeling there's some lesson to be drawn from this. I wonder what it is? A locked door is useless if you leave the windows open. I think we might be in agreement! But maybe for different reasons. Setting up application servers to be secure is hard. Ensuring that application code doesn't contain vulnerabilities is hard. And you're not going to be able to solve security problems with an installer. People need to know what they're doing. They need to have a base level of competence at their jobs. No installer in the world is going to idiot-proof web applications. 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:358233 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: The long tail of ColdFusion fail
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!
RE: The long tail of ColdFusion fail
Correcting the installer won't solve all problems, but it should not be the CAUSE of problems. Hey sys admin, I'm going to make your day! Here's an app which we KNOW has security issues and requires a lot of maintenance. You're going to have to become an expert in this new technology, invest even more time patching it and discover security leaks you won't even be informed about, it'll be your job to tell the app vendor about that, too! In addition, the company that produces the application got hacked recently and the hackers got a lot of user data. But we developers, we're not worried about this because if our server gets hacked (through widely published methods well known by the hacker community), it's all YOUR fault! I mean, it's not like you've got anything better to do, is it? *sound of running feet and screaming* -Original Message- From: Dave Watts [mailto:dwa...@figleaf.com] Sent: 29 March 2014 14:23 To: cf-talk Subject: Re: The long tail of ColdFusion fail I also once had a client who did this, they were Linux heads who thought that hiding the sucky insecure windows/cf server behind a linux server and doing a reverse proxy would make it secure. There is no such thing as make it secure, of course. But it is more secure. It solves one specific security problem - preventing executable code from being directly accessed from an untrusted network. But of course it didn't as everything still works the same way, the SQL injections still got through, the insecure file upload forms still allowed files to be uploaded, which could then be executed as they had cfexecute and cfregistry enabled. So what you're saying is that, despite the fact that the environment was (more) secure by default, developers accidentally wrote exploitable code? I have the feeling there's some lesson to be drawn from this. I wonder what it is? A locked door is useless if you leave the windows open. I think we might be in agreement! But maybe for different reasons. Setting up application servers to be secure is hard. Ensuring that application code doesn't contain vulnerabilities is hard. And you're not going to be able to solve security problems with an installer. People need to know what they're doing. They need to have a base level of competence at their jobs. No installer in the world is going to idiot-proof web applications. 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:358235 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: The long tail of ColdFusion fail
Correcting the installer won't solve all problems, but it should not be the CAUSE of problems The installer is installing an application server. Again, this is inherently dangerous, period, end of story. This particular installer sets up a web application that is needed to configure the server, and has to immediately function in order to complete the installation process. The web application is the source of nearly every CF vulnerability, and has been for many years. In addition, it's very easy to install that web application securely with just a little bit of knowledge, as I outlined previously. And hey! if you install CF 10 today, it gives you a little checkbox called Secure Profile which does exactly what you want! (Assuming that what you want is to limit access to the CF Administrator, disable RDS, require a complex password, disable debugging and detailed error messages, etc, etc.) I'm still not going to rely on that to secure access to CF Administrator, because I prefer to simply block access to it entirely from untrusted networks. But it seems to solve the specific problem you're complaining about. So, honestly, I'm not really sure what you're going on about, other than administrators shouldn't be bothered to learn what they're doing. Hey sys admin, I'm going to make your day! Here's an app which we KNOW has security issues and requires a lot of maintenance. You're going to have to become an expert in this new technology, invest even more time patching it and discover security leaks you won't even be informed about, it'll be your job to tell the app vendor about that, too! Well, honestly, if you set it up correctly in the first place and followed the instructions in the lockdown guide where appropriate, you actually wouldn't have to worry nearly as much about patches. Given that the vast majority of CF vulnerabilities are in the CF Administrator specifically, if you configure access to that correctly you don't have to become an expert, spend a lot of time patching, or discovering security leaks. The same is true for EVERY PIECE OF SOFTWARE YOU EXPOSE TO UNTRUSTED NETWORKS. People used to expose database servers to the public. Whether a database server has known vulnerabilities or not, that's just a bad idea, and anyone who's installing a database server should know better. In addition, the company that produces the application got hacked recently and the hackers got a lot of user data. I'm not sure how that's all that important here. Adobe was not hacked through a CF vulnerability. If you want to find people using CF, you don't need to hack Adobe to get that. There are lots of people who have that data. Admittedly, if you want to find people who bought older versions of CF, that would be easier to get from Adobe, but that wouldn't tell you whether those people are still using CF or whether their servers were set up properly. In addition, that would have nothing to do with what you want Adobe to do now. To the best of my knowledge, Adobe does not possess a time machine, so they can't go back in time to fix problems in old installed systems other than by providing patches. I guess that it's a good thing that administrators don't have to worry about patching anything else. But we developers, we're not worried about this because if our server gets hacked (through widely published methods well known by the hacker community), it's all YOUR fault! I mean, it's not like you've got anything better to do, is it? *sound of running feet and screaming* I'd be interested to hear how security audits work in your organization. On second though, maybe not. If you think vulnerabilities don't exist for other products, through widely published methods well known by the hacker community, I don't know what to tell you. If you install any application that will be exposed to untrusted networks, you are expected to apply basic due diligence. If you cannot do that, you should not be administering that system. And for CF, at least, it's easy to block the widely published methods well known by the hacker community. 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:358236 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: The long tail of ColdFusion fail
Please send a photo of your world, I'd like to know what colour the sky is? You are telling ME how a sys admin or IT manager does their job? Well thanks. -Original Message- From: Dave Watts [mailto:dwa...@figleaf.com] Sent: 29 March 2014 16:50 To: cf-talk Subject: Re: The long tail of ColdFusion fail Correcting the installer won't solve all problems, but it should not be the CAUSE of problems The installer is installing an application server. Again, this is inherently dangerous, period, end of story. This particular installer sets up a web application that is needed to configure the server, and has to immediately function in order to complete the installation process. The web application is the source of nearly every CF vulnerability, and has been for many years. In addition, it's very easy to install that web application securely with just a little bit of knowledge, as I outlined previously. And hey! if you install CF 10 today, it gives you a little checkbox called Secure Profile which does exactly what you want! (Assuming that what you want is to limit access to the CF Administrator, disable RDS, require a complex password, disable debugging and detailed error messages, etc, etc.) I'm still not going to rely on that to secure access to CF Administrator, because I prefer to simply block access to it entirely from untrusted networks. But it seems to solve the specific problem you're complaining about. So, honestly, I'm not really sure what you're going on about, other than administrators shouldn't be bothered to learn what they're doing. Hey sys admin, I'm going to make your day! Here's an app which we KNOW has security issues and requires a lot of maintenance. You're going to have to become an expert in this new technology, invest even more time patching it and discover security leaks you won't even be informed about, it'll be your job to tell the app vendor about that, too! Well, honestly, if you set it up correctly in the first place and followed the instructions in the lockdown guide where appropriate, you actually wouldn't have to worry nearly as much about patches. Given that the vast majority of CF vulnerabilities are in the CF Administrator specifically, if you configure access to that correctly you don't have to become an expert, spend a lot of time patching, or discovering security leaks. The same is true for EVERY PIECE OF SOFTWARE YOU EXPOSE TO UNTRUSTED NETWORKS. People used to expose database servers to the public. Whether a database server has known vulnerabilities or not, that's just a bad idea, and anyone who's installing a database server should know better. In addition, the company that produces the application got hacked recently and the hackers got a lot of user data. I'm not sure how that's all that important here. Adobe was not hacked through a CF vulnerability. If you want to find people using CF, you don't need to hack Adobe to get that. There are lots of people who have that data. Admittedly, if you want to find people who bought older versions of CF, that would be easier to get from Adobe, but that wouldn't tell you whether those people are still using CF or whether their servers were set up properly. In addition, that would have nothing to do with what you want Adobe to do now. To the best of my knowledge, Adobe does not possess a time machine, so they can't go back in time to fix problems in old installed systems other than by providing patches. I guess that it's a good thing that administrators don't have to worry about patching anything else. But we developers, we're not worried about this because if our server gets hacked (through widely published methods well known by the hacker community), it's all YOUR fault! I mean, it's not like you've got anything better to do, is it? *sound of running feet and screaming* I'd be interested to hear how security audits work in your organization. On second though, maybe not. If you think vulnerabilities don't exist for other products, through widely published methods well known by the hacker community, I don't know what to tell you. If you install any application that will be exposed to untrusted networks, you are expected to apply basic due diligence. If you cannot do that, you should not be administering that system. And for CF, at least, it's easy to block the widely published methods well known by the hacker community. 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:358237
