> >> Kind of blows that whole protect your network from the web server thing, > no? > >> ;-) > > How so? That account can be very limited.
Perhaps just the perspective from the apps I am involved with. These web apps have to have access to all the sensitive data because that's just what they do. We process financial data, trades etc., online. > >> There is an assumption in security best practices that web servers can be > more easily compromised than internal systems, and thus anything the web > server can do with it's permissions should be as limited as possible. << > > Completely agree. But that is the same issue whether it is the account > running the web server or a database account found on the web server. OK, after having thought about this during my roller ski ( ;-) ) I have come to a conclusion that fits my needs anyway. I think the reason this thread is getting so much attention is because deep down we are all a litte insecure about this, as well we should be. My conclusion is this: giving access to the web server account using nt auth is the least secure option. Assume the worst vulnerability is a web server compromise (that may not be the worst vulnerability depending on your situation but in my case it makes sense). - if the web server is compromised by a mass attack on a known vulnerability, the first thing the attacker must do is find vulnerable servers. Simple of course, they are right there on the web. - once compromised, the attacker in most cases will do the same thing on all servers. This is the way all general exploits work, attack, if you succeed run x code like "delete c:\" or "search for database and pillage data". - in the case of web server direct access to data, they can use general techniques to do this: odbc connection for example. Just execute the code in your malware payload. - without web server direct access to the database, the attacker must now specifically investigate the compromised server for more details. The next most vulnerable would be passwords in the well known web config file or machine config. The web server certainly has the rights to read this so a general attack could scan the file system for config files and look for things that look like a connection string. If found, they are golden: pillage away. The idea here to put the connection string in a separate file, with some sort of encryption is much better I think. Now the attacker would have to try to determine from the code somehow not only what file has the credentials, but how the code would find the file, decrypt it and then make the database call. This has moved completely from a general attack to a very specific attack on a single server. It may require many more trips back and forth to the server increasing the attackers exposure to detection. Hopefully at some point, the vulnerability would be discovered and corrected, further reducing the attackers chances of success. So, this option, while not secure, is in fact much harder to solve and is invulnerable to a general attack like the Blasters of the world. > >> Allowing full acess to a a database would probably fit under the list of > things not allowed. << > > I'm not sure where the full access assumption came from. See above... > >> You could just as easily argue that if the web server is compromised, you > are screwed anyway because the attack would probably have access to whatever > technique you use to get database credentials. << > > I'm not sure I follow this line of questioning. If the web server is > compromised neither option under discussions will secure the database from > the attacker. True, but I think my point above is pretty solid. What do you think? > You _can_ use a machine account. Shouldn't is arguable. The password in > the config file is encrypted by the system vs. software running under the > web server user. You may be right, it's been so long since I ran as a machine account, I don't recall the details any longer. ===== Philip - http://blogs.xcskiwinn.org/panmanphil "There's a difference between righteous anger and just being crabby" - Barbara =================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in: Essential .NET: building applications and components with C# November 29 - December 3, in Los Angeles http://www.develop.com/courses/edotnet View archives and manage your subscription(s) at http://discuss.develop.com
