As an administrator, or a developer interested in how your server is run, are you getting the most out of your CF Server configuration, especially with regard to security-related settings in the Administrator? Are you fully aware of the opportunities and challenges presented by those settings?

In this second article of a series (Part 1 appeared in the January CFDJ, Vol. 4, issue 1), we continue the discussion of some perhaps less obvious aspects of managing CF Server. Part 1 focused on developer- and performance-oriented settings and tasks; here we'll look at security-related settings and tasks. The original plan was to cover some miscellaneous features as well, but it turns out there's more to both topics than the original two-part format could hold. One more part is planned.

As I said in Part 1, there's no way to cover everything in a single article (or even three). If you take the time to read the available documentation outlined in Part 1, you'll benefit tremendously. And the available online help in CF5's Administrator is another great improvement.

Still, for those who don't do the reading or may have a hard time determining what to pay attention to, I'll highlight a couple of aspects that you might otherwise miss or find confusing. There's more to CF's security features than you might be aware of. Although each discussion is brief, I hope to motivate you to look into these topics on your own.

Basic and Advanced: Insider Tips
CF offers two forms of security out of the box: basic and advanced. If you fire up the CF Administrator (as discussed in Part 1), you'll find them under Security at the top left of the Administrator, as seen in Figure 1.

Note that if "Advanced Security" hasn't been installed (it's optional), it won't show up in that navigational toolbar. Prior to release 5, the Basic Security option showed up left of the main Administrator toolbar under the Server heading (again, Advanced Security shows up under Basic if installed).

The simple designation of "basic" and "advanced" security really doesn't do justice to the differences between the two. There are three forms of control that these two approaches share: access to the Administrator, access to tags within the CF environment, and access to resources by way of ColdFusion Studio's RDS feature (supporting remote developers connecting to the server over the Internet).

There are other aspects of security that the Basic approach doesn't provide, and many developers don't realize that ColdFusion can help them with Advanced Security's built-in functionality. First, there's the simple matter of enabling security within your application, providing a login process to control which users are allowed access to the application and/or specific pages within the app. This is referred to as authentication.

Most people "roll their own" form of it, looking up users in a database and using session variables to track a user's logged-in state. This works, but Advanced Security provides a mechanism to handle these tasks in a more standard way. It allows for authentication against not only a database but also, optionally, an LDAP server or a Windows NT domain.

Identifying who may access your site is just one part of the application security equation: once users are logged in, you may want to limit what they're allowed to do. This is referred to as authorization. Not only can Advanced Security provide for multiple levels of security, with roles and varying rules per individual (or group), but it can even limit access to what specific CF tags, functions, data sources, collections, files, and other resources a user may access. We'll come back to these aspects of application security later.

This article can't discuss all these security matters in depth, but I do want to put some things in context.

CF's Basic Security Option
Using "basic" security, which is implemented by default, the only things that CF secures are:

• Who can access the CF Administrator itself (by way of a password defined at installation or changed within the Administrator)
• Who can access the CF Server resources (files and data sources) by way of Studio's RDS feature (also controlled by a single, but optionally different, password that is set at installation and can be changed in the Administrator)
• Whether developers can execute any of several potentially dangerous tags

Understanding and Guarding Access to the Administrator
The CF Administrator is a Web-based application, which means that it's accessible over the Web if you know the URL for it, which defaults to http:// <yourserver>/CFIDE/Administrator/index.cfm. That remote accessibility is a benefit for many, but there's also the risk that someone gaining unauthorized access might compromise it. Obviously, those who know the Administrator password will be able to change any aspect of the CF Administrator settings, so the password should be guarded. Sadly, there are no mechanisms forcing you to change it regularly, so it would be a good idea to do that on your own.

You can take extra steps to secure the Administrator Web pages at <webroot>\CFIDE\Administrator\ by using Web server security to tighten control further. Just be careful that you don't lock the entire CFIDE directory one level up, because there are more things in there than just the Administrator. Such measures are discussed at www.macromedia.com/v1/Handlers/index.cfm?ID=10954&Method=Full.

Another idea is to remove the CFIDE/Administrator/directory if you're not using the Administrator at all (which is unlikely, but possible), or simply to move it so that visitors to your server can't easily guess its location. Just be aware that there is a setting in the Administrator - the Unsecured Tags Directory - which by default points to that Administrator directory. If you move the directory, be sure to change that as well or the Administrator won't function. The Unsecured Tags Directory was discussed in detail in my February CFDJ article (Vol. 4, issue 2). More on that in a moment.

Understanding and Guarding Basic Studio/RDS Security
As for the aforementioned RDS password, for those not familiar with it, it's used when setting up Studio's RDS mappings feature to allow a remote Studio user to see the files and data sources on the server, as well as perform debugging against that server. For more information on this, see the Macromedia manual "Using ColdFusion Studio," which, like all CF manuals, is available online on your server (if the docs were installed). If you own Studio, you'll find them in Studio's Help feature. Anyone can view all the CF (and Studio and other) docs online at http://livedocs.macromedia.com, as was described in more detail in Part 1.

One problem with the RDS password feature in basic security is that it's an all-or-nothing proposition. Anyone who knows the password and connects to your server via Studio can obtain any resources that the CF Server has access to. The next section shows you how Advanced Security offers an alternative that can provide more granular control over who can access what via RDS. Just know, too, that you can do a couple of things even with simple basic security enabled.

First, you should almost never uncheck the "Use a ColdFusion Studio Password" option in the Administrator, which means that no password is required at all. This is similar to the checkbox for the admin password, as shown in Figure 1 (the same admonition obviously applies to the admin password). It may seem obvious that the Use Studio Password checkbox should be checked, but some administrators who don't understand the Studio/RDS password - or misunderstand it, thinking that it might disable RDS - simply turn off the checkbox, not realizing what could happen. Any Studio user who connects to the server could now access any resources under CF's control, unless you take one of the additional steps below.

Indeed, if you know you're not going to support RDS access to your server at all (not a bad idea in a production environment), you can disable the ColdFusion RDS Service. Like the ColdFusion Application Server and ColdFusion Executive services, it's set by default at installation to start when your server is started.

Another thing you could do, as with the CF Administrator itself, is apply additional Web server security to the RDS connection. When a Studio RDS session is connected, Studio actually runs something like a Web service request to the server (using WDDX under the covers), interacting with a program in the CFIDE\Main\ called ide.cfm (ever wonder where the CFIDE directory got its name?). You could apply additional Web server security to that program or directory as another level of protection. Just be sure to test things out within Studio, since some changes you make may not allow Studio RDS connections to work at all. Again, we're discussing authentication here - who's allowed to use the RDS feature - rather than authorization - what an authenticated user is allowed to access within the server once connected via RDS. That kind of security, enabled by Advanced Security, will be discussed later.

A final way to limit what RDS users can see when they connect is to have the ColdFusion Server service start under an account other than the default, System. There are many possible ramifications of that choice, so I recommend you research it carefully before considering it.

Understanding and Fully Leveraging Basic Tag Restriction Security
The third and final aspect of basic security is optional control to restrict access to a set of potentially abused CF tags. If you follow the link for Tag Restrictions, as listed in Figure 1, you'll be presented with a screen like that in Figure 2. If any of the tags listed here isn't checked, no developer on the server can execute that tag. It's a brute force approach, but in the name of security it works.

As with RDS security, this aspect of Basic Security is an all-or-nothing proposition. If a tag is restricted, the intention is that no one on the server can use it at all. A developer may be unable to perform some needed action, like a CFFILE file upload or a CFCONTENT download. For many that's too severe, and they may choose instead to leave the tags unrestricted, which exposes any applications on the server to potential abuse by less scrupulous developers on that same server. There are two alternatives to consider.

First, in my February article, "Unlocking Restricted Use of CFFILE, CFCONTENT, and More," I wrote about using the Unsecured Tags Directory option, which is also offered at the bottom of Figure 2. With that you can still choose to restrict the tags, but any code placed in the named directory can indeed execute any of the otherwise restricted tags (whether by CFINCLUDE of a template there or a call to it as a custom tag, as with CFMODULE). That's a cool alternative, if you didn't know about it.

But there's another solution, which on the surface would seem absolutely ideal for this challenge - and many others - and it's the subject of the remainder of this article: Advanced Security, the second part of CF's built-in access-control mechanisms.

CF's Advanced Security Option
The Basic Security mechanism is nearly as old as CF itself, but in release 4 the CF team recognized that a finer level of control was needed beyond the previously available all-or-nothing aspects of securing the Administrator, RDS access, and the tag restrictions. The Advanced Security mechanisms were created to give finer-grained control over those things and much more.

Advanced Security (in CF releases 4 and 5) is enabled by the (transparent) bundling of a third-party product called SiteMinder from Netegrity. It's an option available at installation time and can be added after installation. The only changes it makes to CF are the addition of new mechanisms in the Administrator for controlling the setup of Advanced Security and a couple of tags and functions for the application-level security that it can enable.

Briefly, some of the things Advanced security can enable and/or control are:

Sandbox security, which may be most useful in a hosting environment, as it restricts at runtime the available directories and files that the users of a given application can access (not related at all to RDS security, and different from the authorization abilities described above)

We don't have room for more detail, but there is ample coverage of it in both the "Advanced ColdFusion Administration" manual (renamed and improved in release 5) and the "Application Security" chapter of the ColdFusion user's guide, named "Developing ColdFusion Applications" as of release 5. Again, if you don't have the printed manuals, these docs are available online at http://livedocs.macromedia.com (and are available for purchase as a complete set as well).

It may be worth noting that the ability to authenticate against a database was introduced in version 4.01 of ColdFusion. Initially, many administrators or developers may have dismissed using the authentication features because they didn't want to deal with the complexity of an NT domain or LDAP server, but they may not have heard about the fix in 4.01 that solved that problem. (Indeed, there were many small but important changes in 4.01, and now, two years later, I'd still recommend my February 2000 article, "Hidden Gems in 4.0.1" (Vol. 2, issue 2). There's so much that people missed and still don't know, or worse, spread as misinformation.)

Advanced Security Setup
Briefly, the key is the initial process of creating:

• One or more user directories indicating what database, LDAP server, or NT domain will be used for authentication for an application or for RDS access (you can have different user directories for different purposes)
• One or more resources describing the actual resource (file, directory, tag, collection, etc.) that you want to control and the type of access to it that should be allowed
• One or more policies mapping what users should be allowed access to what resources
• One or more contexts serving as a logical grouping of related user directory, resource, and policy specifications

A better discussion of the details can be found in the Advanced Administration book, specifically the section "Advanced Security Basics," at http://livedocs.macromedia.com/ cf50docs/Advanced_ColdFusion_Administration/AdvSecurity3.jsp.

While you're debating whether to use Advanced Security, remember that, even if installed, it doesn't take effect unless the administrator chooses to set it up and enable it. That's done by way of a checkbox called "Use Advanced Security" at the top of the Advanced Security page. Furthermore, simply checking the box won't have any impact unless and until you configure it further.

Another thing to keep in mind is that it can be enabled to secure one aspect of the server (for instance, controlling RDS access) while not impacting existing applications at all. In fact, Advanced Security won't affect existing applications unless they're modified to leverage the new features (tags and functions) that it enables. So there's no harm in trying it out. As usual, it's best to experiment with any new approach in a development or testing environment before implementing it on a production server.

It's worth mentioning here that a free, single-user developer edition of ColdFusion is available for such testing. You no longer have to get it from CF Studio alone. Just download the fully functioning, non-user-limited trial version of CF that, after 30 days, will revert to a single-user version. It will remain fully functioning in every other respect. Both it and the downloadable trial version are Enterprise versions of ColdFusion. Some aspects of Advanced Security, such as Sandbox Security, are only in the Enterprise version.

Challenges in Implementation
Advanced Security offers quite a few useful improvements. Unfortunately, the SiteMinder integration underlying it has proved challenging for several reasons, and most developers have thus never benefited from its existence. There are also other reasons why it hasn't been that popular.

It's an option at installation, so many don't even install it, not knowing any better. Furthermore, since it requires setup, many admins have never bothered to take that next step, or they may fear that enabling it without the complete setup will harm their environment (it won't). Since the benefits aren't obvious to admins and developers unless they read the manuals, many developers have never learned of it nor have they demanded its support by their administrators.

There are some more substantial problems, however - even for those who have tried to use it. For example, the Administrator interface for setting it up can be quite difficult to understand and use. It's been improved in both 4.5 and 5, but it's still daunting. Also, since there are so many ramifications to what it enables, it's easy to misconfigure.

In addition, the default installation uses an Access database as the underlying SiteMinder repository, which of course does not perform well. Even in a low-volume site, the highly interactive nature of the Advanced Security authentication capabilities is such that it can bog (or break) down rather quickly. The simple solution is to use an alternate database, and there are knowledge-base articles and documentation (quite improved in CF5) about doing just that, but the bottom line is that many have just not bothered to install or use it at all.

All this is too bad, because there are quite a few positives about Advanced Security. While there's talk of substantial changes coming in the next release of ColdFusion, code-named Neo, at the time of this writing (early March) it's still in beta. It will be interesting to see if the response of the Neo team is toward making what Advanced Security tried to offer more effective, or toward removing features that people never bothered to use. That would be unfortunate, because it's not that the features it enabled weren't worthwhile, but that the initial implementation, marketing, and education appeared lackluster, and most influential users who tried it got a bad taste.

The docs are better, and there are several KB articles on Advanced Security. Just visit the KB Search form at www.macromedia.com/v1/support/knowledgebase/searchform.cfm and search for "Advanced Security." You might want to try it.We can look forward to what awaits us in the next release, but at least now you know what's possible in the meantime.

Other Aspects of Security in the Administrator
While I've focused on the distinctions between Basic and Advanced Security in ColdFusion, there are still a few other aspects of security worth mentioning (and worth your exploring).

Perhaps the simplest to appreciate is security of your data sources by the use of database usernames and passwords that will be controlled by the database engine. If you use such security, you can choose to store the userid and password in the Administrator's data source definition itself, or you can specify it on the CFQUERY (or any other database-related tag) itself.

An Aside for Users of Microsoft Access
Many of you never bother to secure your database at all, but it's certainly worth doing. One simple way is to create a password for the entire database using Tools>Security>Set Database Password within the Access interface, and then specify that in the password field for "Default Login" (the username defaults to "Admin"), or you can specify that username and the newly set password within a CFQUERY itself. That way, if someone steals the database, it's not that easy to open. And if you want to create individual user logins for the database, look into the Workgroup Information File feature in Access. With that sort of security in place, you can specify that file as the System Database when setting up the data source configuration in the CF Administrator and then use usernames and passwords within your application, as with any other database.

Many don't notice that as another measure of security you can set which SQL statements are or are not allowed via a set of checkboxes in the CF Settings for a data source. (Internal database security can limit that as well, of course, but this is just another possible level of control.) You can even have multiple data sources for the same database with different controls (of SQL statement access or even username/password combinations, if that makes sense for you).

Moving from databases, still another source of security is control over resources on the server and associated servers by way of the Web server and/or operating system, which might be used instead of or in addition to CF's Advanced Security.

Yet another aspect of security involves the ColdFusion Administrator Debugging settings. These are discussed at length in the CF Manual "Installing and Configuring ColdFusion Server" in a section available online at http://livedocs.macromedia.com/cf50docs/ Installing_and_Configuring_ColdFusion_Server/basiconfig13.jsp. You should investigate whether to enable debugging at all, as well as which users should see the debugging output and what potentially sensitive information should be shown or restricted, such as whether to show SQL and data source information and whether to show the full template path of a template in error. I discuss those latter two aspects in my October 2000 article "Toward Better Error Handling (CFDJ, Vol. 2, issue 10).

Another aspect of Administration security that may be worth noting is a change as of release 5. CF5 Enterprise now tracks all the configuration changes you've made to the ColdFusion Administrator, providing options for both a setting summary (a snapshot in time) and change log (an audit trail).

In these days of increasing instances of hacking and occurrences of worms and viruses, administering the server also requires paying attention to security, not only of the ColdFusion Server itself, but also the Web server and physical server environment. To that end, there is a security zone at Macromedia (www.macromedia.com/v1/developer/SecurityZone/) with information that should be understood by anyone setting up a ColdFusion Server (it covers issues related to some common Web server and database security problems as well). It includes more Macromedia products than just ColdFusion, of course, but there are many CF-specific sources there, such as security bulletins, best practices, and white papers. There's even a notification service to receive security bulletins by e-mail as soon as they're released.

.  .  .

I hope this quick tour of features, possibilities, tips, tricks, and traps will make you at least a little more familiar with what's available to make your server more secure and have it running more effectively - not just for administrators, but for developers and end users as well.

Published Apr. 8, 2002— Reads 8,379
Copyright © 2008 SYS-CON Media. All Rights Reserved.

Related Links

▪ Figure 1

▪ Figure 2

About Charlie Arehart
A veteran ColdFusion developer since 1997, Charlie Arehart is a long-time contributor to the community and a recognized Adobe Community Expert. He's a certified Advanced CF Developer and Instructor for CF 4/5/6/7 and served as tech editor of CFDJ until 2003. Now an independent contractor (carehart.org) living in Alpharetta, GA, Charlie provides high-level troubleshooting/tuning assistance and training/mentoring for CF teams. He helps run the Online ColdFusion Meetup (coldfusionmeetup.com, an online CF user group), is a contributor to the CF8 WACK books by Ben Forta, and is frequently invited to speak at developer conferences and user groups worldwide.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...