Your points below are certainly valid. Here's what I think is a summary:

I fully agree that hiding and obfuscation of connection strings are generally a poor way to go. Security through obscurity is a horrible concept, and you are correct that eventually someone will find it.

However, in application development, using integrated security is simply not the norm. It's not very practical, especially in the unix world. You will rarely ever see unix based web applications with web application users in /etc/passwd. Just like IIS, normally they'll be connecting via native db auth, or a database user account. I wouldn't even consider placing all of my web-app users in /etc/passwd on unix. No-way batman. I think most of the unix development community will agree.

I also agree that integrated authentication is inherently safer than SQL native auth. There's no question there. But again, it's not very practical. Most software developers strive to make thier applications as portable as possible. So, many times, they'll write thier code using SQL native auth to make the transition to Oracle, Sybase, Postgres or another RDB much easier. I could always be wrong. Maybe there are a lot more developers than I think out there using integrated auth for IIS based web applications.

And again, noting the most common bugs/exploits in web-servers tend to be file disclosure problems, my basic premise remains intact, keep the connection string out of the file-system.

In summary, if your development model and environment will permit SQL native authentication, that's definitely the way to go. If not, in my opinion, it's a *very* good idea to get the DSN connection strings out of the file-system. Make the attacker work to find/access them.

Further comments in-line denoted with "--->":

-----Original Message-----
From: Chip Andrews [mailto:chipandrewsusa.net]
Sent: Friday, January 11, 2002 10:58 AM
To: Keith T. Morgan
Subject: Re: [RE: [RE: SQL connection string security]]

Keith,

In the UNIX world there is no registry, configuration settings are commonly
found in the filesystem, and they don't expereience near the level of security
issues that you and I deal with daily. The security community has spoken and
it has said that security is inversely proportional to complexity.

----> Definitely the case. And IIS and security in general's an entire can of worms unto itself.

What I am saying is that attempting to "hide" connection strings is not
necessary - simply remove the secret from the connection string OR prevent
direct connection to the SQL Server from all but the web server. This would
allow the connection string to be useless information.

---> Agreed, if you can take it out of the picture via integrated authentication, that's the ticket. Also, protection of the SQL server (as you imply) from direct connection from the internet is critical.

I totally disagree with your assessment that Integrated security scenarios are
not real-world. I use them all the time - it takes 2 minutes to set up and I
can even enforce policy rules - all my accounts are centralized.

---> Hmmm... Out of the dozens of enterprise level intranet/extranet/e-commerce development projects I've worked on, only one of them resided in an environment where integrated authentication was practical. Still, if you can go that route, by all means, it's the best way.

I'm telling you from experience that if you use standard SQL Server security
and the SQL Server is exposed (presumably why you are protecting the
connection string) then sooner or later you are going to be toast. SQL Server
just doesn't have the security model to support any real security features.

---> I'm not sure what you mean by exposed. Anyone that leaves an SQL server wide open for the internet to play with is certainly in very deep trouble. I think protection of the connection strings would be more to prevent it's use by someone who's gained file-system access and can plop thier own ASP (or whatever) code onto the machine. At that point they would be able to take advantage of the string. Again however, as I've maintained from the gitgo, if they've gained privledge escalation to the point where they're executing thier own code on the file-server, it's pretty much game over anyway.

It's just my opinion. I only wanted to help. I apologize if you have taken
it as a personal attack.

---> No, I didn't see it as a personal attack. I think this is a valuable discussion and I hope the list members are following it.

Chip

"Keith T. Morgan" <keith.morganterradon.com> wrote:
> That was my point, if you gain IWAM access on the box, it's game over
anyway. If you pull off priveledge escalation, it's done. Game over. It's
only a matter of time and creativity to a full compromise of both all files on
the webserver's filesystem and a compromise of data sources as well. If
you're writing to the filesystem to install your own objects, (because you
somehow figured out where the registry keys are, and have the correct account
to read them) forget the registry, forget it all, it's game over. If you've
accessed the machine to that point, you've won.
>
> Now, the "shell game" thing. What are the most common exploits against web
servers? File and source code disclosure vulnerabilities. Hmmm... let's put
it in c:\webdsn.xml. All you need at that point is the ability to read some
file out of the webserver's root/virtual roots and you've compromised the dsn
info. If it's in the registry, you have to be able to a: dump the registry
and search it (this requires more than a source disclosure or file disclosure
vulnerability, even interactive access via a c:> remote a~la e-eye), the
ability to somehow parse (decompile?) the objects currently being used by the
webserver so that you can create your own, the ability to write to the
file-system and call the existing objects (in the CORRECT security context
because you've had the sense to place NT based security on your com objects).
>
> This points out the disconnect between microsoft and "real world" security.
Microsoft (and it's solution / dev pertners) should have thier finger on the
heartbeat of the security community. They should know that the most common
exploit against webservers is file disclosure. When you look at it from the
perspective of the way the "real world" works, moving the DSN connection
strings out of the file-system makes a *lot* of sense.
>
> Ok, call it a shell game. But saying "don't use sql native auth" is pure
microsoft brainwashing. They feel that thier security mechanisms are the best
way to go despite thier track record. I know what they recommend, and I
maintain that thier recommendiations regarding SQL authentication will provide
you with no extra security unless you're authenticating your web users
directly to the SAM. Almost *NO* one does that in an
extranet/intranet/e-commerce environment due to the administrative overhead of
managing the NT accounts. Extranet/E-Commerce users will almost *never* be
native Windows accounts. They'll almost always be contained in a separate
object (database, file, etc...).
>
> Granted, doing things pure NT auth works. Forcing your web-users to have
local NT accounts works. That's a good solution. It's not practical. You
won't see it very often in the real world, but it is the best way to go from a
security perspective. And in that case, the microsoft recommendations are
right on.
>
> -----Original Message-----
> From: Chip Andrews [mailto:chipandrewsusa.net]
> Sent: Thursday, January 10, 2002 3:57 PM
> To: Keith T. Morgan; Eli Allen
> Cc: focus-mssecurityfocus.com
> Subject: Re: [RE: SQL connection string security]
>
>
> 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?
>
> <snip>

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