Safe Scripting | ColdFusion Developer's Journal

Safe Scripting | ColdFusion Developer's Journal:

Already Deployed Sites
Identifying and modifying every input variable in a deployed site could prove difficult and costly. Fortunately for users of ColdFusion 4.5, Allaire has a custom tag available on its Web site. The cf_inputfilter tag allows you to filter all special characters from input. The tag has three parameters: scopes, chars and tags. The scopes parameter is a required comma-delimited list that allows you to choose the variables you want to strip of special characters. The choices for the scopes parameter are form, cookie, URL or any combination of the three. The chars parameter is an optional string of the characters you want to filter from input. The tags parameter, also optional, is a comma-delimited list that allows you to specify the tags you want to filter. For example,

filters the characters "%" and "&" and the "script" and "object" tags from all form variables. The cf_inputfilter tag is available free of charge from Allaire's Web site.

If you have an older version of CF, an easy technique for protecting your site is simply throwing an error if a special character is found. I've written the custom tag cf_filter to check for special characters (see Listing 5).

Although not elegant, cf_filter works in ColdFusion 4.01. The cf_filter tag searches for the characters: % < > [ ] { } in form fields, cookies, URL parameters, session variables and client variables. If a special character is found, an error is thrown. You can exclude checking any of these variables by setting any of the optional parameters, checkfield, checkurl, checkcookie or checkclient, to "no." For example, would check the session variables, cookies and URL parameters, but not the form fields or the client variables. Note that cf_filter does not include all special characters. As discussed before, overzealous filtering can result in valid characters throwing an error. If you want to filter more characters, you can easily modify this code to search for the script or object keywords or filter other characters; however, filtering %, < and > should be sufficient for capturing malicious tags and script.

ColdFusion Server Issues
So you've done everything you can to prevent cross-site scripting from using your code. What about Allaire's code? You must be diligent and filter all input and output, even Allaire's. As Allaire warns, none of the wizard-generated code in ColdFusion Studio protects against cross-site scripting. Downloaded and wizard-generated code should be carefully examined.

Wherever the ColdFusion Server echoes parameters to the client, there's room for exploitation by cross-site script. Two areas that immediately come to mind are the default error message and debug information. The ColdFusion Server default error message fails to filter or encode output. Consider the code:

SELECT #test# FROM Documentation

When the URL http://localhost/test/query_test.cfm?test=  is entered as a test's value, ColdFusion attempts to resolve the test and throws an ODBC error. When the error message is written to the user's browser, instead of echoing the value of the test the script is executed (see Figure 5).

The debug information (remember Vlad's observation of mode=debug) also fails to filter or encode parameters echoed back to the browser - and debug echoes them all back.

You should plug both of these security holes. Changing the ColdFusion Server debug settings to allow only specified IP addresses prevents the URL parameter mode=debug from working. You could also include the CF tag:

on every page for the same effect. The bogus URL parameter is now harmless.

I haven't found any way of making the default error message resistant to cross-site scripting. Encoding variables in a ColdFusion page doesn't prevent the default error message from being used in a cross-site scripting attack. Writing:

SELECT #htmlEditFormat(test)# FROM Documentation

has no effect. This is because at the bottom of the default error message URL parameters are echoed back to the client. The only solution I've found is defining my own custom error.

Conclusion
Fred Cohen, a noted security expert, advises that when considering security testing you "start at the inputs and trace them to everything they can do, either directly or indirectly through their effects on memory and other state information and outputs." Every source of input and output is a potential security risk. Identifying and mitigating at least the most serious of those risks is extremely important. As soon as Microsoft had triumphantly announced plugging the Hotmail security hole exposed by Because-We-Can, another benevolent hacker, Georgi Guninski, successfully demonstrated yet another way to steal usernames and passwords from Hotmail. This time JavaScript was sneaked in between the style tags of a document. As the Hotmail attacks illustrate, there are countless sources of input to your site and many of them aren't readily apparent. For the protection of your clients, you must be diligent and try to consider them all.

Every language used for processing dynamic Web input is susceptible to cross-site scripting attacks. For more information on preventing cross-site scripting, visit CERT's Web site (www.cert.org). CERT's bulletin contains numerous links to vendor-specific information, including Microsoft's IIS, Sun's Java WebServer and Apache. For more information on preventing cross-site scripting in CF, JRun and Allaire Spectra, visithttp://forums.allaire.com and navigate to the security section.

Summary
The simple steps listed in this article will protect your ColdFusion Web site and your Web site's clients from attack. Maybe your site will never be subjected to a cross-site scripting attack...but then again, it might. Launching a cross-site scripting attack is easy. Preventing one is just as easy.