RE: SQL connection string security (Summary, I think)
From: Eli Allen (eallen@mail.bcpl.lib.md.us)Date: 01/11/02
- Previous message: Mike Shaw: "Re: NAT firewalls possibly insecure by nature?"
- In reply to: Keith T. Morgan: "SQL connection string security (Summary, I think)"
- Next in thread: Eli Allen: "RE: SQL connection string security (Summary, I think)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Eli Allen" <eallen@mail.bcpl.lib.md.us> To: "Keith T. Morgan" <keith.morgan@terradon.com>, "Chip Andrews" <chipandrews@usa.net> Date: Fri, 11 Jan 2002 15:22:37 -0500
Just to start this off I hope you don't take what I say as a personal
attack, I just like arguing security :) anyway...
Keith, isn't my first idea almost the same as your idea just I'm storing the
strings in a file instead of the registry? (I do like your registry for
storage approach more)
The reason why my method is better then just storing the strings in a file
like global.asa is the ACL on the file. Most file disclosure bugs seem to
just be disclosure of files the IUSR/IWAM account has access to. So I'm
protecting against that possibility.
Integrated authentication to SQL server is much better. But I tend to agree
with Keith in that for a normal public web site where you want logins it
doesn't make much sense to have integrated logins (especially if there are
multiple web sites on the box which I'll get to later) But making the IUSR
account weak by not letting IIS control the password doesn't seem like such
a good tradeoff. So if the web site is only using Anonymous access then you
can't use integrated auth.
I'm not saying the SQL server should be allowed to connect to the outside
world. But since I disagree with saying that if the attacker can run code
on the server then its game over so that means the connection string must be
secure. Sure if you are running your own web server and the attacker gets
access to that web site or the server then its a bad thing. But what about
ISPs who have many customers so a web server can have many sites on it? If
customer a had a site on a box, evil person b could then pay for a site that
would go on the same box. So here is a case where the attacker can run code
on the server but if its game over then lots of ISPs would be screwed.
If each site needed to have its users in the SAM or some domain that
wouldn't work very well since how would the web site only get access to the
accounts that are for that site and no others? Plus you'd then have lots of
usernames already in use which may seem strange from the perspective of just
one of the sites. So that rules out doing security that way.
> -----Original Message-----
>
> 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:chipandrews@usa.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.morgan@terradon.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:chipandrews@usa.net]
> > Sent: Thursday, January 10, 2002 3:57 PM
> > To: Keith T. Morgan; Eli Allen
> > Cc: focus-ms@securityfocus.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>
>
>
- Previous message: Mike Shaw: "Re: NAT firewalls possibly insecure by nature?"
- In reply to: Keith T. Morgan: "SQL connection string security (Summary, I think)"
- Next in thread: Eli Allen: "RE: SQL connection string security (Summary, I think)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
