With all due respect Keith:

Ahh, the old shell game. Is it in global.asa, the metabase, or the registry?
If that string exists it will be found. If I gain even IWAM access on the box
what's to stop me from creating a new asp page that simply invokes the
component and dumps the string? No need to root the box at all.

On a fully patched (I have to say that now) server, you cannot read the
global.asa file anyway because the ASP ISAPI handler will not allow it to
viewed. Why is it necessary to play all of these games? Why do people feel
safer if its in the registry than on the filesystem? or the metabase? or in
memory? or encrypted with a symmetric key (which is also on the box of course
so the application can read it)? Has the registry been a traditionally safe
place for information? I think not.

I'm sorry if I seem cranky. I drank too much coffee today. ;)

Chip
www.sqlsecurity.com

"Keith T. Morgan" <keith.morganterradon.com> wrote:
> We've had a basic premise for storage of connection strings, ODBC DSN
passwords and the like. If we are not using windows based authentication
(most times we do not, as it's not very portable between database back-ends)
we will almost always store the connection strings in the system registry.
We'll then build a com object to read the registry keys and obtain the
connection strings. This keeps that information out of the readable
file-system. For an attacker to gain access to the key, they would have to
,basically, completely compromise the host webserver. We use appropriate
permissions on both the registry keys themselves (along with the obscurity of
an attacker having to locate them), and the com objects that are capable of
reading them. So, this means either gaining the system account permissions,
administrative permissions, or the permissions of the web-server's executive
account is required to gain access to the connection string. If any of the
above three things happens, it's pretty much game-over anyway.
>
>
>
>
> -----Original Message-----
> From: Eli Allen [mailto:eallenbcpl.net]
> Sent: Wednesday, January 09, 2002 8:18 PM
> To: focus-mssecurityfocus.com
> Subject: SQL connection string security
>
>
> With the importance of not letting the connection string used to connect to
> a DB out (i.e. not putting the connection string in the source file) I had
> two basic ideas on how to do that:
>
> http://www.wam.umd.edu/~eallen/sqlconnstr.html
>
> __
> Eli Allen
> eallenbcpl.net
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]