CrystalTech Users Beware

CrystalTech users be aware of another issue I've recently discovered.  This could actually affect anyone on a shared server. After several weeks of unexplained errors in my site of not being able to find the datasource, a datasource I set in my Application.cfm, I figured out that my application name in Application.cfm was the same as the one of another of my sites.  So, every time site two ran, it changed the application.dsn variable for site one, which then caused site one to barf. You've heard of splitting a pizza...  anyone wanna split a dedicated server? Constanty "Connie" DeCinko III Web Architect, Webmaster, Web Developer Lone Jet Enterprises Glendale, Arizona <http://www.lonejet.com/>; www.LoneJet.com

I don't think this is unique to CrystalTech.  This would likely be the case with any hosting company that supports shared servers. It's because of this exact concern that I switched over to a new naming "policy" a few years back.  The code I now use dynamically names the application based on the directory path of the application.  The code is as follows: <CFAPPLICATION NAME="#Right(Replace(GetDirectoryFromPath(GetCurrentTemplatePath()), "\", "_", "ALL"), 64)#" ... > Basically, the code in the NAME attribute gets the full directory path for the directory in which the Application.cfm file resides, converts all backslashes to underscores, and takes the right-most 64 characters to use as the name.  This virtually guarantees a unique application name (unless the hosting company use a seriously messed up directory structure). HTH -- Mosh Teitelbaum evoch, LLC Tel: (301) 942-5378 Fax: (301) 933-3651 Email: mosh.teitelbaum@evoch.com WWW: http://www.evoch.com/ Connie DeCinko wrote: > CrystalTech users be aware of another issue I've recently discovered. This > could actually affect anyone on a shared server. > > After several weeks of unexplained errors in my site of not being able to > find the datasource, a datasource I set in my Application.cfm, I figured out > that my application name in Application.cfm was the same as the one of > another of my sites.  So, every time site two ran, it changed the > application.dsn variable for site one, which then caused site one to barf.

> I don't think this is unique to CrystalTech.  This would likely be the > case > with any hosting company that supports shared servers. Too true. ----- Excess quoted text cut - see Original Post for more ----- I do almost exactly this except I just HASH the directory path to get the name - just as unique, but saves the replaces. Jim Davis

there are a couple of things that would keep this from happening.. don't name multiple apps the same... move the dsn var out of the application scope... ----- Excess quoted text cut - see Original Post for more -----

It should be common practice to have all of your applications use different names. -- Damien McKenna - Web Developer - Damien.McKenna@thelimucompany.com The Limu Company - http://www.thelimucompany.com/ - 407-804-1014 #include <stdjoke.h>

Right, but...  What if you chose a common name and someone on the same server does the same.  Also, what if you need to test different versions of the same application on the same server?  Shouldn't sandboxing protect you from that? It should be common practice to have all of your applications use different names. -- Damien McKenna - Web Developer - Damien.McKenna@thelimucompany.com The Limu Company - http://www.thelimucompany.com/ - 407-804-1014 #include <stdjoke.h>

one thing is to move your DSN value from the application scope to the request scope and that issue is fixed... as for the app name... I always use a different name from dev to stage to production... that way I know which one I am using... ----- Excess quoted text cut - see Original Post for more -----

> Right, but...  What if you chose a common name and someone on > the same server does the same.  Also, what if you need to > test different versions of the same application on the same > server?  Shouldn't sandboxing protect you from that? I would recommend two things: 1. Come up with a good naming convention for your application names and use different names across environments (dev, test, staging, production) 2. Don't test applications on a shared hosting accounts! Mike

I only do this right before going live, to make sure something does not break due to the shared environment.  Otherwise I develop and test on my local workstation. 2. Don't test applications on a shared hosting accounts!

You're all coming up with reasonable workarounds, but Connie's point is that she shouldn't need workarounds... and  she's right! ----- Excess quoted text cut - see Original Post for more -----

Amen. Dave Francis wrote: ----- Excess quoted text cut - see Original Post for more -----

/me wonders if he ever gets tired of being referred to as 'she', or if he's just gotten used to it by now :) ...and i think that's just one of the inherent dangers of being in a shared server environment. As has been mentioned before on the 'dedicated vs shared hosting' threads...you get what you pay for. ----- Excess quoted text cut - see Original Post for more -----

Most of the time I over look it...  Kinda like call me whatever you want, just don't call me late for dinner! /me wonders if he ever gets tired of being referred to as 'she', or if he's just gotten used to it by now :)

Correction, HE's right. And yes, that is my point that there should be protections in place to prevent sites from stepping on other unknown sites on the same server.  Now if I get this on my own server, then shame on me for not being aware enough to use different names. I like the earlier suggestion that uses the location of the site as the application name.  That seems to be a safe way to add my own protection. You're all coming up with reasonable workarounds, but Connie's point is that she shouldn't need workarounds... and  she's right!

> You're all coming up with reasonable workarounds, but Connie's point is that > she shouldn't need workarounds... and  she's right! I'd consider this expected behavior and that uniquely naming an application is really a "workaround".  I think uniquely naming applications would be better framed as a "best practice", particularly in a shared environment. However, from a security standpoint I do see a problem in that you potentially have access to anyone's application scope if you can guess their application name.  If a sandbox protects your directories from other applications reading them via CFFILE, it should protect your memory space as well. -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell:  678.637.5072 aim:   cameroncf email: cameronc@mindspring.com

> I'd consider this expected behavior and that uniquely naming an > application is really a "workaround".  I think uniquely naming > applications would be better framed as a "best practice", particularly > in a shared environment. Correction: I'd consider this expected behavior and that uniquely naming an application is NOT really a "workaround". -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell:  678.637.5072 aim:   cameroncf email: cameronc@mindspring.com

> You're all coming up with reasonable workarounds, but Connie's point is > that > she shouldn't need workarounds... and  she's right! I'd agree that she "shouldn't" have to....but I also know the real world where tech support sucks everywhere and nobody but myself can be trusted with applications I write ;-) Call me a cynic....you'd be right ;-) Cheers Bryan Stevenson B.Comm. VP & Director of E-Commerce Development Electric Edge Systems Group Inc. phone: 250.480.0642 fax: 250.480.1264 cell: 250.920.8830 e-mail: bryan@electricedgesystems.com web: www.electricedgesystems.com

> You're all coming up with reasonable workarounds, but Connie's point is > that > she shouldn't need workarounds... and  she's right! Why?  There's always, ALWAYS workarounds involved when you share... well, anything! When you run a single license of the product and allow many people to use it you'll have compromises - but you get cheap hosting. If you don't want workarounds or compromises pony up for a dedicated box. Jim Davis

No she is wrong... If you don't use a name that is different than another application, you will end up with that applications variables. Which is one reason why we always use the name of the website as the application name. Simple but easy to not duplicate. You're all coming up with reasonable workarounds, but Connie's point is that she shouldn't need workarounds... and  she's right!

My hosting company requires that the dsn name be the same as your domain name - seems to work. I followed suit with the Application name. > Right, but...  What if you chose a common name and someone on the same > server does the same.  Also, what if you need to test different versions > of > the same application on the same server?  Shouldn't sandboxing protect you > from that? >

> My hosting company requires that the dsn name be the same as your domain > name - seems to work. I followed suit with the Application name. That definitely makes it easy for any potential attackers to guess your DNS name.  I assume it's protected by a username and password you supply in your application? I would also point out that using that as your application name makes is very easy for someone to guess your application name and hijack your application scope. Sorry if I'm being a little paranoid about security issues, I've just been doing some threat modeling for the past few weeks and it's on my brain. -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell:  678.637.5072 aim:   cameroncf email: cameronc@mindspring.com

True, but frankly, the only kind of site I'd trust on a low-cost shared server is one that could get hacked and I wouldn't care.  :) ----- Excess quoted text cut - see Original Post for more -----

> My hosting company requires that the dsn name be the same as your domain > name - seems to work. I followed suit with the Application name. The only issue there is that whne you do that you may leaving yourself open for intentional snooping - I could write a page using the domain name as the app name and CFDUMP the application scope. If there's anything important there (DSN passwords for example) they're wide open. Jim Davis

> Right, but...  What if you chose a common name Don't do that :-).  As you've just discovered it creates a security weakness. I use variables.AppName="somename_" & variables.myDSNName & "_" & TimeFormat(CreateODBCTime(Now()),"HHmmss"); The above is part of an installer that writes an /Application.cfm to disk as part of the install routine.  I've also used UUIDs for this, but for the most part just appending the date and time to your application name is sufficient. I have my own servers but still I do a datasource similarly.  somename (not necessarily the url) & date+time. -- --mattRobertson-- Janitor, MSB Web Systems mysecretbase.com

But won't that create a new app name with every request? > Right, but...  What if you chose a common name Don't do that :-).  As you've just discovered it creates a security weakness. I use variables.AppName="somename_" & variables.myDSNName & "_" & TimeFormat(CreateODBCTime(Now()),"HHmmss"); The above is part of an installer that writes an /Application.cfm to disk as part of the install routine.  I've also used UUIDs for this, but for the most part just appending the date and time to your application name is sufficient. I have my own servers but still I do a datasource similarly.  somename (not necessarily the url) & date+time. -- --mattRobertson-- Janitor, MSB Web Systems mysecretbase.com

> But won't that create a new app name with every request? Nope.  That code comes from an installer that writes the /Application.cfm during an install.  It only runs once. No need to use a fancy installer though.  You can just as easily type this in yourself: myapp_20050422153000 And do something similar for the datasource name.  Easy PZ and problem solved. -- --mattRobertson-- Janitor, MSB Web Systems mysecretbase.com

> Right, but...  What if you chose a common name and someone on the same > server does the same.  Also, what if you need to test different versions > of > the same application on the same server?  Shouldn't sandboxing protect you > from that? This is exactly why you don't choose a common name. Mosh posted his code, mine looks like this: <cfscript>   // Set the application ID based as a hash of the directory structure DPApplication.AppID = "DP_" & Hash(GetCurrentTemplatePath());   // Add a "secret" value to the Application name to obfuscate the application name on shared servers DPApplication.AppIDSalt = "";   // Session Timeout DPApplication.SessionTimeout = CreateTimeSpan(0,0,20,0);   // Application Timeout DPApplication.ApplicationTimeout = CreateTimeSpan(2,0,0,0); </cfscript>   <!--- Set the application name and scope ---> <cfapplication   name="#DPApplication.AppID#_#DPApplication.AppIDSalt#"       sessionmanagement="Yes"       sessiontimeout="#DPApplication.SessionTimeout#"    applicationtimeout="#DPApplication.ApplicationTimeout#"       clientmanagement="No"       setclientcookies="Yes" /> Between the Hash directory name and the Salt (which I've left blank here - but you should fill in) I think you're pretty safe from both intentional and accidental snooping. This problem exists on ALL shared CF hosts - it's not unique to CrystalTech by a long shot. Jim Davis

Connie DeCinko wrote: > Right, but...  What if you chose a common name and someone on the same > server does the same.  Also, what if you need to test different versions of > the same application on the same server?  Shouldn't sandboxing protect you > from that? Sandboxes in CF 5 used to have that option, MX and later don't: http://www.macromedia.com/go/wish/ Jochem

Don't blame your bad coding practices on CrystalTech.  Of course two different applications with the same name are likely to cause conflict on a server...any server...even one that you own and have total control over, if you name two applications the same thing you will run into this. Pete

Pete Ruckelshaus wrote: > Don't blame your bad coding practices on CrystalTech. Where am I using bad coding practices? Where do I blame them on CrystalTech? Jochem

> Pete Ruckelshaus wrote: > > Don't blame your bad coding practices on CrystalTech. > > Where am I using bad coding practices? Where do I blame them on > CrystalTech? Down boy!  I don't think he was talking to you.  ;^) Jim Davis

No, even so, that is a major bug in ColdFusion and or sandboxing, or at least a problem with the configuration.  This means that someone could maliciously decide to hijack my site just because they are on the same box and guessed my application name.  Security should be #1 at any hosting price level.  Every site should be treated as if a virtual dedicated server. Don't blame your bad coding practices on CrystalTech.  Of course two different applications with the same name are likely to cause conflict on a server...any server...even one that you own and have total control over, if you name two applications the same thing you will run into this. Pete

> No, even so, that is a major bug in ColdFusion and or sandboxing, or at > least a problem with the configuration.  This means that someone could > maliciously decide to hijack my site just because they are on the same box > and guessed my application name.  Security should be #1 at any hosting > price > level.  Every site should be treated as if a virtual dedicated server. Then every site should cost $80/month. People on shared hosts accept the (still relatively small) risk of "hijacking" in exchange for paying sometimes a tenth of a what a real dedicated space (whether virtual or not) would cost. It's a trade of you make, pure and simple - and it has nothing to do with CrystalTech or CF or Windows or whatever.  The same problems occur when your sharing any resources, anyplace. Every site CAN'T be treated as a virtual dedicated server if you're sharing resources!  It just can't be - the only way to treat every site as a virtual dedicated server is to make every site a virtual dedicated server! So, to do that, CrystalTech (or any host) would have to accept that a box capable of serving, say, 100 shared accounts could now only serve perhaps 10-15.  The customer then needs to prepare for a cost hike to cover that. As far as it goes CrystalTech has (as far as I know) the absolute cheapest dedicated hosting plan I've seen: $80/month gets you an actual box, all your own.  It's not a great box, but it'll do for well over 99% of the sites out there.  Of course in that case you also have to provide your own ColdFusion license (or use BlueDragon). "Security" and "Cheap" just don't go together.  That being said CrytalTech, HostMySite and many other CF host still provide good (but nowhere near perfect) security configurations on their shared servers. There are still hosts where all you have to do to download other people's files is to go up a directory in FTP and pick from the smorgasbord. Jim Davis

> "Security" and "Cheap" just don't go together.  That being said CrytalTech, > HostMySite and many other CF host still provide good (but nowhere near > perfect) security configurations on their shared servers. I think that the key phrase here is "You get what you pay for, period".  Every day I see people who go with the cheapest option available and then moan and groan when the level of service isn't the same as the level of service you get from the highest priced option. I'm not just talking about ColdFusion hosting here, but if the shoe fits... -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell:  678.637.5072 aim:   cameroncf email: cameronc@mindspring.com

As someone who hosts with Crystaltech and has never had any problems, I think it's also important to point out that the problem being discussed here is not Crystaltech's "fault", this will affect every single person who uses a shared server, regardless of who hosts it. ----- Excess quoted text cut - see Original Post for more -----

> > I think that the key phrase here is "You get what you pay for, > As someone who hosts with Crystaltech and has never had any problems, > I think it's also important to point out that the problem being > discussed here is not Crystaltech's "fault", this will affect every > single person who uses a shared server, regardless of who hosts it. Getting what you pay for is definitely not anything specific to Crystaltech.  Any hosting company offering hosting at a low price level is going to put you on a shared server, and at a higher cost will [ut you on a dedicated server. -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell:  678.637.5072 aim:   cameroncf email: cameronc@mindspring.com

> No, even so, that is a major bug in ColdFusion and or sandboxing, or at > least a problem with the configuration. No, it's a feature of the underlying Java servlet platform. Go read the docs about how the underlying context works and you'll see that the security 'bug' is there, not in ColdFusion. -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood

Connie DeCinko wrote: > No, even so, that is a major bug in ColdFusion and or sandboxing, or at > least a problem with the configuration.  This means that someone could > maliciously decide to hijack my site just because they are on the same box > and guessed my application name. It is documented behaviour, so it is not a bug but a gotcha: "You can have multiple Application.cfc files, Application.cfm files, and cfapplication tags that use the same application name. In this case, all pages that have the same name share the same application settings and Application scope and can set and get all the variables in this scope." http://livedocs.macromedia.com/coldfusion/7/htmldocs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=ColdFusion_Documentation&file=00001111.htm#1165302 I think it would be neat if you could 'lock' applications and sessions so they can only be loaded after / during inclusion of the same application.cfc that ran the onApplication/SessionStart. In fact, I just suggested that to Macromedia: http://www.macromedia.com/go/wish/ Jochem

> Right, but...  What if you chose a common name and someone on > the same server does the same.  Also, what if you need to test > different versions of the same application on the same server? Live app name:  myaccount_blog Dev app name:   myaccount_blog_dev > Shouldn't sandboxing protect you from that? Yes, but you shouldn't assume.  Just like you wouldn't hard-code directory paths, you'd make they dynamic or at least easy to change ("wouldn't" doesn't also mean "don't", I had a fun experience a few years back where this "programmer god" had hard-coded paths in a PHP app to run on her server, so when she copied them to our server none of it would work!). -- Damien McKenna - Web Developer - Damien.McKenna@thelimucompany.com The Limu Company - http://www.thelimucompany.com/ - 407-804-1014 #include <stdjoke.h>

> Right, but...  What if you chose a common name and someone on > the same server does the same.  Also, what if you need to > test different versions of the same application on the same > server?  Shouldn't sandboxing protect you from that? No, I don't see how sandboxing would do that. Multiple CFMX instances would protect you from that, however. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

That could explain things.  CT has issues with multiple instances currently and AFAIK is still awaiting a patch from MM. Multiple CFMX instances would protect you from that, however. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/

Hashing your app name isn't going to protect you from others on a shared server from looking in on you: <!--- application tracker object ---> <cfset appObj = createObject("java","coldfusion.runtime.ApplicationScopeTracker")> <!--- get the enumeration of application keys ---> <cfset apps = appObj.getApplicationKeys()>     <!--- session tracker object ---> <cfset tracker = createObject("java", "coldfusion.runtime.SessionTracker")> <!--- while there are more applications in the enumeration ---> <cfloop condition="#apps.hasMoreElements()#"> <!--- get the app name ---> <cfset appname = apps.nextElement()> <!--- get the sessions for this app name ---> <cfset sessions = tracker.getSessionCollection(appname)> <!--- dump the sessions out ---> <cfdump var="#sessions#" label="#appname#"> </cfloop>   That code can be run by anyone on the server and you'll see the application name and the dump of ALL the sessions for that app.

Interesting, wasn't aware of that. Is there any way to guard against that kind of exploit, other than encrypting everything in application and session scope, which would be very inefficient and annoying? Dave Merrill ----- Excess quoted text cut - see Original Post for more -----

Dave Merrill wrote: > Interesting, wasn't aware of that. > > Is there any way to guard against that kind of exploit, other than > encrypting everything in application and session scope, which would be very > inefficient and annoying? Disabling createObject() and cfobject for Java objects in the Sandbox seems to do the trick (I have not seen any POC code to bypass that). Jochem

> Hashing your app name isn't going to protect you from others on a shared server from looking in on you: > > <!--- application tracker object ---> > <cfset appObj = createObject("java","coldfusion.runtime.ApplicationScopeTracker")> But sandbox security can turn that off... -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood

> Hashing your app name isn't going to protect you from others on a shared > server from looking in on you: It not hashing the app name - it's hashing the app DIRECTORY to get the name and then adding a secrete value to the end ("salt"). Using a hash of the directory ensures to a great degree of certainty that the name won't be accidentally used again.  Adding the salt attempts to ensure that nobody could guess the name easily just by knowing your application path. Jim Davis

Sorry - I didn't look at the attached code well enough (I just got up, yeah, I know it's one o'clock).  ;^) You're right - if the server allows access to the core Java Components this will work. Jim Davis ----- Excess quoted text cut - see Original Post for more -----

> Using a hash of the directory ensures to a great degree of certainty that > the name won't be accidentally used again.  Adding the salt attempts to > ensure that nobody could guess the name easily just by knowing your > application path. To be honest, if you're really that concerned about security, you should get yourself a dedicated server or at least a dedicated server instance - both of those prevent snooping into your application scope. Enterprise sandbox security helps prevent a number of vectors but if you have a determined hacker sharing your physical server, you're going to be at some degree of risk. You get what you pay for. -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood

----- Excess quoted text cut - see Original Post for more ----- Exactly as I've said before.  You should expect compromise when sharing - it's just that simple. But the point isn't to completely secure things - it's to secure things has best you can on the budget you have.  It's about mitigating risk, not eliminating it.  It's about, again as best you can with the resources, eliminating the chance for an honest mistake and reducing the chance of a dishonest attempt. Saying "get a dedicated server" is all well and good but a lot of people don't have the money.  So what can you do with your $20 a month? Jim Davis

> Exactly as I've said before.  You should expect compromise when sharing - > it's just that simple. Yes. > Saying "get a dedicated server" is all well and good but a lot of people > don't have the money.  So what can you do with your $20 a month? Right, and for $20 / month I don't believe people should expect the sorts of levels of security being discussed here. Running an ecommerce system that contains customer data and credit card information on a shared host is a helluva risk, in my opinion. I've had a sniff round the application scopes of some shared servers... it's pretty scary how many people seem to think it's OK to cache sensitive customer data in application scope! I think people just need to be aware of the risks when living on a shared host - and remember that these are not really ColdFusion-specific issues. JSP also has a shared application context, for example, and many other technologies allow far more access to the file system than could be considered wise. Security is a big, complex issue and good security typically costs $$$ (if not in purchase costs then in development costs). -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood

----- Excess quoted text cut - see Original Post for more ----- Well, yes, assuming that CFML code is your only route of attack. However, don't most shared hosting providers typically let you run all sorts of code other than CF? I think your best advice was what you said later in the thread - don't expect too much security on a shared server unless you're using server virtualization. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

It's not exactly true that "all sorts of code other than CF" have these sorts of problems in shared hosting environments. ASP.NET, for example, isolates every application from all the others just to avoid these problems. If you're running BlueDragon.NET, then your CFML inherits this application isolation so that multiple users can use the same CFAPPLICATION name without conflict. Also, with BlueDragon.NET, you don't have to turn off CFOBJECT to avoid security issues; again, this is because the underlying ASP.NET runtime insures that all applications are isolated from each other. It just so happens that I'm working on my CFUNITED presentation on exactly this topic right now:     http://www.cfunited.com/topics.cfm#168 Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com ----- Excess quoted text cut - see Original Post for more -----

> It's not exactly true that "all sorts of code other than CF" have these > sorts of problems in shared hosting environments. ASP.NET, for example, > isolates every application from all the others just to avoid these > problems. But even then shared hosting is still sharing something and is thus more risky.  Even if the application is completely segmented: no outside memory or file access (and as far as I know .NET doesn't segment file access out of the box) it's still using the same CPU, disk, bandwidth, system databases, etc. .NET in a shared environment doesn't have this particular issue, but it's still got issues with shared hosting. Jim Davis

I think that some people on the list are blowing this issue out of proportion as a "bug" when it's really just expected behavior (and always has been) for ColdFusion.  However, I don't think it would be a bad idea for Macromedia to examine this and other security issues for adjustment in future versions of ColdFusion. I'm not entirely familiar with the underlying memory management in CF, but it seems to me that if sandboxing protects disk access, it should probably protect memory space as well (if it can).  So far I have the impression that most of the security features in CF for shared hosting are reactionary in nature and not proactive. At the end of the day though, if you are dealing with data so sensitive that you have to be absolutely sure no-one else can access it, you simply need to have your own dedicated server.  Doing any less (in any language) is really short-changing your clients and/or customers on the level of security that they are very likely to expect you are providing for them. -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell:  678.637.5072 aim:   cameroncf email: cameronc@mindspring.com

My point exactly.  Sandboxing should also protect items in memory!  Shared hosting means sharing bandwidth, disk space, getting a slice of total memory, but should NEVER EVER EVER mean sharing variable scopes, memory space or anything that would allow the accidental or intentional sharing of DATA.  At the very least, this is poor design of Coldfusion. I'm not entirely familiar with the underlying memory management in CF, but it seems to me that if sandboxing protects disk access, it should probably protect memory space as well (if it can).

> My point exactly.  Sandboxing should also protect items in memory!  Shared > hosting means sharing bandwidth, disk space, getting a slice of total > memory, but should NEVER EVER EVER mean sharing variable scopes, memory > space or anything that would allow the accidental or intentional sharing > of > DATA.  At the very least, this is poor design of Coldfusion. No.  As Sean pointed out this has nothing to do with ColdFusion but rather with the J2EE environment it runs on. Even with that distinction made remember that CF was never designed to be hosted in a shared environment, period.  Hosts have figured out clever ways to do this with some security, but ALL official statements point to instance virtualization as the ONLY way to segment ColdFusion on the same hardware platform. To use your car analogy why are you paying for a compact and complaining that it seats six people uncomfortably?  Sure you can squeeze six people in but it was never designed to do that and you'll have compromises if you do. Jim Davis

Clarify for me, is it really the J2EE environment, or how Macromedia implements and builds on top of that environment?  And since the J2EE environment in this case is JRUN, do we again come back to a design flaw by Macromedia? As Sean pointed out this has nothing to do with ColdFusion but rather with the J2EE environment it runs on.

> Clarify for me, is it really the J2EE environment, or how Macromedia > implements and builds on top of that environment?  And since the J2EE > environment in this case is JRUN, do we again come back to a design flaw > by > Macromedia? It's the environment.  But the environment provides a solution: multiple, segmented instances of the J2EE environment - CF supports this and it is the recommended way to share resources. However this consumes significantly more resources than multiple apps on the same instance - so hosts that implement it charge more (I've seen anywhere from $50-$80 a month). Jim Davis

Actually, CT normally supports multiple instances for that price, but they had to stop due to MM acknowledge bugs that are causing stability issues. J2EE sessions were not timing out at the same rate as the CF sessions and we saw lots of errors about expired or invalid sessions.  We've been waiting several months for MM to issue a fix. However this consumes significantly more resources than multiple apps on the same instance - so hosts that implement it charge more (I've seen anywhere from $50-$80 a month). Jim Davis

> Actually, CT normally supports multiple instances for that price, but they > had to stop due to MM acknowledge bugs that are causing stability issues. > J2EE sessions were not timing out at the same rate as the CF sessions and > we > saw lots of errors about expired or invalid sessions.  We've been waiting > several months for MM to issue a fix. I don't remember CT offering multiple, segmented instances - but I could have missed it. Still - they also offer a true dedicated server for only $80/month (the cheapest I've seen).  Why not just go with that? Jim Davis

> remember that CF was never > designed to be hosted in a shared environment, period.   I want to thank Sean, and others, for pointing out the technical details of why this limitation exists. As someone who doesn't delve into the underpinnings, it's interesting to know what contributes to some of the engineering tradeoffs. Like Connie, I would like for this to not be an issue. I think Jim's comment above though is the bottom line. Thanks all. --- Kevin Graeme Cooperative Extension Technology Services University of Wisconsin-Extension

And how would it do that? My point exactly.  Sandboxing should also protect items in memory!  Shared hosting means sharing bandwidth, disk space, getting a slice of total memory, but should NEVER EVER EVER mean sharing variable scopes, memory space or anything that would allow the accidental or intentional sharing of DATA.  At the very least, this is poor design of Coldfusion. I'm not entirely familiar with the underlying memory management in CF, but it seems to me that if sandboxing protects disk access, it should probably protect memory space as well (if it can).

----- Excess quoted text cut - see Original Post for more ----- In defense of my words being twisted in support of other assertions. I don't really think that this represents poor design in ColdFusion, and definitely doesn't deserve all this banner waving and general freaking out.  It may be an undesirable behavior, but it's pretty common knowledge and expected behavior. This memory behavior has been consistant across every version of ColdFusion since the application scope was introduced.  Acting suprised and appaled about this issue only indicates a lack of experience.  However, that doesn't mean we can't suggest that a change in behavior be considered for future versions - or that a solution would be welcome. We've all done a pretty good job of describing the problem here, it may be a good idea to chill out a bit on the kicking and screaming and allow some folks to suggest some solutions.  Looks like Sean's suggested some other great options for helping solve the problem. -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell:  678.637.5072 aim:   cameroncf email: cameronc@mindspring.com

> My point exactly.  Sandboxing should also protect items in memory!  Shared > hosting means sharing bandwidth, disk space, getting a slice of total > memory, but should NEVER EVER EVER mean sharing variable scopes, memory > space or anything that would allow the accidental or intentional sharing of > DATA.  At the very least, this is poor design of Coldfusion. If you run multiple Java applications in a single JVM then they share memory BY DEFINITION. That's how Java works. Therefore all applications within a single J2EE server instance will be sharing memory. A "ColdFusion application" is really just a programming convention - it exists solely because you can associate a name with a request (not with pages - you can set the application name per request). All your "ColdFusion applications" execute in the context of the J2EE application that is ColdFusion itself. That means that the Servlet context is, again by definition, shared between all of your "ColdFusion applications" since they are all running in the same J2EE application context. If you are running ColdFusion Standard, you are running a single JVM by definition. If you are running ColdFusion Enterprise you can choose to run a single JVM or multiple JVMs. If you use multiple JVMs, i.e., multiple server instances, then each instance is physically separate which makes you more secure. In fact, even separate context root installations running on the same server instance do not share application scope (because each installation has its own application context). Therefore ColdFusion Enterprise could be installed multiple times in a single server instance and each installation would be separate from the others (although they will share a single JVM and therefore compete for the same heap etc). Perhaps you should petition your shared host to offer that setup? (Multiple installs within a single server instance, using one context root per customer website) -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood

> Perhaps you should petition your shared host to offer that setup? > (Multiple installs within a single server instance, using one context > root per customer website) I've just blogged a (fairly long) piece about this... -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood

> No, even so, that is a major bug in ColdFusion and or > sandboxing, or at least a problem with the configuration.   > This means that someone could maliciously decide to hijack my > site just because they are on the same box and guessed my > application name.  Security should be #1 at any hosting price > level.  Every site should be treated as if a virtual dedicated > server. That's absurd. Saying security should be first priority at any hosting price level is like saying every car should be just like a Mercedes no matter what you pay for it. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

So, you say that even a cheap car should not be considered safe?  I should not expect my $8,000 Chevy to have brakes that actually stop the car and headlights that work?  Don't expect basic safety for that price!  Hell, don't expect basic security as in door locks either!  Safety and security should be #1 at any price level for any service or product, web hosting included!!!  Low price is NO excuse for lazy installation/implementation or design. That's absurd. Saying security should be first priority at any hosting price level is like saying every car should be just like a Mercedes no matter what you pay for it. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/

----- Excess quoted text cut - see Original Post for more ----- I can see where you are coming from, believe me; but I do not think that hosting providers need to provide the same level of security for each customer. Going back to your car analogy above, think about it this way... When I bought my Mazda 6 I could have gotten the base model which at the very least meets the minimum safety requirements or I could have gotten to S3 package (or whatever they called it) which game me more airbags, roadside assistance during the warranty period, larger wheels/tires, better brakes (performance), and stiffer suspension. I opted for the S3 package because I live in the DC area and people can't drive, only me :-) so the added features were welcomed. Should everyone have the S3 package? Does my grandma who drives once a week need the S3 package? Should she pay for it if she doesn't "need" it or put herself into situations where it is needed? Of course she shouldn't. Just like not all web applications need a the same level of security thus paying for more is only reasonable. The tough thing in my opinion is that while my analogy talks about cars having minimum safety requirements, web applications do not... at least not any that can be enforced. Mike

----- Excess quoted text cut - see Original Post for more ----- You working in absolutes where none exist.  You can't talk about "no security" vrs "complete security" (the latter of which doesn't exist anyway). A cheaper SHOULD be considered "safe" - but it will NEVER be AS SAFE as a luxury car. Your cheap hosting account is MUCH SAFER than it could be, but not AS SAFE as a dedicated account by far. Quality of safety in cars is directly correlated to price, quality of security in hosting accounts also directly correlated to price. I'mnot sure how to say it any more clearly. Jim Davis

Right.  What it comes down to are an agreement on what MINIMUM levels of security are.  Isolation of disk space, memory, etc. should be minimum.  I don't feel Macromedia and most hosts, including CT are providing that today. It should be doable even on a shared host.  On top of that, you add encryption, SSL, hashed passwords, etc. etc.  Those are what takes your basic car to a luxury, nearly bullet proof car.  So, while I hate the statement, you get what you pay for, I think that even if you pay a dollar a month, there are certain minimums that must be met.  Where I have a problem is I see some things as required, while others feel you should only expect isolation on a dedicated server. You working in absolutes where none exist.  You can't talk about "no security" vrs "complete security" (the latter of which doesn't exist anyway). A cheaper SHOULD be considered "safe" - but it will NEVER be AS SAFE as a luxury car. Your cheap hosting account is MUCH SAFER than it could be, but not AS SAFE as a dedicated account by far. Quality of safety in cars is directly correlated to price, quality of security in hosting accounts also directly correlated to price. I'mnot sure how to say it any more clearly. Jim Davis

" However, I don't think it would be a bad idea for Macromedia to examine this and other security issues for adjustment in future versions of ColdFusion." Umm, I don't think Macromedia will be releasing anymore versions of ColdFusion................ I think that some people on the list are blowing this issue out of proportion as a "bug" when it's really just expected behavior (and always has been) for ColdFusion. However, I don't think it would be a bad idea for Macromedia to examine this and other security issues for adjustment in future versions of ColdFusion. I'm not entirely familiar with the underlying memory management in CF, but it seems to me that if sandboxing protects disk access, it should probably protect memory space as well (if it can). So far I have the impression that most of the security features in CF for shared hosting are reactionary in nature and not proactive. At the end of the day though, if you are dealing with data so sensitive that you have to be absolutely sure no-one else can access it, you simply need to have your own dedicated server. Doing any less (in any language) is really short-changing your clients and/or customers on the level of security that they are very likely to expect you are providing for them. -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell: 678.637.5072 aim: cameroncf email: cameronc@mindspring.com

>  Umm, I don't think Macromedia will be releasing anymore versions of ColdFusion Zzzzzzz........ -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell:  678.637.5072 aim:   cameroncf email: cameronc@mindspring.com

Yeah, but Adobe might. If they don't fire everyone on this list who works for them, there will be someone listening who can take on the feedback. Anyway, as for separating memory spaces, CF already does this; that's where separate instances come in via J2EE deployment. " However, I don't think it would be a bad idea for Macromedia to examine this and other security issues for adjustment in future versions of ColdFusion." Umm, I don't think Macromedia will be releasing anymore versions of ColdFusion................

> Yeah, but Adobe might. If they don't fire everyone on this list who works > for them, Yikes man that's messed up. Going through an acquisition is kind of stressful and there are quite a few MM guys on this list - maybe a little respect? I am going to start naming all my applications the exact same thing. -- ~Blog~ http://www.robrohan.com ~The cfml plug-in for eclipse~ http://cfeclipse.tigris.org ~open source xslt IDE~ http://treebeard.sourceforge.net

> Anyway, as for separating memory spaces, CF already does this; that's where > separate instances come in via J2EE deployment. Actually, instances do alot more than simply protect memory space.  I also was not suggesting seperate memory spaces but protected memory spaces.  Again, I'm not familiar at all with CF's internals in this area, and admittedly am not an expert in the least at memory management, but if CF can create a sandbox that says "only files from these directories can play here", it should also be able to say "applications created in this sandbox have to stay in this sandbox". -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell:  678.637.5072 aim:   cameroncf email: cameronc@mindspring.com

----- Excess quoted text cut - see Original Post for more ----- Well, first of all, when I said "all sorts" I simply meant it's a common problem, not that there aren't environments that are immune. You can run Perl or whatever within a chroot environment on Unix, and that would also be immune. However, these environments are the exception and not the rule, I suspect. That said, it's my understanding that ASP.NET does not automatically isolate applications the way you suggest. You can configure them to be isolated within the IIS management console by choosing the application isolation level in IIS 5 or the application pool in IIS 6, but I'm not sure what the default settings happen to be - on IIS 6, I think the "DefaultAppPool" is used by default, while on IIS 5 I think that "Medium" is the default application isolation level, which I believe will place more than one application within the same pool. In addition, on IIS 5 your ASP.NET applications run as LocalSystem by default, I think, so those applications have free run of the filesystem by default. On IIS 6 you can run them using a lower-privilege security context like NetworkSystem, but that's not the default setting. Now, I'm certainly no expert when it comes to ASP.NET security, so if I've made any errors, please let me know. But in any case, running separate ASP.NET application pools is about the same thing as running separate instances of CFMX within separate JRun servers, as far as I can tell, although presumably the memory consumption of a single ASP.NET application is probably much smaller than the memory consumption of a single CFMX instance. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

You're confusing application isolation with process isolation. Yes, ASP.NET runs all applications within the same process by default; however, it does isolate the applications within that process as I describe. It's a very simple matter of configuration to add process isolation in ASP.NET by assigning applications to different process pools; and yes, the memory consumption of additional ASP.NET processes is much less than addition CFMX instances. The default setting on IIS 6.0 is to run ASP.NET processes as a user with lower security privileges than LocalSystem, so that's another advantage of ASP.NET (and BlueDragon.NET) over CFMX or the Java/J2EE editions of BlueDragon. Again, I'm presenting a talk a CFUNITED that covers all of these topics (the talk is specifically focused on Windows Server 2003 and IIS 6.0, so some of the points you bring up about IIS 5.0 won't be covered). Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com ----- Excess quoted text cut - see Original Post for more -----

----- Excess quoted text cut - see Original Post for more ----- This simply isn't the case with anything. Safety and security are hardly ever the first concerns of, well, anyone. With security, just like with anything else, you get what you pay for. If you have shared hosting, you're not paying for security or safety, and any that you get is simply a happy coincidence. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

If that wasn't the case you have the chance to die in a car-crash, I have never seen ColdFusion developers die of a software-crash. If so, we would have entire software developer cemeteries all over the world. In short, you are comparing apples and oranges. Micha Schopman Project Manager Modern Media, Databankweg 12 M, 3821 AL  Amersfoort Tel 033-4535377, Fax 033-4535388 KvK Amersfoort 39081679, Rabo 39.48.05.380 ------------------------------------------------------------------------ ---- ----- Excess quoted text cut - see Original Post for more -----

"you get what you pay for" didn't become a universally recognized axiom by accident, or because it was catchy. Generally speaking the cheaper something is the crappier it is.  Its not brain surgery to figure this out for crying out loud. -- --mattRobertson-- Janitor, MSB Web Systems mysecretbase.com

Oh give me a break!  What a crock! "you get what you pay for" didn't become a universally recognized axiom by accident, or because it was catchy. Generally speaking the cheaper something is the crappier it is.  Its not brain surgery to figure this out for crying out loud. -- --mattRobertson-- Janitor, MSB Web Systems mysecretbase.com

> Oh give me a break!  What a crock! > Would you like some cheese with your whine? I think that now that you're getting snotty I'll take a moment to point out that this whole thread -- which has a title that slanders a commercial entity unfairly -- has nothing to do with that entity and everything to do with your chosen coding practices.  You made a mistake.  Deal with it. Haven't we whipped this horse to death?  If there's any more boo-hoo-I-wanna-ice-cream kind of posts necessary shouldn't they be in CF-Community at this point? -- --mattRobertson-- Janitor, MSB Web Systems mysecretbase.com

Bless you, Matt. ----- Excess quoted text cut - see Original Post for more -----

Remind me never to hire either of you clowns who have no concept of security or reality. Bless you, Matt. ----- Excess quoted text cut - see Original Post for more -----

Clowns? Wow...ouch...that hurts. Think about that stinging barb long? Hate CrystalTech? Switch hosts. Think ColdFusion lacks in decent security options? Switch application servers. But stop your unrealisitc and belligerent whining. And I hate to break this to you, but if anyone on this thread has made people's "do not hire list", it is you. ----- Excess quoted text cut - see Original Post for more -----

I think maybe we need to get Will's cuss_checker CFC and add "crystaltech" to the banned words list. I'm not often one to say this, but can we please move on? J ----- Excess quoted text cut - see Original Post for more ----- -- --------------- ------------------------------------- Buy SQLSurveyor! http://www.web-relevant.com/sqlsurveyor Never make your developers open Enterprise Manager again.

I personally *despise* the axiom "you get what you pay for".  If that's the case, I'll sell you this application for $1,000,000. The *correct* axiom should be "you get what you make an informed decision on": if you have done your research and made an informed decision then the price is irrelevant.  If I research the options and decide a $100 application is best for me then why should I buy a competing one for $1000 just because it costs more? -- Damien McKenna - Web Developer - Damien.McKenna@thelimucompany.com The Limu Company - http://www.thelimucompany.com/ - 407-804-1014 #include <stdjoke.h>

you make an 'informed decision' based on the level of quality that you need vis a vis the price you can afford :) ----- Excess quoted text cut - see Original Post for more -----

> I personally *despise* the axiom "you get what you pay for".  If that's > the case, I'll sell you this application for $1,000,000. Cool, then I expect it to do the same things as Amazon.com... ...because I expect to get what I pay for. -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell:  678.637.5072 aim:   cameroncf email: cameronc@mindspring.com

----- Excess quoted text cut - see Original Post for more ----- I think you're missing the point of said axiom, then. No one is saying, "buy the most expensive thing", we're just pointing out a general correlation between cost and value. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

CFMX Standard, I can not get the missing template handler to work.  I have one on our current site which is CFMX Enterprise, but I can't find anything that this should matter.  I have tried absolute paths, relative paths and everything in between.  I can get it to work by using IIS to replace the 404 page, but CF does not execute when you do this.  Has anyone run into this before???  I am going out of my mind, what little is left. Christian

> Remind me never to hire either of you clowns who have no > concept of security or reality. Don't take this the wrong way, but if you really think you should be entitled to the same security with a shared server as you'd get on your own dedicated server, I've got a pair of red size 26 EEEEEs just for you. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

> Don't take this the wrong way, but if you really think you should be > entitled to the same security with a shared server as you'd get on your > own > dedicated server, I've got a pair of red size 26 EEEEEs just for you. ROFLMFAO!! Dave...I've been on this list for years...and your replies are generally succinct and well thought out...but when you don't hold back it's pure gold ;-) That just made my whoile week!! Bryan Stevenson B.Comm. VP & Director of E-Commerce Development Electric Edge Systems Group Inc. phone: 250.480.0642 fax: 250.480.1264 cell: 250.920.8830 e-mail: bryan@electricedgesystems.com web: www.electricedgesystems.com

Dave, stop.  Stop Dave.  Dave...  Please stop.  If I laugh any harder I will need an ambulance, Dave. --HAL--

As I keep saying and apparently no one is listening...  I expect the same BASIC security on a shared host.  With no sandboxing of memory, that is the same as NO security.  Does everyone hear me now??  I don't expect the same level.  I do expect more than just sandboxing of disk space.  More than I have repeated this same statement. This thread is done, finished, over and out.  I've made my point.  I am sick of the crap of price meaning you have to put up with lousy service and features that should be there in a basic plan.  This is not a $1 per month plan.  This is a middle of the road plan that should be providing AT LEAST A BASIC LEVEL OF SECURITY!  Currently with the lack of J2EE sessions, it does not.  For this I have both CrystalTech and Macromedia to blame. MODERATOR, PLEASE LOCK THIS THREAD, THROW IT TO CF-COMMUNITY, WHATEVER!  MY POINT HAS BEEN MADE!!!!!! > Remind me never to hire either of you clowns who have no > concept of security or reality. Don't take this the wrong way, but if you really think you should be entitled to the same security with a shared server as you'd get on your own dedicated server, I've got a pair of red size 26 EEEEEs just for you. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/

Connie DeCinko wrote: > As I keep saying and apparently no one is listening...  I expect the same > BASIC security on a shared host.  With no sandboxing of memory, that is the > same as NO security. It is called "keeping honest people honest". > I do expect more than just sandboxing of disk space. You can get Sandboxing of OSI layer 3 and 4 too :) Jochem

> As I keep saying and apparently no one is listening...  I expect the same > BASIC security on a shared host.  With no sandboxing of memory, that is the > same as NO security.  Does everyone hear me now?? We heard you the first time. And clearly we all think you have unrealistic expectations. > MODERATOR, PLEASE LOCK THIS THREAD, THROW IT TO CF-COMMUNITY, WHATEVER!  MY > POINT HAS BEEN MADE!!!!!! No, that would give you the last word... and where would be the fun in that? :) -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood

> MODERATOR, PLEASE LOCK THIS THREAD, THROW IT TO >CF-COMMUNITY, WHATEVER!  MY > POINT HAS BEEN MADE!!!!!! I think there is a number you can call to turn someone in. The BSA (BS Software Alliance) may be interested in your plight. Someone needs to pay for these egregious violations! 1-800-IGO-TPMS

> dedicated server, I've got a pair of red size 26 EEEEEs just for you. If I buy two pairs, do I get a free red nose that goes *HONK*?  I've got a wedding in a few days. Joe -- Get Glued! The Model-Glue ColdFusion Framework http://www.model-glue.com

----- Excess quoted text cut - see Original Post for more ----- I'm not sure what you mean by a basic level of security. I can tell you that configuring security such that one developer can't affect another on the same machine is a hard, non-trivial problem, requiring quite a bit of attention to detail and limiting what developers can do within their own space. It's as simple as that, and I wouldn't want to be the one to guarantee to someone else that their application and its data was secure within a shared environment. Sandbox security uses directories to figure out how to restrict things, while CF applications are not bound by the filesystem - I can have ten different directories, with separate virtual web servers pointing to each, and still use the same CFAPPLICATION name in all of them, and that's one application! Given that, how could sandboxes possibly affect application memory variables? I don't think this is anything new with CFMX, either. In any case, if you want to isolate your code from my code, they can't be run within the same service, because my code could potentially make that service do something that it shouldn't be able to do, so at that point you're talking about separate services running with separate credentials. Considering that each JRun server has a minimum memory footprint of about 40 MB, you can't run too many of them on the same machine. Resources cost money, so you should expect to pay more for that level of isolation. I'm not sure what the lack of J2EE sessions has to do with any of this, either. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!