Someone posted a message on cf-talk today that quickly mushroomed into a discussion on shared hosting and the related security risks. There is nothing wrong with shared hosting, and for many applications shared hosting may be the right choice (due to the low cost). But such an environment does have inherent security risks, and it is important to understand them.
Unless you are running ColdFusion on top of a J2EE server (more on that in a moment), computers run a single copy of ColdFusion. This is true of all versions of ColdFusion, starting with CF1 all the way through CFMX.
What does this mean? Several things. For starters, the performance of any application is affected by the performance of any other, if someone were to write really bad CF code that slowed his or her application, your application will suffer too. In addition, settings are shared (debugging settings, caching settings, timeouts, global error handlers, etc.). This will likely mean that when you ask for a CF Admin setting to be changed for you, you’ll be told “no”. Furthermore, when an update or service pack comes out, you’ll probably have to wait to be able to use it – your ISP will generally need to be extremely conservative when it comes to making any configuration changes. And you can forgot asking for a service to be restarted when the need arises.
All of these may or may not be valid concerns, but they are not the really big concern. The really big concern is security. On a shared box resources are shared. Data sources defined for one application may be used by another. Files and directories belonging to one application may be accessed by anyone with access to and . Even scopes may be shared.
At a high level there are two ColdFusion features that can help with the problem, or rather, can help with different parts of the problem. One option is to disable the use of “dangerous” tags. I know of lots of ISPs who do not allow the use of , , , and other tags too. And while I appreciate that turning off the use of these tags can help, I do not like this option at all. For starters, it is unfair to users to prevent them from being able to use the language elements they want. In addition, it creates a false sense of security, as if somehow this solves the whole problem. I personally would never host with an ISP who imposed language restrictions on me. Another security option is to use sandboxes, this allows an ISP to lock down CF activity by directory structure, so that applications in specific directories have access to their data sources and files but not others, and perhaps even allowing some applications to use CFML language elements that others may not. This does not solve all security problems, but it does help quite a bit. Sandboxes were introduced in CF4, but they only became easy to use in CFMX. As such, many ISPs don’t use them. My advice would be that if ISPs won’t use sandboxes, then you don’t use them.
Beyond all this, there is another risk, and there is no solution for this one in a shared hosting environment. As already said, all applications share the same ColdFusion. Stuff in the SERVER scope (which you generally should not be using anyway) is shared by all applications. Stuff in APPLICATION is shared by all instances of the same . Stuff in SESSION is shared by all requests containing the same session identifiers. So if two applications have the same then they will share an APPLICATION scope. This mean that if a malicious user were to learn your then they could change your APPLICATION scope variables. There is no way around that one in a shared instance. It’s one of the risks you have to take when using a shared ColdFusion server.
Having said all this, shared hosting is not a bad thing, but it is inherently risky (this is nothing to do with CF, if you were using ASP or PHP or Perl or whatever it would be just as risky). Sites that need high security and high availability and complete control should not be using shared hosting, they need dedicated hosting. In the past this meant a dedicated box, but this is not the case anymore. Using ColdFusion on top of a J2EE server it is now possible to have multiple instances of ColdFusion in the same box. For the right clients and applications, this is the only really safe way to implement shared hosting.

6 thoughts

  1. For those of you who subscribe to CFDJ, my column this month covers just this subject: how and why to use ColdFusion for J2EE.

  2. So if you have 1 CPU license for both CFMX J2EE and JRun, you can run multiple instances of CFMX on this 1 CPU machine? And if you can, then can you tell me how many instances could this 1 CPU machine handle (lets say it’s 2GHz Xeon with 2 GB memory)?

  3. I don’t know what the magic formula is, or if anyone has one yet. But, each CF instance requires 80MB-100MB to run (that is just the CF engine, not your code). On a 2GB box you could probably have several instances. Of course JRun has overhead too, as does the OS, and whatever else you’re running. What it will really boil down to is what you consider to be acceptable performance.

  4. As Ben says "It depends", and it depends on a lot of variables. As an example, macromedia.com runs on three 8 CPU, 8Gb Solaris machines. Each machine runs two instances of CFMX for J2EE. Yes, just two. We have 2Gb allocated to the Java heap for each instance with a ceiling of 3Gb. That limits us to two instances (to leave enough memory for the O/S etc). How did we figure that out? Load testing. See Brandon Purcell’s "Under the Hood" report about that. Note that CFMX for J2EE can take advantage of multiple CPUs – a single instance of CFMX for J2EE will outperform CFMX Server (Standalone) on a multi-CPU machine. See the performance whitepapers on macromedia.com. So, can you run multiple instances of CFMX for J2EE on a single CPU box with 2Gb RAM? Yes. Will it perform well under heavy load? Probably not. So it all depends on how much load you’re expecting. I’d really recommend at least one CPU per instance (and, yes, I realize that means more licensing costs).

  5. Among other security measures, my hosting service has shut off all of the "dangerous" cf tags (cffile, cfdirectory, etc)
    However, they wisely (and conveniently) provide their customers with CFX alternatives (cfx_file, cfx_directory, etc) These are Java CFX tags that work exactly the same way as their native cf counterparts except that they all require a valid username and password.
    I have 2 points to make…
    1. I think this kind of solution is grounds to override Ben’s advice to boycott hosts that disable "dangerous" cf tags.
    2. Hooray for my hosting company (uplinkearth.com). Customer service, it seems, is still alive and well in some companies.

Leave a Reply