ColdFusion Security: a Clango Whitepaper

pdfDownload the PDF

1         ColdFusion Platform Security Notes

Recent attacks on government sites at the Office of Personnel Management (OPM) and other departments have raised some questions about the security of the Adobe ColdFusion platform for web application development.  However, ColdFusion has an excellent security track record by comparison to other web development languages and frameworks, reporting just 5 vulnerabilities of medium severity or lower in the past 2 years[1].  ColdFusion is just as easily secured and configured as other major platforms, and includes a host of built-in security options.  This white paper is a brief attempt to outline the issues surrounding ColdFusion web application security and give business owners some key information for developing a strategy to mitigate risks.

1.1        Components of the ColdFusion Platform

ColdFusion is a blanket term referring to a web development and deployment platform that includes several components: The first step in assessing a ColdFusion web application’s level of risk is to correctly identify which components are in use on your site:
  1. CFML Engine vendor (Adobe, Railo, Lucee, OpenBD)
  2. Servlet container/Java application server (Tomcat, Glassfish, JBoss, Websphere, etc.)
  3. Web server (Apache, IIS, etc.)
  4. Java version in use (e.g., SDK/JRE 8 or 7)
  5. Frameworks or third-party components in use (e.g., FW/1, FuseBox, Mach II, ModelGlue, CFWheels, ColdBox)

1.2        Patching, Updating, and Minimizing Surface Area

The majority of successful attacks against IT systems leverage exploits that already have fixes available, or succeed because systems were not properly configured[3].  System owners either did not understand how to properly install and configure the system for production use, or failed to keep up to date with the latest versions of software, frameworks, and vendor-supplied hotfixes.     To minimize the risk in running ColdFusion sites in particular, the following steps should be considered for any production site:
  1. Install ColdFusion using the Secure Profile option for Adobe ColdFusion.
  2. Apply settings in the latest ColdFusion Lockdown Guide[4].
  3. Set and maintain a server patch schedule for your system, at least monthly.
  4. Set and maintain a software patch schedule for your ColdFusion system by checking in the ColdFusion administrator (Adobe ColdFusion) or regularly checking the vendor of your CFML engine (Railo, Lucee, OpenBD).
  5. If you use a web server that is not patched as part of your system patches, set and maintain a separate patch schedule for your web server (e.g., Apache on Windows will not be patched as part of the usual Microsoft patches).
  6. Remove, disable, or uninstall services and add on components that are not currently in use. These components can be re-added later as they are needed by re-running the installer, changing configuration files, or downloading and installing.
  7. Set and maintain a patch schedule for any third-party add-on components that are not automatically updated as part of the above updates. This includes patches and updates to your frameworks, open source projects, JRE, database software, etc.

1.3        Securing Code and Maintaining Security

Web application code may itself contain security flaws that permit privilege escalation, information leakage, SQL injection, and even arbitrary code execution.  To protect against these risks, consider a software audit process that could be repeated – This process should include reviewing and refactoring code to use best practices and frameworks with good testing and security histories.
  1. Use automated code scanners with plug-ins or signatures for the platform in question. Nessus by Tenable is a free, open source scanner that has ColdFusion signatures available.
  2. Use built-in technologies like ORM or Stored Procedure support to minimize the risk of SQL Injection attacks.
  3. Implement sitewide error handlers and missing template handlers to minimize information disclosure.
  4. Delete deprecated or unused code.
  5. Consider encrypting ColdFusion source code, pre-compiling templates, or deploying ColdFusion sites as a WAR/EAR file directly to a Java application server.
  6. Use a source control system to maintain tagged versions of web site software for quick code comparison and restore.
  7. Use Intrusion Prevention and Detection software or appliances to look for suspicious traffic patterns indicating possible probing or attacks against your site.
  8. Do not store or transmit passwords, PII, PCI, ePHI, and other sensitive data unless absolutely necessary. When this is unavoidable, use at-rest encryption and in-transit encryption to maximize privacy and confidentiality.
  9. Integrate web site security with common controls available at your site[5].
  10. Implement continuous monitoring solutions such as log event analyzers, application firewalls, application performance monitors, site availability measures, file system intrusion detection, and server health alerts.
  11. Use check lists such as OWASP Top 10[6] and SANS Top 25[7] when reviewing code, architectural decisions, and data handling.
  12. Subscribe to mailing lists and data feeds for vulnerabilities, data breaches, and your products. Typical general feeds include the Common Weakness Enumeration (CWE)[8] and Symantec Security Response[9]. Vendor specific databases include the Adobe Security Bulletins and Advisories[10] and related blogs and Twitter feeds from ColdFusion evangelists.  Also consider watching the Oracle Critical Patch site[11] and subscribing to their feed for breaking news on Java JRE patches.

1.4        Continuous Security

Securing ColdFusion web sites involves no more configuration or special considerations than any other scripting language or platform, and CFML engines contain special settings to help protect against common attack vectors such as CSRF tokens, XSS scripting defense, secure profiles, pre-compiling, information hiding, and more.  Relative security is difficult to measure, but ColdFusion has an excellent security record in the past three years (26 recorded vulnerabilities as compared to 2,592 in PHP generally, 482 in Drupal specifically, and 112 in Ruby)[12].  The security measures it requires are not different or more costly than those of other languages and platforms. As with any Internet facing software, due diligence and due care are the most successful strategies against exploitation. Securing the ColdFusion Platform and its components should be considered part of an over arching and ongoing security strategy. There are several best-practice approaches available, including those published by NIST for securing public web servers[13]. Since the ColdFusion Platform is usually integrated with several other connected systems, it is essential to broaden the scope of security to the full system boundary. The following diagram describes a high-level continuum of activities at various stages of the system lifecycle. Continuous Security Work Flow

1.5        ColdFusion and OPM

A full accounting has not yet been, and may never be, publicized on the attack vectors of the OPM hack nor ColdFusion’s role in the breach.  However, published reports from the IG and other experts indicate a problem with the overall topology of the IT environment and the rigor of continuous administration and monitoring rather than any specific platform exploit. Multiple reports indicate the version of ColdFusion powering the Electronic Questionnaires for Investigations Processing (e-QIP) system (one of the modules of the EPIC tool set) was running JRun 4.0, Adobe’s Java application server.  While it is unclear exactly which version of ColdFusion application server e-QIP was using, Adobe has not shipped ColdFusion with JRun since version 9.   As noted above, since version 10 released in May 15, 2012, Adobe has utilized Apache Tomcat as its Java Application Server. Additionally, transitions to and from the e-QIP server were still using TLS 1.0 cryptographic protocols.  TLS 1.0 was first introduced in 1999 and while still surprisingly common on the internet has been recommended for deprecation by the Internet Engineering Task Force (IETF) since the development of TLS 1.1, 2006, and TLS 1.2, 2008. Finally, the topology of the datacenter utilized a shared firewall.  This oversight allowed for a compromised webserver to provide access to the OPM databases and services connected to it.

2         About Clango

Founded in 1993, Clango provides IT professional services to help organizations adopt, develop, and maintain enterprise-class technology solutions. Clango has provided these services to a diverse client base including multiple engagements with the Department of Defense, the Department of Interior and other federal agencies.  Our application development Practice Area and Cyber Security Practice Area work hand in hand to ensure that that we provide solutions that meet specifications, and are maintainable, extensible, robust, and secure.  Relevant to this white paper Clango has partnerships with and Clango employees have certifications from Adobe, RSA, CyberArk, ForgeRock, Oracle, Microsoft, and IBM.  Clango applications Developers have written millions of lines of code in ColdFusion and alternative web development platforms including Java and .Net.

3         About the Authors

Edward Trudeau is Clango’s Director of Software Development and has 17 years of experience leading software development, quality assurance, and security in the Public and Private Sectors, as well as Higher Education.  Edward holds certifications from ITIL and Scrum Alliance and has been a ColdFusion Certified Developer and / or Trainer from Allaire and Macromedia.


Arun Kothanath is Clango’s Chief Security Strategist and has more than 20 years of experience in information security architecture, Identity Management, and fraud management systems. Mr. Kothanath has a CISSP with a strong background in integrating complex systems, product development, and architecture.  Over his career Mr. Kothanath has held positons as CSO and CISO and still holds an honorary status of Oracle Deputy CTO.


Patrick McGeehan is Clango’s Vice President of Service Delivery and oversees all 3 Clango Practice Areas.  Patrick is a former Advanced Certified ColdFusion Developer and has over 16 years of progressive development, IT architecture, and management experience in Federal Contracting, Health Care, and Higher Education.  Over the last 12 with Clango, Patrick has been involved with dozens of large scale web applications projects including ColdFusion applications containing sensitive information.