Over the past year, reports of website security vulnerabilities
have increased—in number and severity. Security is a top
issue in application development and production. There are a variety
of responses to hackers, but (as Vernon Viehe points out in this
month's Logged
In) the most important one is prevention.
ColdFusion application developers—like all applications
developers—can take steps to prevent security violations.
When you install the Macromedia ColdFusion MX server on your local
machine, it's easy to start developing applications right out-of-the-box.
Your focus during development is on the inner workings of the
application and not on setting up and configuring the ColdFusion
administrator. When you deploy your ColdFusion application to
production, however, you expose your application to the whole
world. In this environment, things are different.
Below you’ll find ten tips for setting up your ColdFusion
MX application server with security in mind. This list is divided
into these general sections:
Note: Check out the Security Zone to learn about security issues that affect
Macromedia products and Macromedia affiliate products. Be sure
to sign up for the Security Zone Notification
Service, which will notify you each time a new security bulletin
is posted on the Macromedia website.
Features and settings to
turn off
- ColdFusion MX installation
Install ColdFusion on the production server without the documentation
and example applications. You can uncheck the Example Applications
option during your ColdFusion server installation. While the
example applications are helpful to new ColdFusion developers,
the CFML source code for these examples is freely available,
so they present a tempting target for hackers in a production
environment. The example applications were revised in ColdFusion
5 to make them more secure, but still there is rarely a good
reason to have them on a production server.
- Disable RDS (Remote Development Services) on your ColdFusion
MX production system
The easiest way to disable RDS is to set the RDS password on
your production system to a password that is not easily guessed.
Choose passwords that not are susceptible to "dictionary"
(words that can be found in a dictionary) attacks. If you can't
come up with a unique and hard-to-guess password, a quick web
search for the phrase "random password generator"
will turn up a plethora of password-picking aids. As a rule
of thumb, mix letters, numbers, and symbols in your passwords.
Note: For more information about disabling RDS, see
Security
Best Practice: Disabling ColdFusion RDS on Production
Servers (TechNote 11712).
- Turn off ColdFusion MX server debugging
In the ColdFusion MX administrator, you can enter a list
of IP addresses for which the ColdFusion server will display
debugging information. This means that when a machine with a
specified IP address browses a CFML page, debugging information
will display for that particular user. Note that if you have
no IP addresses specified and debugging is enabled in the ColdFusion
Administrator, then debugging information can appear for any
user of the application.
Entering a single IP address of 127.0.0.1 is a good choice for
a production system. Even if a clever hacker spoofs this IP
address by creating IP packets with 127.0.0.1 as the source
IP address, these packets will never be passed along through
the public Internet. Some other non-routing IP addresses are
10.*.*.*, 192.168.*.*, and the range 172.16.*.* through 172.31.*.*.
If your internal network uses these addresses, it is quite safe
for you to put the IP address of a few of your local machines
into the list.
Features and settings to turn on
- Specify a site-wide error handler on a production system
You can specify a page that will be your site-wide error handler
on the Settings page in the ColdFusion MX administrator. Note
that for ColdFusion, you should enter the relative path (such
as /swerror.cfm), rather than an absolute path to the file.
The page you specify does not need to be elaborate. A simple
message to your user that something has gone awry will usually
suffice. Since the error page is a ColdFusion page, you can
build in logic that will send you information about the error
that the user has encountered.
For instance, you could have information about the failure e-mailed
to the ColdFusion MX administrator and at the same time display
a generic message to the user (or your attackers) that contains
no information about the page being executed. You can use the
cflog tag, introduced with ColdFusion 5, to write the error
to your ColdFusion logs. Your site-wide error should not try
to perform too many actions—it would be poor design if
a site-wide error ColdFusion page itself causes an error! Instead,
use the cftry and cfcatch tags in your error handler.
- Specify a site-wide missing template handler
Often you can specify the same page as your site-wide error
handler. Neither legitimate users nor nefarious hackers need
to know much about missing pages (at least, no more than what
you would show them in your site-wide error handler). Using
the same page helps to deter and frustrate hackers who are probing
your website for similarly-named pages. You can collect a lot
of information about a potential attack if you use the cflog
tag. Using the same template for both the site-wide error handler
and for the site-wide missing template handler will keep the
hacker in the dark—he won't know if probes were wrong
or if he just failed to include some required data for a ColdFusion
page.
- Protect the ColdFusion MX administrator password
Protect the ColdFusion administrator password in the same way
that you protect the RDS password. All web servers have some
mechanism to restrict directory trees to authorized users. You
may want to use this mechanism for the ColdFusion administrator
directory, too. Remember that there are files in the /CFIDE
directory tree that ordinary users need to access. It’s
preferable to restrict access to the /CFIDE/Administrator directory
tree and not to the entire /CFIDE tree.
On-going chores
- Read your ColdFusion MX and web server logs
Very few developers literally read the ColdFusion and web server
logs, but it's important that you peruse them occasionally.
Scripts that exploit known vulnerabilities are easy to spot
in web server logs. As you look over your logs, keep an eye
out for a single IP address that has made hundreds of HEAD requests
or for requests to unlikely file names such as “CMD.EXE.”
(Not long ago it was discovered that IIS had a vulnerability
which would allow hackers to execute CMD.EXE and pass a command
line to it. If you have a Unix site, you may think that this
effort doesn’t sound so risky, but be aware that there
have been some impressive Unix security exploits, too.)
- Read security bulletins
Read the security bulletins for all of the products you use
on your website. Most software companies have a security area.
At Macromedia, it's www.macromedia.com/security; at Microsoft, www.microsoft.com/security;
at Sun, www.sun.com/security;
and so forth. The amount of time from discovery of a new security
vulnerability to the widespread use of malicious scripts that
probe websites for the vulnerability is getting shorter. The
situation can easily become a race between malicious scriptwriters
and website administrators. Since you probably want to win this
race, it's best to sign up for automatic e-mail notifications
of security bulletins. On Macromedia's Security Zone, sign up
for the Security Zone Notification
Service. Usually, web server vendors have a similar service
you can subscribe to.
- Have a recovery plan in place
If you do get hacked, have a recovery plan ready to go. Hopefully
you’ll never need it, but it’s difficult to focus
on fixing a website after a security attack if you don’t
already have a plan. If you do get attacked, there are two broad
categories of tasks to perform:
- Preserve the evidence—namely, your web server
logs and your ColdFusion MX logs. This will help you figure
out how the hacker manipulated your website. While it's
useful to be able to update your website with a backed-up
version, you'll want to compare the hacked version of your
application to an unmodified version of files so that you
can determine what has been altered. A backup of your database,
if possible, also can be useful forensic evidence.
- Restore your website. At minimum, you'll want to
restore your application and database to the unaltered state.
If you cannot quickly determine how the attack was launched
and what it affected, you may also want to also re-install
all your software, including your operating system, web
server, and ColdFusion MX server.
If you have the ColdFusion Enterprise edition, you can
use the Archive/Deploy utility to swiftly and easily reconfigure
ColdFusion (assuming that you created a fresh archive
after your most recent change). If not, a backup of your
application and records of how your data sources and other
ColdFusion settings will do. You’ll also want to
have on hand similar records of both your web server configuration
settings and your database settings if you have to re-install
all your software on short notice.
Note: We want to hear from you if your ColdFusion site
gets hacked. Please use the Alert Guidelines and e-mail
address to notify us if this happens.
Testing techniques: A hidden JavaScript
example
There are myriad development-phase techniques for creating hacker-proof
websites. In fact, there are whole books devoted to this subject
and it’s a little beyond the scope of this “top ten”
list of production-phase security tips. Nonetheless, you should
keep in mind that preventing security breaches is important during
development, too. Even after moving your application into production,
you should do some testing to see what’s vulnerable. Here’s
an example of a technique known as “cross-site scripting.”
This common website attack is a ploy to get around the rules
for JavaScript. All modern browsers honor this rule: JavaScript
can only access cookies for the website from whence it came.
The trick is for a malicious site to direct one of your unsuspecting
users to your own site via a HTML link. This link not only contains
the URL for your site, but it also contains some sneaky JavaScript
embedded in a text field. If your application sends this text
back to the unsuspecting user, it will not appear on his screen.
Instead, it will execute as if it came from your site, which—technically—it
did!
For example, the evil site may have a link to your login page
that has this code:
<a href="http://www.yoursite.com/login.cfm?username=Ralph
Cramden<script>{malicious_code}</script>&password=yyy>
When an unsuspecting user clicks on this link, the response will
undoubtedly be your application's password failure response (unless
you really do have a user named “Ralph Cramden” and
his password is “yyy”). While your puzzled user ponders
why she has received a password failure and why you are calling
her “Ralph Cramden,” the {malicious_code} part of
the script is executing in her browser. The script could be collecting
all the cookies it can access and forwarding them to a program
at the hacker's website. It is the user's cookies from your website
which are being harvested, since the JavaScript originated from
your site as far as her browser can tell.
The solution is to disinfect any user input text before you send
it back to a user's browser. You can use the ColdFusion functions
HTMLEdit() and XMLEdit(). Either tag will render any embedded
JavaScript harmless. They do this by turning the <script>
tag into <script>. XMLFormat() also changes the
apostrophe character to ' and handles < and > by
turning them into their ASCII equivalents. Either function will
disarm a malicious script and cause it to display harmlessly in
the user's browser rather than execute.
Testing your application
You can easily test your application for susceptibility to this
attack. Just copy the following not-very-malicious script and
try pasting it into various text input boxes in your application.
If you only see the script on your screen, no problem—but
if the alert box pops up in your browser, your application may
have an opening for Cross-Site Scripting attacks.
<script>alert("Ooops!")</script> You
might be surprised how often the alert box pops up on your screen.
Conclusion
This article covered some very basic security steps for ColdFusion
MX production and reviewed one example of a development-phase
technique for preventing a security breach. This barely scratches
the surface of what can be done to keep hackers at bay. This list
may help you with your initial deployment and remind you to keep
security ever near the top of your application-development priority
list. |
