Comments on: CF shared hosting security: Java, CFEXECUTE, COM, .NET and Java again

By: “it could be bunnies” » Blog Archive » ColdFusion shared hosting security and internals

Mon, 15 Dec 2008 12:43:41 +0000

[...] far we have seen that to secure our shared hosting customers from each other we need to place them in a Sandbox [...]

By: Jochem

Jochem — Thu, 11 Dec 2008 08:34:17 +0000

I started this post writing what?

If you want to know about the security of a specific server nothing is stopping you from doing a little investigating yourself. At the very least you have the code samples and explanations from this post (more in the installment). Just try to get to a command prompt, some *.xml file in the /cfusion/lib folder, some database that is not yours etc. The best resource for understanding the underlying security model of Java is probably the Java Security Architecture specification and the rest is up to your imagination.

By: Sebastiaan

Sebastiaan — Wed, 10 Dec 2008 15:12:44 +0000

But, you started this post by saying Webstekker is bad for Shared CF Hosting - does this mean that all the baddies you mention in your posts are present on the Webstekker servers? How has Webstekker responded to your claims?

By: Jochem

Jochem — Wed, 10 Dec 2008 14:51:43 +0000

I didn’t list CreateObject(COMPONENT) as being a problem because it isn’t. There are no security risks associated with enabling CFCs. And even if CreateObject() was disabled for components, then you would still be able to use them through CFINVOKE like we did in the CF MX days (just return this from the init method).

By: Sebastiaan

Sebastiaan — Wed, 10 Dec 2008 12:12:23 +0000

But…, nu CreateObject(), then no CF7 or 8 code (as no CFC’s). So CF and Shared Hosting is NEVER a good option, that’s your bottomline!