I'm not sure what bank you are talking about, but I was able to do the same thing on First Union's (now Wachovia) site. However, they could have eliminated that with cferror. IMO a user should never ever see the cold fusion error. 1) It's an aesthetic nightmare 2) the user doesnt need to know what caused the error 3) security.
As for the database thing:
Say you are using Oracle. Rather than build your own user tables for each database, you can use Oracles built in user system. There are a number of benefits, such as creating profiles for password standards and account expiration and lockouts. IMO the best part is the security. You create an oracle user for each user of your application, then you assign them oracle roles for you application. So now oracle handles your applications users and roles. Then you can lock down each role with permissions. Say you have a view_only role. That role will only be assigned permission to SELECT on tables. I can get much more grandular that too, but I think you can get the idea.
So now that your db is handling users and roles you pass this username/password with every db call. So if your sever is ever comprimised, neither the code or CFIDE will expose your dbs security.
Additionally, everything should be in stored procedures. This will save you alot of time when setting up roles, and make them easier to manage. You can give the roles permission to access packages, rather than individual tables. Finally go into the CFIDE and on your datasource disable everything but stored procedure calls. You shouldn't have any SQL in your CF code. Again if that code is comprimised, or a error blows up and display lines, no one will have a clue to your db schema design.
-adam
> -----Original Message-----
> From: Tangorre, Michael [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 23, 2004 02:19 PM
> To: 'CF-Talk'
> Subject: RE: Securing CF Apps.
>
> > I think the most important thing to do is lock down the
> > server before worrying about code. That's usually where
> > most attacks will focus. A few simple things you can do:
>
> I would agree that it is important, however protecting the code and its
> ability to be manipulated is just as important. After a coworker showed me a
> popular bank website that passed a lot of information in the URL, I got
> playing around with it while logged in and was able to change the look and
> feel, get the app to error out and expose information to me such as table
> names and column names via the SQL error page, etc... This is not some
> lesser known bank, this is a popular bank which shocked me.
>
> > Break out the CFIDE from your server's web root and create
> > another site for it. Then lock down that site with
> > permissions from the web server to the file system.
>
> That's a given for us here.
>
> > Don't store username and password in the CFIDE. Pass it
> > through with your code on each call. You can even go as far
> > as integrate your database server's users/roles directly into
> > your application.
>
> What do you mean here?
>
> I am really interested in people's approach assuming the servers are already
> locked down properly (wouldn't that be nice!). The fact remains that we all
> pass parameters in the URL, forms, cookies, session vars, etc and this is
> what I was really trying to focus on.
>
> Mike
>
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
