Oct 3
I recently posted the following on CFGURU and it was suggested that I blog it, so here it is.
When using the Sandbox Security in ColdFusion MX Enterprise Edition there are several things you need to take into consideration when securing your environment.
- You should have a default sandbox for the the folder that contains all your sites, with all tags/functions disabled that provide any kind of file system access
E.G. d:\wwwroot
You may also want to consider totally removing CFEXECUTE and CFREGISTRY form the server so that they cannot be used period. See my related blog entry for details on how to do this.
The tags/Functions I disable by default are:-- CFFILE
- CFDIRECTORY
- CFREGISTRY
- CFEXECUTE
- CFPOP
- CFMAIL
- CFLDAP
- CFCONTENT
- CFDOCUMENT
- CFFTP
- CFHTTP
- CFOBJECT
- CreateObject() on CFMX6 and CreateObject(JAVA) on CFMX7
- GetProfileString()
- SetProfileString()
- For CFFILE uploads, every sandbox needs to explicity allow access to the temp folder
E.G.
C:\CFusionMX7\runtime\servers\coldfusion\SERVER-INF\temp\wwwroot-tmp\
C:\CFusionMX7\runtime\servers\coldfusion\SERVER-INF\temp\wwwroot-tmp\-
creating a default sandbox at the root of all your websites and giving that access to the temp folder does not work. - The same applies to c:\windows\fonts folder when using cfdocument if you have specified ANY font name anywhere in the document then you need to have this path explicily allowed in the sandbox for that site.
- When using MYSQL DSN's, you sometimes need to explicity allow the IP:PORT of the MYSQL server in the sandbox. This is a random issue and does not occur all the time, so is perhaps a bug.
- Sandboxes do not apply when calling a CFC as a web service.
- Sometimes sandboxes just do not work, and you will need to delete it and re-create, sometimes more than once.
- Sometimes sandboxes become corrupted and will stop working, you must delete and re-create.
A common error with corrupted sandboxes is that you will find that you can no longer enable sessions in your application.cfm, and you will get an access denied message for www.mydomain.com - When CF tries to find a CFC in any custom tag path, it will fail with an "access denied" error for the custom tags path when you have sandboxes in place. CF will randomly try to find CFC's in custom tag paths if your not using a mapping to invoke your CFC or the CFC is not in the same folder as the calling template.
- Sandboxes do not work by default in a J2EE or multi-server install. You must explicitly enable them by modifying the jvm.config and ideally having a separate jvm.config for each instance otherwise you can only tell each instance to use the neo-security file for one particular instance. (see related blog entry)
- As you know CF will search all the way up to the directory tree for an application.cfm file, if you have an application.cfm above the folder that is sandboxed, it will not execute.
- If you call a custom tag in the custom tags folder, it will not obey the rules of the sandbox of the site that called it, I.E. it will have FULL access to all paths. (nb: this may have changed since CFMX 6)
- Sandboxes do not apply to CFX tags.
- Sandboxes to not apply to Java, if CreateObject(java) is enabled, you can do anything. even if CreateObject(java) is not enabled, you can create a JWS file and call it as a web service.
Oct 3, 2006 at 2:17 PM This is great information. Sandboxing is one of those features of CF that really take time to figure out, but this really helps to sort it all out.
Nov 8, 2006 at 6:05 PM It appears custom tags with MX 7.0.2 obey the sandbox rules of the site that called it. I wish it didn't because we have a cf_file custom tag that calls cffile because we set restrictions on where users can upload files. This is easier than having to create separate sandboxes for each site that wants to use cffile.