In production your db shouldn't allow any client tools to connect, however even if the user does connect to your db, they still have the same restrictions. They can only do/see what you've allowed for that role.
My issue with <cfquery> is that you are exposing your db design. It's alot harder to hack a db is you dont know the table and column names.
With <cfstoredproc> all you are expsoing in the code is the procedure name and the types of arguments it takes. Whats actually going on in the db, is completely hidden.
As for encrypting the fuseaction, the question is why not? Users can start throwing errors by trying different fuseaction calls. Which in turn could expose too much info if you dont have a site wide error handler. The topic of this thread is securing cf apps. Although it may not be 100% necessary, it sure doesn't hurt. (minimal processing increase aside)
-adam
> -----Original Message-----
> From: Matt Liotta [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 23, 2004 04:47 PM
> To: 'CF-Talk'
> Subject: Re: Securing CF Apps.
>
> > my datasources are locked down in CFIDE to only allow stored procedure
> > calls.
> >
> That doesn't sound very locked down. Why didn't you do that at the
> database user level? Doing it with CF is not even close to as secure as
> doing it with the database.
>
> Oh and the other part about cfquery being insecure is just plain
> foolish. Certainly cfquery can be a security problem, but then again so
> can cfstoredproc. It all depends on how you use them.
>
> -Matt
>
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
