design over matter

You can find part one of securing your ColdFusion applications here. Part two will focus on securely storing your data.

Step 5 - Use Secure Socket Layer

Use the SSL and https when passing sensitive data to and from your server. This is a no-brainer, but I mention it since passing data insecurely will defeat the purpose storing data securely.

Step 6 - Encrypt your passwords

ColdFusion provides one-way encryption using the hash() function. You won't be able to decrypt the passwords but neither can any hackers. When a user submits their password you'll use the hash function then compare the password with the hashed password value in your database. ColdFusion 7 improved the hash function by adding multiple levels of encryption. Pete Freitag has a nice write up on it at http://www.petefreitag.com/item/270.cfm.

Step 7 - Help users reset forgotten password

In the past developers have used the "forgot password" feature to email users their password or ask them a "secret question/answer". Both methods are a security risk. If you email their existing password, and someone gains access to that email other accounts that use the same password would be compromised. The secret question/answer method may ask the user "the street they grew up on, or high school mascot". This method of password retrieval has gotten more insecure as we share more personal information through social networks. The method I chose is to set a temporary password or reset key in the database and email that to the user. I also insert the date/time of the request so the temporary password/reset key will expire after a period of time (4 to 24 hours).

Step 8 - Encrypt and Decrypt sensitive specifically credit card numbers.

Now, let me start off by saying storing credit card data is risky business. So, unless you really need to store it, you shouldn't. A situation where you might want to store credit card data would be a subscription service. With ColdFusion you can use the encrypt() and decrypt() functions. There are different encryption methods.

 

 

Of course, you could store the secret key in a location other than the application.cfc. This is just an example of how to generate and save the secret key.

Step 9 - Don't use the SA account in the CF administrator

When you create your database, also create a new login user and grant this new user access to your database. But limit access to only database functions you want your application to use. For example insert, update, delete records, but leave out add and dropping tables.

Step 10 - Use Captcha

Add a captcha image on pages that are potential hacking targets. For example you could add captcha to your login page.

 

Well that does it. Happy Coding.

 

Recently, I received a phone call from a former client about an application I worked on in 2001.  The e-commerce site was written during the ColdFusion 5 days and has been running ever since.  Unfortunately, he was calling to say they'd been hacked.  Below are the steps I took to secure the application against sql injection, cross-site scripting attacks and general probing by hackers.

Step 1 - Upgrade to ColdFusion 7 or higher

Running ColdFusion applications on pre-ColdFusion MX (6.1) servers poses some security risks.  Upgrade to ColdFusion 7 or 8 to take advantage of the security measures in this post.  One caveat before you upgrade.  Test out your application on the new version of ColdFusion before deploying it to your production server.  I can't stress this enough.  You don't want your customers seeing errors because you haven't tested out your old code on the new version of ColdFusion. 

 

One error I found with my client was the use of dot notation when naming application variables.  For example, we set common email addresses in the Application.cfm file and used names like application.email.service = "jim@acme.com".  This works fine under ColdFusion 5, but throws a java.exception in ColdFusion MX and higher.  Why is this? Newer versions of ColdFusion added dot notation for simple assignment of structure values "object.property" is a value for the structure called "object". Read more about Structures.

Step 2 – Move from Application.cfm to Application.cfc

Ben Nadel does a great job breaking down the features of Application.cfc in this post.

 

Hackers want information about your application, code, database, etc.  "Oh, the better to hack you with my pretty." (said in your best evil witch voice).

 

Use the OnError() function of Application.cfc to do a few things.  See the code below

The less hackers know about your application the better.

Step 3 – Secure any variables passed via Forms or URLs.

Variables passed via URLs are especially vunerable to hackers.  Two ways you can secure them.  First use <cfparam>  and set the type for any numeric values. 

 

For example, foo.cfm?id=1 can easily be modified to foo.cfm?id=1 and 1 = convert(int,(select top table_name from information_schema.tables)). 

 

Add cfparam at the top of your page to prevent non-numeric values.

You should also secure all values passed into the cfquery tag.  ColdFuion MX and higher support the <cfqueryparam> tag.  Use it at all times. 

 

Here is the non-secure query

 

Here is the secure query

STEP 4 – Protect against malicious html code (cross-site scripting attacks).

Hackers will try to insert html code to attack you and/or your users.  They will use the <script>, <object>, <embed> and other tags to run malicious code through your site.

 

ColdFusion 7 Administrator has a setting you can turn on to protect against such an attack.  Login to the ColdFusion Administrator,  and click on Settings.  Near the bottom is a check box for Specify whether to protect Form, URL, CGI, and Cookie scope variables from cross-site scripting attacks.  Check that box!

 

If you want extra protection or can't access the ColdFusion Administrator, there is a great custom tag called CodeCleaner.  Download CodeCleaner here and place it with your other customtags.  Then add this code at the top of your page.

This will remove any "bad" html a hacker may try to insert into pages or a database.

 

That's it for Part 1 of securing your ColdFusion Applications.

 

If you have suggestions for Part 2, please let me know and Happy Coding.

 

What happens if you forget your ColdFusion Administrator password or for some reason your CF Admin password won't work?  This actually happened the other day.  After moving all my data from my iMac onto an Intel MacBook Pro running Leopard, I found ColdFusion 8 was not starting up.  Decided to uninstall and reinstall ColdFusion hoping this would solve my problems. 

After a couple failed attempts, the install worked and I saw the beautiful Cold Fusion Administrator Setup/Migration screen.  For those not familiar, this is not the regular login screen, but the final step of the install process.  At this point, you enter the ColdFusion administrator password you just created during the installation.  Well, my password would not work.  CF kept returning "Invalid password". 

Hmmmm, I'm "this" close to finishing the install and my password won't work.  Is this some cosmic joke?

Well, I did some poking around my hard drive and discovered a solution.

1. Shut down ColdFusion 8.  On the mac I launch the Terminal located in the Utilities folder.
   • Enter  sudo /Applications/JRun4/bin/jrun ‚Äìstop cfusion
2. Use Spotlight to search for the file "neo-security.xml"
   • On my Mac ...
     /Applications/JRun4/servers/cfusion/cfusion-ear/
     cfusion-war/WEB-INF/cfusion/lib/neo-security.xml
3. Select the file and do Command – I to bring up the Info panel
4. You'll need to make sure you have Read-Write permissions.
    
   
    
   
5. Open neo-security.xml in any Text Editor
6. Look for the line
   • <var name='admin.security.enabled'>
                <boolean value='true'/>
     </var>
7. Change the value to false
8. Restart ColdFusion 8
9. Browse to the http://127.0.0.1/CFIDE/administrator/
10. Click on "security" on the left side.
11. Make sure you turn the Administrator Authentication back on and enter a new password.
     
    
     
    

Happy coding...