Ten tips for securing your ColdFusion application

Over the past year, reports of website security vulnerabilities have increased—in number and severity. Security is a top issue in application development and production. There are a variety of responses to hackers.

ColdFusion application developers—like all applications developers—can take steps to prevent security violations. When you install the Macromedia ColdFusion  server on your local machine, it’s easy to start developing applications right out-of-the-box. Your focus during development is on the inner workings of the application and not on setting up and configuring the ColdFusion administrator. When you deploy your ColdFusion application to production, however, you expose your application to the whole world. In this environment, things are different.

Below you’ll find ten tips for setting up your ColdFusion  application server with security in mind. This list is divided into these general sections:

  1  Features and setting to turn off

  2   Features and settings to turn on

  3  On-going chores

  4  Testing techniques: A hidden JavaScript example

1 Features and settings to turn off :

    1.1 ColdFusion  installation :

Install ColdFusion on the production server without the documentation and example applications. You can uncheck the Example Applications option during your ColdFusion server installation. While the example applications are helpful to new ColdFusion developers, the CFML source code for these examples is freely available, so they present a tempting target for hackers in a production environment. The example applications were revised in ColdFusion 5 to make them more secure, but still there is rarely a good reason to have them on a production server.

    1.2Disable RDS (Remote Development Services) on your ColdFusion MX production system :

The easiest way to disable RDS is to set the RDS password on your production system to a password that is not easily guessed. Choose passwords that not are susceptible to “dictionary” (words that can be found in a dictionary) attacks. If you can’t come up with a unique and hard-to-guess password, a quick web search for the phrase “random password generator” will turn up a plethora of password-picking aids. As a rule of thumb, mix letters, numbers, and symbols in your passwords.

1.3   Turn off ColdFusion MX server debugging :

In the ColdFusion MX administrator, you can enter a list of IP addresses for which the ColdFusion server will display debugging information. This means that when a machine with a specified IP address browses a CFML page, debugging information will display for that particular user. Note that if you have no IP addresses specified and debugging is enabled in the ColdFusion Administrator, then debugging information can appear for any user of the application.

Entering a single IP address of 127.0.0.1 is a good choice for a production system. Even if a clever hacker spoofs this IP address by creating IP packets with 127.0.0.1 as the source IP address, these packets will never be passed along through the public Internet. Some other non-routing IP addresses are 10.*.*.*, 192.168.*.*, and the range 172.16.*.* through 172.31.*.*. If your internal network uses these addresses, it is quite safe for you to put the IP address of a few of your local machines into the list.

Features and settings to turn on :

  1 .Specify a site-wide error handler on a production system :

You can specify a page that will be your site-wide error handler on the Settings page in the ColdFusion administrator. Note that for ColdFusion, you should enter the relative path (such as /swerror.cfm), rather than an absolute path to the file. The page you specify does not need to be elaborate. A simple message to your user that something has gone awry will usually suffice. Since the error page is a ColdFusion page, you can build in logic that will send you information about the error that the user has encountered.

For instance, you could have information about the failure e-mailed to the ColdFusion  administrator and at the same time display a generic message to the user (or your attackers) that contains no information about the page being executed. You can use the cflog tag, introduced with ColdFusion 5, to write the error to your ColdFusion logs. Your site-wide error should not try to perform too many actions—it would be poor design if a site-wide error ColdFusion page itself causes an error! Instead, use the cftry and cfcatch tags in your error handler.

2 .Specify a site-wide missing template handler :

Often you can specify the same page as your site-wide error handler. Neither legitimate users nor nefarious hackers need to know much about missing pages (at least, no more than what you would show them in your site-wide error handler). Using the same page helps to deter and frustrate hackers who are probing your website for similarly-named pages. You can collect a lot of information about a potential attack if you use the cflog tag. Using the same template for both the site-wide error handler and for the site-wide missing template handler will keep the hacker in the dark—he won’t know if probes were wrong or if he just failed to include some required data for a ColdFusion page.

   3. Protect the ColdFusion  administrator password :

Protect the ColdFusion administrator password in the same way that you protect the RDS password. All web servers have some mechanism to restrict directory trees to authorized users. You may want to use this mechanism for the ColdFusion administrator directory, too. Remember that there are files in the /CFIDE directory tree that ordinary users need to access. It’s preferable to restrict access to the /CFIDE/Administrator directory tree and not to the entire /CFIDE tree.

2 On-going chores :

    1 .Read your ColdFusion and web server logs :

Very few developers literally read the ColdFusion and web server logs, but it’s important that you peruse them occasionally. Scripts that exploit known vulnerabilities are easy to spot in web server logs. As you look over your logs, keep an eye out for a single IP address that has made hundreds of HEAD requests or for requests to unlikely file names such as “../.” (Not long ago it was discovered that coldfusion had a Directory traversal attack which would allow hackers to read server configuration.

    2 .Read security bulletins :

Read the security bulletins for all of the products you use on your website. Most software companies have a security area. At Macromedia, it’s http://www.adobe.com/devnet/security.html ; at Microsoft, www.microsoft.com/security; at Sun, www.sun.com/security; and so forth. The amount of time from discovery of a new security vulnerability to the widespread use of malicious scripts that probe websites for the vulnerability is getting shorter. The situation can easily become a race between malicious scriptwriters and website administrators. Since you probably want to win this race, it’s best to sign up for automatic e-mail notifications of security bulletins. On Macromedia’s Security Zone, sign up for the Security Zone Notification Service. Usually, web server vendors have a similar service you can subscribe to.

   3 .Have a recovery plan in place

   If you do get hacked, have a recovery plan ready to go. Hopefully you’ll never need it, but it’s difficult to focus on fixing a website after a security attack if you don’t already have a plan. If you do get attacked, there are two broad categories of tasks to perform:

•         Preserve the evidence—namely, your web server logs and your ColdFusion logs. This will help you figure out how the hacker manipulated your website. While it’s useful to be able to update your website with a backed-up version, you’ll want to compare the hacked version of your application to an unmodified version of files so that you can determine what has been altered. A backup of your database, if possible, also can be useful forensic evidence.For more help contact us

•         Restore your website. At minimum, you’ll want to restore your application and database to the unaltered state. If you cannot quickly determine how the attack was launched and what it affected, you may also want to also re-install all your software, including your operating system, web server, and ColdFusion MX server.

•         If you have the ColdFusion Enterprise edition, you can use the Archive/Deploy utility to swiftly and easily reconfigure ColdFusion (assuming that you created a fresh archive after your most recent change). If not, a backup of your application and records of how your data sources and other ColdFusion settings will do. You’ll also want to have on hand similar records of both your web server configuration settings and your database settings if you have to re-install all your software on short notice.

4 .Testing techniques: A hidden JavaScript example :

There are myriad development-phase techniques for creating hacker-proof websites. In fact, there are whole books devoted to this subject and it’s a little beyond the scope of this “top ten” list of production-phase security tips. Nonetheless, you should keep in mind that preventing security breaches is important during development, too. Even after moving your application into production, you should do some testing to see what’s vulnerable. Here’s an example of a technique known as “cross-site scripting.”

This common website attack is a ploy to get around the rules for JavaScript. All modern browsers honor this rule: JavaScript can only access cookies for the website from whence it came. The trick is for a malicious site to direct one of your unsuspecting users to your own site via a HTML link. This link not only contains the URL for your site, but it also contains some sneaky JavaScript embedded in a text field. If your application sends this text back to the unsuspecting user, it will not appear on his screen. Instead, it will execute as if it came from your site, which—technically—it did!

For example, the evil site may have a link to your login page that has this code:

<a href=”http://www.yoursite.com/login.cfm?username=reda ammara<script>{malicious_code}</script>&password=yyy>

When an unsuspecting user clicks on this link, the response will undoubtedly be your application’s password failure response (unless you really do have a user named “Ammara reda” and his password is “yyy”). While your puzzled user ponders why she has received a password failure and why you are calling her “Ammara reda,” the {malicious_code} part of the script is executing in her browser. The script could be collecting all the cookies it can access and forwarding them to a program at the hacker’s website. It is the user’s cookies from your website which are being harvested, since the JavaScript originated from your site as far as her browser can tell.

The solution is to disinfect any user input text before you send it back to a user’s browser. You can use the ColdFusion functions HTMLEdit() and XMLEdit(). Either tag will render any embedded JavaScript harmless. They do this by turning the <script> tag into &lt;script&gt;. XMLFormat() also changes the apostrophe character to &apos; and handles < and > by turning them into their ASCII equivalents. Either function will disarm a malicious script and cause it to display harmlessly in the user’s browser rather than execute.

5 .Testing your application:

You can easily test your application for susceptibility to this attack. Just copy the following not-very-malicious script and try pasting it into various text input boxes in your application. If you only see the script on your screen, no problem—but if the alert box pops up in your browser, your application may have an opening for Cross-Site Scripting attacks.

<script>alert(“Ooops!”)</script>

You might be surprised how often the alert box pops up on your screen.

Conclusion

This article covered some very basic security steps for ColdFusion  production and reviewed one example of a development-phase technique for preventing a security breach. This barely scratches the surface of what can be done to keep hackers at bay. This list may help you with your initial deployment and remind you to keep security ever near the top of your application-development priority list.

For Coldfusion security pesntest and review contact us at SYSMOX