DO NOT store usernames or passwords in or trust your application variables as they can be accessed by other websites on the same server instance. Many ColdFusion developers will read this bold warning as old news but unfortunately many more are not aware of the problem and are storing very dangerous information like database, email or admin usernames and passwords within the application scope and leaving their databases & sites open to attack. Thanks to a recent comment (thanks Bradley) we have been reminded that it's time again to get this warning out there.

The Problem:
Because of a feature in ColdFusion available since the move to j2ee, it is possible to use an unamed application to access the names and variables of all applications running on a server instance. With the application name known it's then also possible for script on the server but outside of your site to access and modify your application variables. This is possible because the ColdFusion application maps to an attribute in the J2EE application servlet context. Unamed applications correspond directly to the ColdFusion J2EE servlet context and you can only have one (shared) servlet context per server.

Along with the security risk of exposing usernames, passwords etc there is also the real danger of cross site scripting attacks being injected into cached content stored in the Application.

Versions 6, 7 & 8 of the server seem to be affected and according to the reference for ColdFusion 9 beta it appears this feature remains the same as 8 and will expose the same vulnerability for shared hosting. Obviously this is a major concern for any ColdFusion developer working on a website within a shared hosting environment.

Fix/Workaround:
We are not aware of any way to disable the using of an unamed application on the server but we reccomend the following:
For Developers:

• ensure you do not store any sensitive information within the application scope
• use the request scope for persisting DSN's, usernames or password information
• ensure you filter any application variables for possible cross site scripting before outputing them
  

For Server Administrators:

• inform your clients/developers of the dangers of storing data in the application scope
• scan the application variables contained within the ServletContext for username or passwords and notify the developers

Please note that although the script for scanning and accessing the applications on a cf server is very simple, we won't be posting it here for fear of incouraging attacks on shared hosting servers. We are happy to provide the script to any ColdFusion hosting providers so they can help scan their servers for exposed sites. So please email us if you are a hosting support or server administrator from a known CF host and would like a copy.

Help by voting for this issue:
We would ask everyone to make use of the new public Adobe CF bug tracker available and show Adobe that this is a serious security issue that needs to be addressed. Sean Corfield has already submitted a bug for it (72072) which you can add your vote for it to be fixed here.

References:

• Adobe ColdFusion 9 bug report for this issue
• CF8 Docs: Interoperating with JSP pages and servlets

Comments

Justin Hyland wrote on 07/24/09 7:04 PM

Thanks for the alert, is this also the case for servers running coldfusion enterprise and using sandboxing?

Brent wrote on 07/26/09 10:31 AM

@Justin,
This would work just the same on Enterprise with sandboxes, assuming every site is running in the same instance (jrun.exe process).

Joanna (coldfusion hosting girl) wrote on 07/30/09 9:59 PM

Thanks for the detailed post on this coldfusion shared hosting problem.

pass drug test marijuana wrote on 11/05/09 9:22 PM

I subscribed to your blog when is the next post

SEO wrote on 11/16/09 6:59 PM

Do u know any ebook for coldfusion programming?

Computer Services Baltimore wrote on 11/19/09 10:49 PM

I needed this info thanks mate

Regards

john wayne autobiography wrote on 11/30/09 10:08 PM

I will bookmark and continue reading your blog in the future! Thanks alot for the informative post!



Regards

resin flooring wrote on 11/30/09 10:14 PM

Thanks for such a nice post.

Regards

Jeff wrote on 02/11/10 3:14 PM

What about encrypting the application variables using the encrypt function? Then decrypting when you need the variable.

Not a fix to the security hole. But wouldn't it make it rather difficult for a hacker to decrypt/figure out the application variable?

Post a comment