> >But with JSP enabled I am broadcasting my username and password to >everyone on the server, as they can read my code. >
Right - I was just trying to clarify that there were two separate issues at hand there. The JSP one is definitely an issue; datasources on the other hand run more to personal preference. Assuming that the JSP issue is resolved, the datasource problem is effectively solved as well. >As dave suggested, a slight reorganisation of servers (or even instances >on the same server) such that some run JSP and some don't would suffice. >Customers needing JSP can take their chances on those servers and those >who want some security can have the servers wherein it is disabled. > That's being considered as one alternative, but I'd personally like to avoid it if at all possible as it leads to complications on our end. This shouldn't be seen as laziness, it's just a reality - the more complex the backend is the more likely it is that there will be an issue of some sort when it comes time to update the servers. Or having to explain to a novice JSP user why this stuff is insecure <shudder>. I'd rather have it running and locked down permanently. Plus the idea of knowingly putting up a server with a gaping hole in security turns my stomach a little. >For a shared host, the best CF security involves turning off JSP, >disabling CFOBJECT and createobject() for all customers and sandboxing >files for every app to allow access to only the account directory. If >you can provide some servers with this config (secure hosting servers) >and others with the more relaxed JSP option, you take care of both sets >of needs and I stop whining like a child. CFObject is insecure in v5.0, but with the advent of sandboxes I believe it was deemed safe in MX versions. If you believe I'm mistaken on that point please let me know. Currently our server config only disallows use of CFExecute and CFRegistry, both for fairly obvious reasons. Also RDS is disabled, but that should be given as well. Sandboxing isn't quite as simple as you make it out to be - it's not enough to simply have access restricted to the webroot. You also need to implement a host of other directories that CF needs access to for various reasons. Here's an example from one of our servers running MX 7.0 c:\websites\DOMAIN_NAME\ Read,Write,Execute,Delete c:\websites\DOMAIN_NAME\- Read,Write,Execute,Delete c:\cfusionmx7\lib\updates Read c:\cfusionmx7\lib\updates\- Read c:\cfusionmx7\lib\cfxneo.dll Read c:\cfusionmx7\runtime\servers\coldfusion\SERVER-INF\temp\wwwroot-tmp Read c:\cfusionmx7\runtime\servers\coldfusion\SERVER-INF\temp\wwwroot-tmp\- Read c:\cfusionmx7\customtags\ Read,Execute c:\cfusionmx7\customtags\- Read,Execute c:\cfusionmx7\cfx\ Read c:\cfusionmx7\cfx\- Read c:\cfusionmx7\wwwroot\cfide Read c:\cfusionmx7\wwwroot\cfide\- Read c:\CFusionMX7\lib\vadmin.jar Read c:\CFusionMX7\lib\verity.jar Read And this is just a server that started out as v7. You should see one of the ones that was upgraded from v6.1. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:207117 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
