(re: Fusebox as security provider)
> First off this is mis-stated. One of the appealing points of
> fusebox is that you can lock down all of those function and
> object tags (whoops did I say objects?) with only 3 lines of
> code in your application.cfm. That is, if the request is not
> coming from index.cfm, then send them to index.cfm. So you can
> htr or ::DATA$ me all you want and all you are going to see is
> an index page which paths to a bunch of templates/modules that
> you are never going to access unless you do it the way my logic
> provides. By this, I mean if you see a tag call or path to some
> template, you are never going to be able to call that template
> by itself. So if you figure out that my order processing is done
> on act_process_order.cfm, and you try calling that template by
> itself through the browser with a .htr or ::DATA$, application.cfm
> is going to see that the request is not coming from index.cfm and
> send you to the front of my website or wherever it is that I
> choose to send you. So its not "You can call any template
> from a browser", rather it prohibits this. This, is in fact a
> different means of your current goal. Its just easier to implement.
Without getting into another discussion of the merits of Fusebox as an
application development methodology, I have to point out that it doesn't
provide any additional security for your application.
The two exploits that you list above, both IIS-specific, rely on the
behavior of the web server to retrieve files before those files are
processed by the CF server. This happens before any CF code is run, so
application.cfm won't redirect the user. So, on a server with either of
those two security holes, if I specifically request the appropriate CF file,
no matter where it's buried withing the document root of the web server, IIS
will retrieve the file and show me the source code. If I wanted to
compromise the source code on a site using Fusebox, I could simply view the
source code of the index page, read the CFINCLUDE tags, then request to view
the source code of those included files. Trust me on this - or better yet,
test it yourself.
A better security solution is to make sure that source code can't be viewed
from the browser. There are several ways you can make this happen:
1. Close all known security holes (a leap into the obvious).
2. Remove unnecessary functionality.
As an example, the .htr exploit can only be used against a server if that
server is still configured to map .htr to an ISAPI extension. On the servers
that we administer (thankfully, very few servers), we'd removed that mapping
before the exploit was public knowledge, since we didn't want to use the
functionality that it provided. This is a standard part of IIS configuration
best practices as described by Microsoft - don't leave it on if you aren't
going to use it.
3. Use NT security.
The CF server needs execute permissions. The IIS user needs to be able to
check file permissions. That's really all you need to enable. Note the lack
of "read" permissions for the IIS user. If you configure your server with a
minimal set of permissions, source code reading exploits will fail.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
