ColdFusion and Security: Part 1 – Intro

This is the first in a series of articles I plan to write on the subject of ColdFusion and Security. The series will cover topics including server configuration, application security and encryption. Part 1, this article, will introduce the subject and reflect on why I’m interested in the topic, as well as why security in a ColdFusion-based environment is an important issue.

Having worked both as a developer and as an IT security advisor, application and server security is one of my pet subjects. Back in the day, most of the ColdFusion developers I knew had little or no idea about securing their applications, let alone the ColdFusion server software or web server software they were using. Most of the time, these developers were also responsible for securing the production servers their applications were deployed on, as the security folks they dealt with knew next to nothing about ColdFusion. Does this sound familiar?

In recent times, the teams I’ve worked with have been much more aware of these issues. However it’s still not uncommon to find development teams who completely fail to take security into consideration when building applications. To be brutally honest, this is scary!

How familiar is this scenario? Oblivious to the pain they are setting themselves up for, the ColdFusion developers merrily go on their way, coding up a storm and producing a whizzbang application that performs whatever they have been assigned to produce – more often than not in a really useful and innovative way. At the same time, over in the hardware and infrastructure team, there is a nicely hardened Windows or *nix box with a hardened web server ready for deployment into production as the home for the new ColdFusion application.
Everything works nicely in dev and test for both teams, and then the app gets rolled to the production server for final QA and the sadness often begins. Almost inevitably, there are problems. Depending on a number of factors including political or business priority, the “cowboyness” of the people responsible for production deployment and the degree of anal rententiveness of the people running the ColdFusion dev and hardware teams, one of three things usually happens. Either:

  • the ColdFusion app is deployed insecurely but works. The application owner is happy, they have what they want, but there’s a truck-sized security hole on the server, causing the server build or network security crew to have fits;
  • the hardened server is hardened in such a way that the ColdFusion app refuses to work and the deployment fails, causing the app dev team to cry foul, or;
  • the app gets sent back to be fixed and secured and the server and dev teams start talking to each other about what they need in their ideal world.

The third situation is the one where I found myself a few years back, and it was the start of my interest in developing secure ColdFusion apps and gaining an understanding of the needs and processes of server and network security. Now, I’m no guru, but I can hold my own.
Based on my experiences since then, there are a few things both application development (whether ColdFusion, or any other platform) and server infrastructure teams need to do. In no particular order (they are all critical), they are:

  • talk to each other to get at least a high-level understanding of the environment. There’s no excuse for hearing something like, “Oh, I’m just a developer. I don’t need to know about the deployment environment.” That’s demonstrably crap;
  • spend some time learning about the part of the technology you don’t understand. Just a few hours reading about Apache or IIS if you’re a coder, or about ColdFusion if you’re a hardware guy will at least put you in the other guy’s shoes to a useful extent;
  • follow accepted standards and best practices for the technology you work with. Failing to keep up with this stuff is a sackable offence as far as I’m concerned. At least if your part of the work follows the rules, if you’re causing the other guy pain, you can justify it and demonstrate you’re not a loose cannon or unhelpful blocker in the process;
  • develop on a mirror of the production environment or build the production environment with the deployment platform in place (ColdFusion, .NET, PHP, whatever) as a core part of the build. That way, any high level issues are likely to show up early, and;
  • keep talking to each other during the entire project lifecycle. If you stay in close contact, any emerging issues make themselves known earlier rather than at some mission critical late stage.

Frankly, I see all of this as a matter of commonsense (an uncommon commodity). But a lot of people I know, even today, just don’t work like this. These factors are equally applicable to development of any sort, let alone ColdFusion. You should use them, as they are tried and proven to make your project run a good deal more smoothly and to ensure the security of your application and environment is as good as it can be.

In the next article in this series, I’ll be doing a roundup of good online resources for ColdFusion application and server security.

Leave a Reply