A thread on cf-talk over the last few days has focused on the possibility of "snooping" application scope data in shared hosting environments. Some people are outraged and think this represents a fundamental design flaw in ColdFusion. Those people do not understand how the underlying J2EE system works.

Shared memory space. If you run multiple applications within a single JVM, they are by definition sharing a single memory space and will compete for resources. If you want isolated memory spaces, you really need to run multiple JVMs - one per application. That's why ColdFusion Enterprise lets you run multiple server instances. Yes, that might eat up resources but that's the price you pay for isolation.

The application context. What is an "application" really? In J2EE, the notion of an application is a bit fuzzy but if you look at Servlets in particular, you see that all Servlets that operate in a single context root share a single Servlet context - a single application context. ColdFusion is usually installed under a single context root (typically "/cfusion") and therefore all applications running inside that ColdFusion installation will, by definition, share that single application context.

Servlets and sharing. In the Servlet world, if you have a bunch of Servlets under the "/foo" context root, then they all share a single application context and can use it to exchange common data. If you have another bunch of Servlets under the "/bar" context root, then they all share a single application context - but it is a different application context to the Servlets running under "/foo". Yes, even in the same server instance.

Ah, so you don't have to use separate server instances to get separate application contexts? Right, you can use multiple context roots within a single server instance. What does that mean for ColdFusion? Well, you could perform multiple installs of ColdFusion within a single server instance just using separate context roots. A shared host environment could actually have a completely separate install for every customer, all within a single server instance. All of those installations would share the JVM memory space and compete directly for resources within that JVM - but that's already true if you have multiple customers on a single ColdFusion installation anyway.

ColdFusion "applications". The other thing to bear in mind is that ColdFusion's notion of application is even fuzzier than J2EE's. You define an application in ColdFusion purely as a runtime programming convention. What I mean is that a single page can be part of any application, determined purely by the name= attribute in the <cfapplication> tag. For example:

This page can run as part of any application simply by specifying appname= in the URL.

It should be clear from this that multiple ColdFusion "applications" running within a single installation of ColdFusion itself would all share the same Servlet application context and, since ColdFusion and Java are interoperable via the Servlet machinery, it isn't too hard to "snoop" across application scopes - because they are all part of the same Servlet application context.

The solution to this apparent "security risk" - which exists in the underlying J2EE architecture by design - is to use separate server instances (i.e., JVMs) or at least use separate Servlet contexts (multiple ColdFusion installs within a single server instance).

Good post Sean. I think this may help some CF people understand a bit more about the architecture they are working with.

I would suggest however that this is more than an "apparent security risk". The risk is real. The fact that the risk can be mitigated, or even eliminated doesn't change the fact that the risk exists. Especially since many people are in a shared hosting situation.

The important thing is that people know the risk is there, and can than plan accordingly.

Thanks for that Sean.

Ignoring whether or not this facility is by design or not, this issue combined with the server-mapping snooping risk seems to leave CF Standard Edition accounts (as configured by most hosting services) on shared servers, looking less than secure, it has to be said.

At the very least, it sounds like obfuscated, non-guessable cfapplication names should be used without fail for typical, non-enterprise shared-server accounts.

Are you saying that within such shared setups, if two customers both happen to choose the same application name, and, for example, one <cfdump>s her application scope, she gets to see the other customer's app variables as well as her own?

No offense to anyone, but one might say that an application on a shared server is probably not functionally elaborate enough to worry about someone exposing it's methods via introspecting the various shared scopes. Granted there are situations here and there where this might not apply, but it seems most sites on shared servers are mom & pop type stuff, brochure-ware sites, etc.

However, if you DO have an application on a shared server which held sensitive information, etc., others being able to access shared scopes is really the least of your worries.

I know where you are coming from Brandon, but the *vast* majority of businesses are small, and the majority of those, in my experience, run their Web apps on shared-servers. Many small "e" businesses are micro buisnesses engaging in small scale e-commerce, power-seller e-bay trading, etc. They may not have the turnover of Amazon, but their customer and operational data is still very important to them (and to their customers).

If a hosting provider offers an account aimed at small businesses, with SSL, etc. They should ensure that the data is acceptably secure (or else at the very least, make the customer perfectly aware of the risks). I'm not sure that snoop-able server mappings and application data counts as acceptably secure in anyone's book.

I have to disagree with Sean and his line of argumentation. The risk with shared escope is older than CFMX and the underlying Java plataform and cames since Allaire introduced cfapplication. Multiple instances (the only true solution for the problem) are not an option for a traditional shared hosting (low-cost). Is worth to mention that only with CFMX the problem could be mitigated using multiple instances. With CF5 and older versions users are insecure if they use a guessable application names such as "intranet", "website" and so on (more common than we think), even using Sandbox Security.

Talking about sandboxes, what I don't understand (but I believe there's a good reason) is why sandbox security (a more feasible approach for traditional shared enviroments) does not isolate application and other shared escopes. This is something difficult to implement?

Yep Roger, I agree with you. I think in that case people aren't seeing the forest because of the trees; a third party having direct access to your databases and source code (I would imagine most people doing shared hosting are not going to depoly J2EE instances) which stores financial and other sensitive information is a much bigger problem than other users being able to introspect what is lying around in shared scopes.

As Brandon indicates, shared hosting has inherent security risks. This is about a cost / benefit tradeoff.

If you have two Servlet applications in the same context root, they share their application context. You need to place them in separate context roots to isolate them as far as application context is concerned, and you need to place them in separate server instances to isolate as far as memory space is concerned.

If you don't want your applications to be that exposed, you must pay the extra cost to get a dedicated context root or a dedicated server instance.

Someone in the cf-talk thread drew an analogy with car safety - it backfired because someone pointed out that the base model has a given safety level but spending more money gets you vehicle stability control, more airbags, anti-theft devices etc. Security costs money - that's a fact of life.

If you're worried about sensitive data in application scope, don't store any there - or use strong encryption! If you want the luxury of storing sensitive data in application scope, perhaps for caching to enhance performance, then pay the money to get your own context root / server instance. Besides, if you want high-performance, you probably ought to be looking at a dedicated server anyway. If an ecommerce business cannot afford $1,000 a year in hosting fees for a dedicated server...

Roger:

Non-guessable application names won't make a lick of difference - you can actually iterate through all of the applications on a given shared-instance server using some of CF's underlying factory methods. The code is available on numerous sites.

Roland, those factory methods can easily be disabled through sandbox security.

I completely agree with Sean here. You cannot buy shared hosting without assuming the risk that is inherent in being on the same server with a large number of sites that you have no control over. For instance, I have had ColdFusion on shared servers go down because someone wrote some bad code and locked it up...is that ColdFusion's fault? No, and while it sucks, it is part of the trade-off you make for paying less to be on a shared server. If you don't want someone to be able to access data via the application scope...put it in a different scope (i.e. if you know your application will live on a shared host - take that into account when you set it up). If email is not a secure form of communication, then I don't send my credit card numbers and bank account information over email...I don't send it and then bemoan its lack of security.

Right, but the "all or nothing" disabling of the createObject(java) permission just to solve this problem is a bit limiting. Especially when this particular reason for disabling it can be defeated by two lines of code:

<cfapplication name=""> <cfdump var="#application#">

Hopefully more hosts will start switching to dedicated CF instances via the new CF7 multi-instance functionality.

Brian, you're right, but people are not discussing if shared hosting is 100% secure or not (in fact nothing is 100% secure). The problem is that the shared escope issue in CF is very risky, even for a shared ("not secure") hosting.

Security sandboxes does not address the issue but it should. If not, there's no reason for Macromedia to say sandbox security is a "plus" for the Enterprise version. It does not isolate things as it should. In the CF7 we have (finally) the option to use CreateObject() and CFOBJECT to invoke our CFCs without risking the server opening access to the CF service factory and the underlying Java runtime, but we still need better isolation. What about a "application" isolation level, just like we have for datasources and etc?

Again, I don't understand why is not possible to do that with sandboxes.

Of course, stability and performance are always going to be compromised to a greater or lesser extent on shared servers. But I don't know anyone who doesn't accept this.

You make the point that no one would use email to send sensitive details. Email's security issues are well-publicized and widely known. However, I don't think many shared-hosting ColdFusion users, whether "Mom & Pop" sites, personal blogs, small businesses, whoever, are fully aware of the fact much of their key data is wide open on many shared server installations. This is borne out by the reactions of many developers on the various forums and mailing lists when they learn of the realities. Sensitive data isn't just passwords and customer details, it's any data that relates to the person or business.

I've just been able to loop through the application structs of each of the applications on one of several shared CF Servers that I have access to - and have found the DSN names and passwords of many of the users on the system. It gets even more interesting and sobering when Fusebox is being used - as I'm sure Fusebox users can imagine with the whole application stored in application scope.

Many of the more experienced developers on the CF-Talk thread reacted with smug disdain when the issue was discussed. "What, you didn't know? (Subtext: You shouldn't be using ColdFusion if you're that ignorant...). OK, so that's the deal. I thus assume that those in the know will from now on routinely include clauses within their blog and site FAQs that ColdFusion on shared servers isn't secure. I assume Macromedia will instruct their resellers to make it *perfectly* clear that this is the case (I've used about four CF resellers now and none have ever mentioned the risks of using shared scope data as a mechanism for storing sensitive data, or that the mechanism is exposed on typical shared hosting setups).

I don't understand the "you get what you pay for" argument in the context of security. While I acknowledge that no system is perfect and that dedicated servers have inherently less risks attached for the obvious reasons, I don't accept that low-cost should mean that application-internal data is exposed. Gmail and Yahoo are free, but they don't take this attitude. Mobile telecomms is an industry that sells aggresively on price, it doesn't take that attitude (yes, I know the tech is different, but the principle remains)

If low-cost hosting solutions are inherently insecure and inevitably involve low levels of data security, then let the hosting industry as a whole be open and up front about that instead of allowing the perpetuation of the current common misconceptions.

Sean, I share your exasperation regarding companies who want to do online retailing but who are prepared to shell out little more than pocket money each month for the privilege, but I don't think that this has much bearing on the fundamental issue. I expect free gmail to keep my data secure regardless of whether I use the service for business or pleasure.

(apologies for the long post)

(My "you make the point" sentence was referring to a post by Brian Rinaldi above...)

Roger,

I understand your argument...and I hope I did not appear smug in my post. While I understand that not everyone is aware of the risk, that is not exactly what is going on. I am glad the risk is getting some publicity here, but this discussion seems more about whether this risk should exist (as I believe most posts here are from people who are aware of the risk..and the same went for the posts on CF-Talk).

I do think you get what you pay for in this instance, as what we are asking from a shared host to remedy this issue would directly affect the profitability of the product (i.e. creating a unique instance of CF for each site on a shared server). I have not looked into this, but I would be willing to bet that someone offers this level of service on a shared server - for a price.

I think the car analogy mentioned earlier works well here. I can get a car with all the safety features and spend more or I can get one with limited safety features and spend less. That I am aware of the difference is important, but in the end that difference will exist regardless of how wonderful it would be to get those features for the same price.

I am curious: how do other scripting environments deal with this issue? If I am running PHP, is this still a problem? If not, how does PHP manage this? How does ASP.NET (and old-style ASP) deal with this problem on a shared host?

Seems like it's the hosting services' responsibility to inform users of this risk, not MACR, no? And, at some level, isn't it the developers responsibility to understand the tools they use?

Well, this has been a very sobering discovery for me. I have always assumed that even on shared servers the sandboxing prevented code running within one application from being able to access memory scopes generated within another app.

While I knew of the existence of undocumented methods, I had assumed that their use would be blocked within shared environments, at least for those that could be used to access memory not connected with the current app. Boy, am I feeling naive.

Does this mean, as i assume it does, that some enterprising fellow could also run methods on cfc's that are cached in application scope in their neighbor's application?

Yes, yes it does. To ColdFusion, the mere presence of a CFAPPLICATION tag with a given name is the only thing that defines an "application" as far as the Application scope goes.

In a shared hosting environment someone could also instantiate your CFCs and (assuming CFFILE and CFOBJECT/createObject are not disabled) read all your files.

Again, this is not some kind of failing in ColdFusion -- it's an inherent part of the shared hosting configuration.

I'm still hoping someone can answer the question about how PHP and other environments deal with this.

Nathan, I'm not sure, but I believe that for traditional ASP apps and hosting, IIS Websites works as separeted "instances", not allowing users from differente websites to spoil "application" variables from others.

Also, for traditional JSP hosting, AFAIK (folks, please correct if I'm wrong!!) you must have multiple instances just like CF/JRun to address the issue, but since you don't need to install/deploy CFMX (a not so lite java app that sits ontop of your Java server), you need less resources to do it, making a shared (low cost) approach more feasible than a Java with CFML support.

Alex, yes, if you have a single context root, your JSP applications will share the same application context. Perhaps JSP shared hosting companies have a separate context root for every client?

Nathan, PHP does not have a built in analog to cfapplication and the extensions that add it have the same security considerations. Shared memory is, well, shared. For this reason, most hosts that have packages installed with a shared memory cache option have that portion disabled. On the PHP applications I build I only use shared memory for "friendly" servers; on shared hosts That sort of info is serialized and stored to the file system or a DB. With proper abstraction the "application" data store method can be set in one location.

HTH, Alan

I would have thought Macromedia or Allaire would have chosen to handle the possibility of "sharing" App Scopes by using a bit more software engineering than they apparently did. I would have wanted to see the logical separation of App Scopes more than the physical separation of App Scopes because logical separation could have been achieved using very little code and very little runtime overhead. Something as simple as creating an Associated Struct that stored the App Scopes in which each actual App Scope is associated a specific instance of a ColdFusion Application in such a way so as to guarantee that each specific <cfapplication> invocation gets a different and unique App Scope based on a system generated GUID, for instance. If a GUID had to be generated for each App Name it would be pretty difficult to "snoop" especially if the host name the App ran on was made part of the hidden system App Name. I can think of a lot of ways to better handle this sort of "problem" other than to simply allow J2EE to work-it-out. Anyway, this is just my 2 cents.

Ray, yes, a completely separate application scope mechanism could have been designed - but that would have made interop with Java / JSP harder. And this is a "problem" that JSP already has by design. I think it's perfectly reasonable to defer to a "previously unsolved problem", i.e., to do whatever J2EE already does.

Your point is certainly well-taken when it comes to interoperability however there are 2 points I would still like to assert with some hope that they are somewhat valid. (1). It is a pain in the rump to to setup multiple JVM's - I know because I have not dug deep enougn into the mechanics of "how" this is done as of yet and I am no noob when it comes to working with ColdFusion and (2). Unless you are saying it is required to maintain interoperability with JSP all the time in order to get ColdFusion to work at-all it would still have been a more elegant solution to cover the security bases whenever JSP or Java interoperation was not required because since point (1) is a hurdle most cannot get around out-of-the-box without some additional kowledge of J2EE that has eluded me thus far the default behavior for ColdFusion out-of-the-box is to possibly have a huge security breach and this is simply not desired.

Now then, if the best solution is to handle this App Scope Security Breach by correctly leveraging J2EE by making multiple JVM's then by all means provide a solution out-of-the-box which means Macromedia/Adobe should provide an automated means of making multiple instances of the JVM each capable of having a separate instance of ColdFusion without having to worry about licensing issues. Personally I feel single-CPU licenses should allow unlimited usage of instances of a product as long as all instances run on the same CPU - unless this is not a licensing issue at all and then I consider it less than desirable for Macromedia to leave it up to those who know how to properly setup a multiple JVM setup in order to be able to have no App Scope Security holes.

These are the points I was trying to make before in my prior comment(s).

CFMX 7 Enterprise provides a multi-server configuration that allows you to create new J2EE instances with the click of a button, inside the CF Administrator, no Java knowledge required. You can run as many instances as you want on a single server - per the license (which, by the way, is a 2 CPU license). It seems that CFMX 7 Enterprise does exactly what you want.

Okay, I think I see your point now.

The setup that seems to be missing from the picture then would be a single JVM with many instances of CF Server or am I still confused ?

You can have a single server/JVM instance with multiple CFMX installs. But those are not clones (which is what the builtin CF Admin functionality provides). They are not clones because they have different context roots. You can use a master instance to build out multiple installs on a single server/JVM in a fairly automated manner tho':

1. Use the CF Admin to clone the master instance to a new server instance.

2. Use the JMC (JRun Management Console, port 8000) on the new server to modify the context root path.

Repeat (1) and (2) as necessary. Step (1) always clones the instance, including the context root, so this process ends up creating multiple context roots / CFMX installs on a single server instance.

OKay but I am a bit unclear about the steps to accomplish #1. Can you elaborate more about this. Thx.

1. CF Admin > Enterprise Manager (left menu) > Instance Manager > Add New Instance

Give the new server instance a name and click Submit.

That's it.

Okay that seems pretty easy and I had no idea it would be this easy.

Now, what about the context root path - what path would I use and how would I know what it should be ?

You can set the context root to any name. The "empty" context root is / and a 'typical' CFMX J2EE install uses /cfusion (per several of the install docs). It is the start of each URL.

So then is the context root an arbitrary name that has nothing to do with any folder structure ? I have never been clear on this point. I guess I am thinking the context root, whatever I wish it to be, would also need to match a folder name... or am I confused ?

The context root does not need to match any folder structure (by default it typically does - but it does not need to).

Ah, and all this time I have been under the wrong impresson but then it might not have mattered had I simply forged ahead and spent a little time working this this side of CF. Guess I just learned someting new... imagine that !

Further to this conversation - I have created some methods which allow you to view the running applications on a CF box - which is designed to make managing and restarting the easier. http://www.lynchconsulting.com.au/blog/index.cfm/2006/10/23/

Obviously they are very dangerous in shared hosting environments but this is not a bug in ColdFusion but the responsibility of the hosting provider - (i.e. disable createObject('java').

If the hosting provider allows users to ftp out of their shared website directory it is not the operating systems fault - just the configuration of the server (i.e. the Hosting providers fault)

A more secure place to keep your DSN's and usernames and passwords may be the request scope as it does not persist - and the overhead would be minimal.

Name:
Email Address:
Comments *** Please note that all comments require moderation so it may be some time before your comment posts to this blog! ***
Remember My Information: