S, I'd like to find out how insecure. Can you forward the code?
_____________________
Derrick Peavy
derr...@derrickpeavy.com
404-786-5036
_____________________
On Jul 10, 2009, at 1:43 PM, shawn gorrell wrote:
Clarke,
Welcome to the big leagues. I know that you might want to stay away
from that stuff, but if you want to be an uber-developer, you really
need to know that stuff inside and out. Network and server
administrators are unlikely to learn CF config at any level of
depth, so you need to be the resource to help them out and protect
your customers.
If your host is allowing CFEXECUTE to all customers, I'd find
another host. There are times when it may be the only solution to a
very specific usage scenario, but a good rule of thumb is to shut it
off as a policy unless someone can make the specific case not to. If
someone does make the case, you are better off to sandbox that
specific piece of functionality on its own, and contain it tightly.
As far as sandboxing, it is better to lock it down as hard as you
can. Your default position should always be to be less permissive
than more permissive. If you find out that you are blocking things
that you need, it's easy enough to open it up a little more until
you find exactly the settings you need. If you err in the other
direction and you get exploited, you're just hosed.
Let me give you a for-instance about sandboxing. One of the things
you can sandbox is DSN's. In a shared environment, would you want
anyone on that server to be able to find out about your DSN and
access your data? Or would you prefer that each sandbox has only the
DSN's that it is allowed to see and access? Seems pretty common-
sense to me.
If you want to find out exactly how insecure your shared host is,
I've got some code that I could give you. You could have some great
fun finding out all sorts of interesting and uninteresting things
about the server and all of the applications and databases
(including all of the data in their databases) it hosts, all in a
completely non-threatening way;)
Cheers,
S
From: Clarke Bishop <cbis...@resultantsys.com>
To: discussion@acfug.org
Sent: Friday, July 10, 2009 10:45:22 AM
Subject: [ACFUG Discuss] cfexecute, shared hosting, and security
I realize that all developers have a role in application security
(cfqueryparam, etc.). So, there definitely are things I have to pay
attention to in building an application.
But for server-level administration and security issues, I would
personally
like to stay away as much as I can!
While debugging my database connection problem the other day, I
discovered
that the host has cfexecute enabled. It is CF Enterprise, but I
don't know
if sandbox security really helps this problem. Please let me know
your ideas
for how serious a problem this is. I wish there was an independent
group
that evaluated and certified hosting providers -- It's really hard
to know
who's good and who's not!
---------
I found this on the web at
http://jochem.vandieten.net/2008/12/09/cf-shared-hosting-security-java-cfexe
cute-com-net-and-java-again/
So the hoster is left with a hard choice: disable CFEXECUTE, CFOBJECT,
CreateObject(.NET), CreateObject(COM) and CreateObject(JAVA) or
accept that
there is no security whatsoever in the shared hosting configuration.
If you
disable these tags a lot of applications and frameworks won't work
anymore.
For instance Transfer ORM needs Java access, so any application
build on top
of it will not work in a secured shared hosting environment.
---------
My application is the front end to a shopping cart (like a product
configurator). The actual transaction with credit card information
happens
on a totally different server. The data I'm actually keeping
wouldn't be
very interesting for a hacker.
My philosophy on security is that it's all about striking the right
balance.
You can lock things down so tightly that using the system becomes
difficult
and expensive. Or, you can be too open. I'm having a hard time
figuring out
the right balance.
Thanks for your comments!
Clarke
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------
