Serious security issue and how to approach it
-
I've inherited a .NET web application with a SQL 2000 backend. I've never been a big fan of SQL connection strings being stored in web.config files, but sometimes it is the easiest solution. This application has just such a web.config file with the login name and password of a sql server account.
Here's the real problem: The account is a member of sysadmin
Now, how would you go about telling the developer that, well, this isn't a really good idea and that, if you are going to put a login name and password in a web.config file, it should be a least-priviledged account as possible for the application to work and in no way should be a db_owner or sysadmin member?
-- J.T.
"I may not always know what I'm talking about, and you may not either."
-
Depends on how well you get on with the developer. If you get along fine then just tell it like it is.
If you don't get along, or you get no where by telling it like it is, you've got several options:
- Remove the account or change the password and wait for the developer to come to you. Then offer a solution of creating a new account and give it the necessary privilges.
- Delete several key tables and blame it on a hacker that hacked the web.config file. Wait for developer's face to go pale when the manager questions why a sysadmin account was used. Recover database from a backup you coincidentally took just seconds before the "hack". This is my faviourite because you get your change, you watch the developer s**t their pants and you get a pat on the back for having a safe backup
Seriously though, the only way to go about it is to explain the risks (which are pretty obvious) and offer a solution that hurts no one, is easy to implement, and best of all, is more secure.
-
If it's a .Net 2.0 app, you could as a minimum encrypt the sensitive data section. Still, no excuse not to use a least-rights account!
-
Easy - don't tell the developer, tell his boss. Tell whoever in the business own the application. Tell anyone in the the business who might care.
Tell them the business reasons it's bad, not the "IT reasons", and let them tell the developer. He'll respect their decision and it won't cause any conflict between ye and he.
-
Thanks for the advice. I wound up telling my boss who told me to tell the developer in an email and copy the project manager. I basically laid out why it was a bad idea to use a member of sysadmin in this capacity and asked if he could provide us with a list of what access was needed by the application.
His response?
"read write access to all the user tables on the server"
-- J.T.
"I may not always know what I'm talking about, and you may not either."
-
Good for you! I've discovered that quite a few applications are built on the 'sa' account (or an account with sysadmin privileges) just because they were developed that way--security wasn't their concern. I've had to cross that bridge many times with third-party applications, and when I ask why the application needed that much authority in SQL Server vendors usually can't give an answer 🙂 We are currently purchasing a new product and the vendors want us to use the 'sa' account for a lab scenario and I won't allow it because the production database certainly won't have it.
Stick to the principle of least privilege and you will be glad you did.
-
I agree. At a previous job we had to purchase separate application and database servers for two commercial applications becuase they hardcoded the sa credentials in the application code and could not/would not change them.
Security as an afterthought. Makes one weep.
-- J.T.
"I may not always know what I'm talking about, and you may not either."
-
Glad to hear it worked out for you.
They do tend to say read/write everything in response though, but it is a sea change from sysadmin. At least your server and the network are safe - shame about their data!
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply