Welcome!

Security Authors: Liz McMillan, Elizabeth White, Raja Patel, Yeshim Deniz, John Barco

Related Topics: ColdFusion, Security

ColdFusion: Article

ColdFusion Security Best Practices

Knowing the security risks are there is half the battle

The Internet has become a scary and hostile place; can your Web applications survive?

Although a lot of media attention has recently been paid to information security, surprisingly little has been published regarding ColdFusion security. Does this then mean that ColdFusion applications are immune to security risks? The answer, unfortunately, is no. Attacks may actually be easier to execute and much more prevalent than programmers would like to believe. Knowing the security risks are there is half the battle.

This article is not meant to be a silver bullet or a complete reference, as that could easily fill many volumes. I hope instead to give a thorough overview of ColdFusion security coding practices - thorough enough that you will know what types of things to take into consideration as you write your applications. Making your applications secure is probably a lot easier than you think.

I will cover some of the more common security problems, such as cross-site scripting, SQL injection, and man-in-the-middle attacks, along with some general ColdFusion security considerations. I will also touch on buffer overflow attacks and authentication and login security.

Cross-Site Scripting (XSS)
Perhaps the easiest type of attack to enact (and the easiest to prevent) against a Web application is that of a cross-site scripting (XSS) attack. Saving a form to the local machine the attacker is working from is the first step in this sort of attack. Once the file is there, the attacker then has the ability to change form field values that would not normally be accessible to a user simply filling out a form, such as radio buttons, select boxes, and hidden form fields, to name a few. The first thing an attacker would have to do is to change the post action of the form to include the full URL of your post page.

Preventing this kind of attack is as easy as checking for a referrer - or even just making sure that the post action is coming from your site. One way to accomplish this is to include code such as the following at the top of your posting pages:


 <!--- XSS Protection --->
 <cfif NOT len(cgi.http_referer) 
    OR NOT findnocase(cgi.http_host,cgi.http_referer)>
       <h3>Post action aborted!</h3>
       <br />
       <p>Post from foreign host detected</p>
       <cfabort>
 </cfif>
This code checks first to be sure that there is a referrer with the "NOT len(cgi.http_referer)". The reasoning behind this is that if the first page they are going to is the posting page, then something is obviously wrong. Also, this is a very real indicator that yes, this is an XSS attack. There can, however, be some false positives with this code because of older browser usage, but this is the fault of the browser and not the code. So at this point we know there is a referrer but not whether it is coming from our server, which is why we include the second part of the cfif statement "NOT findnocase(cgi.http_host,cgi.http_referer)". This section of the statement checks to be sure that this is indeed a page on your site going to post on your site. With this we know that it is most likely a legitimate transaction and will allow the user to post the form.

Note: Be aware of the "www." in your domain when using this code. You may want to alter the code to accommodate all of the possible domains for your site. It is also important to note that there is not a 100% guarantee on the referrer, as this information is sent from the client's browser and is therefore "spoofable."

SQL Injection Attacks
An injection attack is the act of embedding partial SQL queries inside of input that is sent to a WHERE clause in one of your existing queries. A classic (and all too common) example of vulnerable code would look like this:


 <!--- SQL INJECTION VULNERABLE CODE -‡
 <cfquery datasource="#myDNS#" name="qryLogin">
 SELECT * FROM Users WHERE username= '#form.username#' AND
  password='#hash(form.password)#'
 </cfquery>
 <cfif qryLogin.recordCount gt 0>
 	<cfset session.authenticated = 1>
 <cfelse>
 	Invalid login!
 </cfif>
 
To exploit this an attacker would simply have to enter " ' or 1=1--" into the username field. That would produce an end query that looks like this:


 SELECT * FROM Users WHERE username='' or 1=1-- AND password=''
 
As you can see, 1=1 will always be true. The "--" in MS SQL Server will comment out the rest of the query. The resulting record count will be however many records are in the Users table, obviously greater then 0. The user would be logged on and happily browsing your application.

There are a number of things developers can do to reduce the risk of SQL injection attacks in their applications. One technique I like to use is to write a UDF (user-defined function) that will escape out all quotes and then use it as a wrapper for all values passed to the query. Following is a simple example of such a UDF:


 /**
  * UDF that replaces strings commonly used in SQL Injections
  * and replaces them with Unicode equivalents.
  * 
  * Written for September 2004 issue of CFDJ magazine
  * Version 1 by Bryan Murphy, [email protected]
  * Written in cfscript
  * @param string 	 Text to parse. (Required)
  * @return Returns a string.
  * @author Bryan Murphy ([email protected])
  * @version 1, July 22 2004
  */
 function sqlSafe(string) {
   var sqlList = "-- ,'";
   var replacementList =
 "#chr(38)##chr(35)##chr(52)##chr(53)##chr(59)##chr(38)##chr(35)##chr(52)
 ##chr(53) ##chr(59)# , #chr(38)##chr(35)##chr(51)##chr(57)##chr(59)#";
 
   return trim(replaceList( string , sqlList , replacementList ));
 }
 
The simplest way to protect your applications from a SQL injection attack would be to store all of your SQL code in stored procedures. Because a stored procedure does not dynamically create a SQL query, it is not susceptible.

ColdFusion also has the CFQUERYPARAM tag. Using this tag properly will also ensure the safe execution of your SQL queries. Be sure to provide the CFSQLType value to ensure that the data being passed is of the expected type for your database.

Man-in-the-Middle Attack (Session Hijacking)
Using this type of attack, the attacker sometimes sniffs the packets of a legitimate user. The attacker will then alter the packets and send them back at the application on the user's behalf.

The best way to eliminate this risk is by "tying" multiple variables from different scopes together. Require a session, database, and cookie variable to be concatenated and match a session-specific variable. An encrypted or hashed UUID works best for this purpose.

Parameter Manipulation
Another very common type of attack used against a Web application is parameter manipulation. Arguably just about any type of attack could be grouped into this category, but for the purpose of this article I will use this term to refer to attacks by users providing unexpected input into fields they are given access to.

These attacks could range from someone entering ".5" for the quantity of a $100 product and being charged only $50 for it, to someone entering a letter into a field that is expecting a number to see if they can receive an error message.

This type of attack simply comes down to not properly checking user-supplied attributes. If you are expecting a whole number, use the ceiling() function to round entries up to the nearest whole number; if you are expecting any sort of numeric value, use the val() function, which automatically strips out nonnumeric characters.

Your post actions should do a host of error handling and input validation before anything is saved to a database or any access is granted. Your error handling should be done server side. Do not rely on JavaScript or other client-side validation, as these are all easily manipulated by the end user. Be aware that CFFORM fields generate JavaScript validation, making it useless against this sort of attack.

Buffer Overflows
Buffer overflows are by far the most prominently publicized vulnerabilities. Although these are extremely prevalent in normal software, they are not a direct concern for ColdFusion developers, as the ColdFusion Server does not allocate memory at runtime or have pointers. This does not mean that the ColdFusion Server itself is not susceptible to such attacks. The recommended course of action is to subscribe to the ColdFusion security mail list (www.macromedia.com/devnet/security/security_zone/ notification_service.html) and patch appropriately as patches are released.

General ColdFusion-Specific Security Considerations
There are some general things that every ColdFusion programmer should take into consideration. CFFILE, CFFTP, and CFPOP present a unique set of insecurities. Each of these tags allows an end user to write a file to your server. It is important to filter MIME types to exactly what you are expecting. Better yet, allow files to be saved only outside of Web-accessible directories.

In the event of an error, never give away any details (DSNs, table names, directory paths, and so forth) in the error message. Attackers will intentionally throw things at your application in an attempt to generate error messages that will aid them in their attacks.

SSL (Secure Sockets Layer) provides a layer of encryption between the client and the server. If your application stores or transfers any data of a sensitive nature (social security numbers, credit card numbers, etc.) you will need to use SSL. If it's a public site, your users will demand it. Even novice Internet users know to look for the little padlock in the corner of their Web browser; if they don't see it, they take their business to another company.

Authentication/Login Mechanisms
The last security issue I will touch on covers authentication systems and login systems. These systems may seem simple to the average developer, but creating a secure login requires a substantial amount of code. I would recommend putting a lot of time and effort into your login/authentication mechanism and placing it in a CFC or custom tag. Then you can reuse it across all of your applications, and if a problem is found it requires that you change code in only one place for all applications. It's a good idea to use and reuse trusted components. However, if you would prefer an off-the-shelf product, you may try MetaGuard (http://guardianlogic.com/?dna=products&rna=metaguard ). We have written all of the laborious stuff for you.

Always hash/encrypt passwords and other sensitive data. If an attacker is somehow able to get direct access to your database, you don't want them to see all of your passwords in plain text.

Require complex passwords. Time and time again, end users have shown that they are completely content using the name of their pet, child, or even their username as a password. This is gold to an attacker, as it requires only a brief amount of research or one or two guesses to break it. I recommend using some sort of UDF to verify the complexity when a user goes to change or create a password. My favorite is passwordCheck(), which can be downloaded from www.cflib.org/udf.cfm?id=1072

Make passwords expire. This rule is sometimes disregarded, but it is still very important. If an attacker managed to gain a copy of your users table six months ago, he or she will still be able to gain access with those passwords today if you don't require expiration.

Log everything (or at least all that is useful). If someone is hammering an account with 100 invalid login attempts per minute and all you know is that your site is running slow, then your application has a way to go before it can be considered secure. Use CFLOG, write the events to a table in a database, or use CFFILE to write a plain text log file. Any or even combinations of these methods will work. Remember, these logs are useful only if someone actually checks them.

Set a maximum invalid login threshold lockout. In other words, if a user has X invalid login attempts, he or she will be locked out for Y minutes. Some applications require that an administrator unlock an account after a lockout occurs. In my opinion this is not the best method, as it could be used to create a DOS (denial of service) event. It is common for attackers to gather all of the logins they can for a site and run a brute-force or dictionary attack against each one. This will essentially lock out every user on your system (that they have usernames for). This is a nightmare to deal with.

Allow only one connection per user at a time. If someone attempts to log on as a user who is already logged on from a different IP, it should be logged as a security event. The user is either sharing passwords, or his or her password has been compromised.

Write IP-based auto-blacklisting for repeat offenders. This may even be the route you want to go for the invalid login lockout. This way the account itself remains usable by legitimate users, but the attacker's IP is locked out. Of course this does allow the attacker to make an attempt from another IP or to spoof the IP and try again.

As you can see, many security concerns must be taken into account when writing a Web application. It may seem like a lot of extra effort - until you experience your first XSS attack and the attacker makes off with your product for pennies or uses a SQL injection attack to steal your customer database, credit card numbers included.

Security considerations should be included in everything you do. They should be embedded into your thinking and not added as an afterthought.

Resources

  • OWASP: www.owasp.org
  • Search Security: http://searchsecurity.techtarget.com
  • Macromedia CF security: www.macromedia.com/devnet/mx/coldfusion/security.html
  • CF server security announcement list: www.macromedia.com/devnet/security/security_zone/ notification_service.html
  • WASC: http://webappsec.org
  • More Stories By Bryan Murphy

    Bryan Murphy is the owner of GuardianLogic, Inc. (www.guardianlogic.com), an information security firm that provides application and network vulnerability assessments and hardening. He is also one of the authors of Metazoa (www.metazoa.ca), a security-enhanced content management system; Membrane, an application-level firewall; and MetaGuard, a CFC that provides role-based login, authentication, and access control. Bryan has been an ethical hacker since the old-school BBS days. Visit his blog at www.downgrade.org.

    Comments (3) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    Ron K 06/22/07 11:10:54 PM EDT

    Great article. Gave me some good pointers on security issues.

    Michael Johnson 01/18/06 02:35:22 AM EST

    This is a really poor atricle.. your suggesting preventing cross site scripting by checking the referer, wow! Most input fields you can directly inject the code, if that gets stored into a database and re-displayed back to the user I can get whatever information I want.. Also with a combination of http response splitting you can overwrite the header information easily. This article should really be removed or updated correctly.

    somus 04/02/05 12:51:39 PM EST

    I wonder if your paranoia stems from having your hand in the security field? does the fact that you are making money from spreading fear and suspicion keep you up at night?

    I hope you choke on your fat wallet