Have you looked yet into the new feature in Macromedia ColdFusion
MX called "sandbox security" or "resource security"?
If you haven't, you should do so because it allows the specification
of controls over the resources (data sources, files, directories,
tags, functions, and more) that ColdFusion templates are allowed
to access. Whether you're a developer or an administrator, it's
important that you understand how this new feature works.
In fact, I'd argue that every developer and administrator should
understand this topic. It's quite easy to grasp and it can be
important for ensuring security and integrity in your application
development environment. Even though it's especially important
for those working on hosted or shared corporate servers, those
of you with a single application may still benefit from the opportunity
to reign in the power that ColdFusion offers.
If you remember previous implementations of "advanced security"
in ColdFusion 5 and 4, you'll find that the ColdFusion MX approach
is much easier to configure and, in most ways, adds features.
In this three-part series, I introduce you to sandbox/resource
security, show you how to set it up, and explain some common challenges
faced when working with it. For those using ColdFusion MX Enterprise
Edition, the feature is referred to as “sandbox security”
while in Professional Edition, it’s referred to as "resource
security." The terms are often used interchangeably, which
has contributed to some confusion. In some ways they're the same,
but in other ways they're different.
This first article clarifies the distinction, as well as explains
them both in comparison to the advanced and basic security features
of the previous releases. There is a good bit of misunderstanding
and some misinformation in current discussions. Hopefully this
will help put the new feature in proper perspective, as well as
motivate all developers and administrators to investigate this
powerful, important new feature.
Part Two, "Setting
Up Sandbox/Resource Security", walks you through the
configuration of this security, and Part Three"Challenges
Working with Sandbox/Resource Security," (coming soon) discusses
some of the challenges you'll face, especially migration and configuration
issues. Before jumping into setting it up, it will help to have
some background.
Restricting resource access for security
Sandbox/resource security is an optional feature that can be selectively
enabled in the ColdFusion Administrator to give an administrator
greater control over what ColdFusion pages are allowed to do.
It's disabled by default when installing ColdFusion MX.
Because ColdFusion code runs under the auspices of the ColdFusion
server, it has access to whatever resources (with whatever
permissions) are granted to the account under which
ColdFusion is running. (For more information about this,
see TechNote 11859, "Running
ColdFusion as a Specific User.") If you don't
enable sandbox/resource security, tags such as cffile,
cfcontent, and cfdirectory
can provide ColdFusion code access to more resources
(such as files and directories) than may be appropriate.
The same goes for ColdFusion functions such as GetTempFile,
DirectoryExists,
FileExists, GetProfileString,
and SetProfileString.
Furthermore, some ColdFusion tags can expose quite a lot of power,
such as cfregistry and cfexecute, whose misuse could threaten
the integrity of the server.
Even on a server with a single ColdFusion application, there
may be things you want to control more tightly, such as certain
tags that give developers access to the Windows Registry and more,
or limiting the files that ColdFusion tags and functions can access.
In the case of a ColdFusion server with multiple applications—whether
it's a hosting provider or a corporate intranet—you most
certainly want to prevent one application from accessing files
and directories that belong to another.
With tags that manipulate data sources, you might want to restrict
which data sources an application can access. Of course, database
security control is another important measure of defense, but
especially in a shared environment you might want to prevent ColdFusion
code in one application from being able to access a data source
belonging to another application.
Comparing sandbox/resource security to advanced/basic
security
The potential for exploitation is not new to ColdFusion MX. ColdFusion's
flexibility and power has always demanded equal measures of responsibility
and care. It may be useful to understand how ColdFusion MX's sandbox/resource
security compares to similar features of previous releases.
To address this concern over controlling resource access, ColdFusion
4 introduced an approach (which ColdFusion 5 preserved) to provide
more granular access control with what it called "advanced
security." Similar in some ways to ColdFusion MX's sandbox/resource
security, this feature provided options to control whatever resources
a given application was allowed to access.
It leveraged an underlying tool called Netegrity
SiteMinder. Besides its unpredictable performance, a rather
confusing setup process, and scarce debugging tools, advanced
security was not easily understood by most developers and administrators.
ColdFusion MX no longer relies on Netegrity SiteMinder for its
security implementation. (Therefore, tags such as cfauthenticate
and functions such as IsAuthorized are also no longer supported.)
ColdFusion 4 also introduced a more global sort of security control,
called "basic security," which ColdFusion 5 also kept.
Rather than use advanced security to set up control on an application
basis, an administrator could simply restrict access by any code
on the entire server from executing any of several possibly dangerous
tags such as cfregistry, cfexecute, cffile, cfcontent, and so
forth. ColdFusion MX also no longer supports this approach to
basic security.
Sandbox/resource security is a much simpler, yet capable, means
of providing either such global or more granular access control
to resources for ColdFusion applications.
As you will learn, resource security in ColdFusion MX Server
Professional Edition applies to all code on the server so it can
be thought of as similar to basic security in the previous releases,
even though it's much more powerful, granting full control over
not just tags but also functions, data sources, files and directories,
and more. Meanwhile, ColdFusion MX Server Enterprise Edition's
sandbox security does indeed provide the same sort of application-level
control over access to resources but with much less configuration
hassle. Indeed, you can set up sandbox/resource security in just
minutes in ColdFusion MX. You'll learn how to implement it in
Part Two of my series of articles.
Note that whereas ColdFusion 4 and 5 offered a handful of tags
that could be restricted in either basic or advanced security,
ColdFusion MX provides the option to restrict any of 25 tags with
sandbox/resource security, adding such tags as cfcollection,
cfldap, cfinvoke, and even cfquery. It also adds the option to
restrict any of 12 functions such those listed previously as well
as CreateObject, ExpandPath, GetBaseTemplatePath, and more.
While the new approach is simpler, there are some aspects of
advanced security that were not retained in ColdFusion MX. For
instance, advanced security provided a means to control directories
accessible to specific RDS (Remote Development Services) users
from within ColdFusion Studio. That is no longer available. Advanced
security also provided additional options for supporting programmatic
user security, which controlled authentication of users against
a variety of user directory options. ColdFusion MX has introduced
new tags such as cflogin to
replace that programmatic approach. See the ColdFusion MX documentation
(or look at ColdFusion
MX LiveDocs, the online documentation for ColdFusion MX) for
more information, as well as Rob Rusher's article, "Security
Best Practices: Authenticating and Authorizing Against NT Domains
with ColdFusion MX." In my series of articles, Part Three
(coming soon), explores these matters further.
How sandbox security and resource security differ
Up to this point, I've generally referred to the feature as "sandbox/resource
security" because the single feature is implemented in slightly
different ways and therefore referred to differently between the
Enterprise and Professional Editions of ColdFusion MX Server.
Although the distinction will make more sense once I walk you
through the setup in Part Two, for now just understand that in
the Enterprise edition, you are free to create resource controls
for as many applications as you'd like. Indeed, these are referred
to as "sandboxes" (hence the name) and are specified
as the access controls that apply for all code in a given directory.
There is no notion of sandboxes in the Professional Edition.
Instead, any resource controls apply to all applications on that
server. That will be a source of disappointment to some, but having
multiple sandboxes is indeed a benefit of upgrading to the Enterprise
Edition.
In either edition, you have the ability to control whatever data
sources, files and directories, and servers and ports are accessible
by ColdFusion tags as well as whichever ColdFusion tags and functions
are restricted totally. It's just that in the Professional Edition,
you can only define these restrictions for all code on the server.
That still has value, given that as I previously explained, ColdFusion
code is otherwise free to operate with the access control granted
to the account under which ColdFusion runs.
The Enterprise Edition's sandboxes, of course, make great sense
for a hosting provider or corporate intranet where multiple applications
share the same server. In that case, it's especially important
to be able to keep the applications separate from one other.
Any code in a directory (and its subdirectories) for which a
sandbox has been defined inherits the access controls defined
for the sandbox. It's also possible to define additional sandboxes
for directories under a sandbox, thereby nesting them. This greatly
facilitates implementing access control for a particular developer
working in a given directory, as well as specifying resource controls
for separate but distinct applications under that directory.
For instance, consider a developer named Bob who has his code
in ColdFusion MX server web root as follows:
C:\cfusionmx\wwwroot\Bob\
C:\cfusionmx\wwwroot\Bob\App1\
C:\cfusionmx\wwwroot\Bob\App2\
A sandbox applied to the Bob directory applies to App1 and App2
as well. If further controls are desired for App2, an administrator
can create a separate sandbox for that directory. Part
Two shows you how to configure such sandboxes.
(Note that if you're running the Trial Edition of ColdFusion
MX, you're actually running ColdFusion MX Enterprise Edition.
After it expires you'll still be running Enterprise Edition but
as a single-user "Developer Edition.")
Making sense of it all
I hope this brief introduction to sandbox/resource security helps
not only explain why it's important but also clarifies any confusion
you may have had about the difference between the sandbox (in
the Enterprise, Trial, and Developer Editions) and resource (in
the Professional Edition) security in ColdFusion MX.
There's some conflicting and confusing information out there,
even in the ColdFusion MX documentation. Because it's a new feature,
and also because it's very different from ColdFusion 4 and 5's
advanced security, it will take time for everyone to adjust completely
to understanding the distinctions and differences between the
two.
The next step is to learn how to enable and configure sandbox/resource
security. Part
Two will show you that. And Part Three (coming soon) will
discuss several other aspects of working with the feature that
might cause challenges, including some setup challenges as well
as migration issues for those who used ColdFusion 4 and 5's basic
security (basic security tag restrictions are not migrated automatically,
there is no longer support for RDS security on a per developer
basis), supporting sandboxes outside the default c:\cfusion\wwwroot\
location, challenges preserving the enabling of sandbox security
with the Admin "Archive and Deployment" feature, and
more.
Resources
"Security
Best Practices: Authenticating and Authorizing Against NT Domains
with ColdFusion MX" by Rob Rusher
"TechNote
11859: Running ColdFusion as a Specific User"
|
