I've been setting mine in the ODBC connection. I've seen so many holes
in IIS that allows you to read a cfm page, i'll never put my
username/password in the code.
You could always setup the CF administrator so it only is accessible
from 127.0.0.1, that way someone has to be physically at the computer to
access the ODBC connections, AND they have to know the password to get
into the admin, and even after that, they wouldn't have direct access to
the password of the connection.
I'm pretty sure that's stored in the registry, which offers another
interesting issue. Make sure you turn off the "remote registry", i
imagine there could be a security hole there.
Steve
Marc Funaro wrote:
>
> DaveD,
>
> Where should one set the usernames and passwords for databases -- in the
> ODBC connection on CF Server? I thought that was a security risk too...
>
> Always felt a little uninformed on this -- I welcome clarification!
>
> Thanks for the update and info!
>
> Marc
>
> -----Original Message-----
> From: daved [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 30, 2001 12:57 PM
> To: Fusebox
> Subject: Security Warning Update
>
> I know this security warning was posted back in May of 2000 but I think it
> needs to be readdressed.
> After installing the "+.htr" patch on our NT4.0 server back in May,
> everything was good.However; in January 2001 we upgraded to Windows 2000
> server and IIS5. At the time I wasn't thinking of going back an reviewing
> old patches. You'd assume these would be fixed in new releases or service
> packs. I was wrong and the +.htr problem still exists and when migrating
> your server to Windows2000, you'll need to reapply the patch. Everyone who
> has upgraded should check their site. I've noticed quite a few sites that
> still have this hole.
>
> Other things I've noticed and would like to comment on:
> a.. Don't supply usernames and passwords to databases (or anything) in
> your code because if your code does get exposed, these will be available to
> the world.
> b.. Don't rely on cfencrypt to secure your code because there are decrypt
> utilities available.
> c.. Don't allow for "free" input into your cfqueries, validate user input.
> d.. Check for referrer in action type forms. IE: I have a login.cfm page
> that posts to an authenticate.cfm page. Make sure that the authenticate.cfm
> page only takes input from your server and the login.cfm page. If you don't,
> people will be able to write their own login.cfm page on another page and
> post to your authenticate.cfm page.
> e.. Check that you have an IP address to send debug info to or someone can
> type ?mode=debug in the URL to pick up valuable info about your site.
> f.. Don't end your files with anything but cfm. I've noticed people ending
> their include files with things like .inc or .h. These will not get
> processed and a user who goes to it directly will see the code.
>
> Allaire has released some good stuff on this at:
> http://www.allaire.com/developer/securityzone/
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
