Is there a need to secure connection string in web.config?

Question

So I am using connection strings in my web.config using SQL authentication.

Of course people say this could be a vulnerability as you are storing password in plaintext.

However, from what I know, IIS never serves web.config, and web.config should only have read access to administrators and IIS anyway. So if the hacker has gained access to the webserver, then it won't matter what encryption I use because the private key will be on the webserver.

Wouldn't encrypting connection string be classified as security through obfuscation?

Is it worth encrypting web.config connection string and storing the private key on the webserver?

Further, of course if I don't use SSL, I am transmitting connection string over HTTP in plaintext. If I use SSL then this problem should be mitigated as well.

Solution 1

I wouldn't say that storing a plaintext password in Web.config is a security vulnerability, in and of itself. But encrypting the password is a useful defense-in-depth measure, not just security through obscurity:

1. What if IIS is misconfigured to serve Web.config?
2. What if a security vulnerability is discovered in ASP.NET (like the padding oracle vulnerability) that allows anyone to download Web.config?
3. There are varying degrees of access to the Web server, from full administrative privileges to server-side code injection. If an attacker can only manage to do the latter, he might be able to read Web.config but might not be able to access the machine keys, especially if your application is running under partial trust.

In the end, it's up to you to decide if the risk of storing plaintext passwords in Web.config is acceptable. Of course, if Windows authentication is an option, then you may want to consider using that instead of SQL authentication.

UPDATE: When talking about security, it's a good idea to identify the assets and the threats. In this case, the asset is sensitive data in the database (if the data is unimportant, then why bother protecting it with a password?), and the threat is the possibility of an attacker somehow gaining access to Web.config and thus the database as well. A possible mitigation is to encrypt the database password in Web.config.

How much of a risk is it? Do we really have to plan for such an astronomically rare occurrence?

This mitigation has already proved its worth once: when the ASP.NET padding oracle vulnerability was discovered. Anyone who stored a plaintext password in Web.config was at risk; anyone who encrypted the password wasn't. How certain are you that another similar vulnerability in ASP.NET won't be discovered in the next few years?

Should we also encrypt source code and decrypt on run-time? Seems excessive to me.

So what if an attacker does get access to your source code? What's the asset you're protecting, and what's the threat you're concerned about? I think that in many cases, source code is much less valuable than data. (I'm thinking here about off-the-shelf commercial and open-source software which anyone can obtain.) And if your source code is valuable, maybe obfuscation is something to think about.

I feel if they already have even limited access to your box, then your host has failed or you've installed vulnerable services already.

What about security vulnerabilities in ASP.NET or your code? They do pop up from time to time.

My concern is standard practices. Is it a standard?

Microsoft has recommended encrypting connection strings.

What you should do is evaluate the risk that storing a plaintext password poses:

• How likely is it that an attacker will be able to discover and exploit a security vulnerability that exposes Web.config? Based on past history, I'd say the likelihood is low (but not "astronomically" low).
• How valuable or sensitive is your data? If all you're storing is pictures of your cat, then maybe it doesn't matter much whether an attacker gets your database password. But if you're storing personally identifiable information, then from a legal standpoint, I'd say you should take all possible measures to secure your application, including encrypting your connection strings.

Solution 2

Consider that, if Production passwords are present in the web.config file, then any developer with access to that file has access to the Production database. This is especially a problem when the username in the connection string has read/write access to the database. It then becomes possible for developers to "fix" things with no record that the "fix" ever occurred.

Solution 3

I think this is not from "outside" protection, but for "inside".

Sometimes, SQL administrator/user and OS administrator are different people. But OS administrator has access to all files, so he could easily read the SQL credentials in web.config file. But those credentials can be encrypted in a way, that even OS administrator has no way to decrypt.

And it is hardly "security through obscurity", because encrypted connection string canno't be decrypted without correct user certificate and usualy only IIS "user" has that one.

Solution 4

I used to read some articles on IHackStuff online blog. This guy explained some ways to get to really interesting info using Google search engine typing things on the search box like:

filetype:config web.config -CVS

This came out with multiple results related to cached web.config files on production servers, all the info of those files were available to public eye. Considering this possibility I would still recomend to encrypt web.config database access info whenever such info is valuable enough.

View more solutions

Comments

[Dexter]

If someone is an OS administrator, wouldn't they have access to the IIS user and the private key contained in the user certificate? Seems rather like security through obfuscation to me. I would think it is more protection against users who have only localized FTP access to the site folders (so they can possibly read web.config), not full access to the webserver.

[Dexter]

Yeah, I agree. I would think it would be protection from developers, users with FTP access, who may not be allowed to access/change the production database (and don't have web-server admin access). That is not a particular concern of mine because the developers are few and vetted. But definitely something to discuss internally right?

[Euphoric]

I don't think it is possible to read the certificate. I don't remember the exact procedure, but I believe it is impossible for OS administrator to read the encryption.

[John Saunders]

It also depends on whether and how your industry is regulated. Certain industries must be able to show that their production data is safe.

[John Saunders]

-1: sorry, I don't believe you. Try serving a .config file through IIS and you'll see. If you believe this is true, then post a link with proof.

[CoderRoller]

202.120.107.88/incoming/WebSite1/Web.config

[CoderRoller]

Well, even when this is not a common case, incorrect configuration on a server can lead to disclosure of web.config info on search engines as its proven on those links.

[John Saunders]

Unimpresive. The first is some mono site, which to my mind, doesn't count. The second case is an FTP site for uploading files. Someone posted their web site there. It doesn't matter in any case, since the server in question is not reachable through the Internet (at least, not from where I'm located).

[John Saunders]

Why would you need anything other than the standard .NET ability to enrypt config file sections and to have them automatically decrypted upon use?

[CoderRoller]

I use ftp service to update files on some asp.net web apps which I think perfectly valid. I found this other one: ftp.crab.wa.gov/web.config uptime.netcraft.com/up/graph?site=www.crab.wa.gov (IIS enabled server) You could also remove the .config extension on an IIS based site on its properties and let config files readable. My point is just to prove that on some ocassions the file could be visible and therefore encryption might be justified.

[John Saunders]

Making your FTP site accessible with no authentication is asking to be hacked in any case.

[CoderRoller]

Also be sure that the IIS configuration for your website is correct to avoid the need of encryption.

[John Saunders]

The default IIS configuration will not serve .config files. You have to go out of your way to make them accessible.

[CoderRoller]

The default configuration can be changed, so verify it is set properly.

[Euphoric]

@John Saunders That requires you to be exact same user who encrypted the file or have private key, that is used for decryption on IIS.

[John Saunders]

Are you sure it doesn't just use the machine key?

[Euphoric]

@John Saunders You can use multiple types of encryption providers. Machine key is one of those. More: msdn.microsoft.com/en-us/library/68ze1hb2.aspx

[Dexter]

I don't quite understand. To me, an OS administrator is someone who has root access to the box, nothing below it can be protected. No certificate or key of any kind if protected.

[Dexter]

I've met people who have argued that the web.config is vulnerable and is accessible by "gaining access through some other app in the system." And this blew my mind because, if they have access to your webserver, then they already have all your source code too---do we encrypt that as well??? So I do believe this is some sort of protection from developers who already have source code access, but are not allowed to have database access. I feel it's more a host issue than a developer issue.

[Dexter]

1. It's the default option, and you would have to manually set it.2. Then they already have access to your source code too. Should we also encrypt source code and decrypt on run-time? Seems excessive to me. 3. I feel if they already have even limited access to your box, then your host has failed or you've installed vulnerable services already. ---- to me encrypting your web.config is security through obfuscation. It would be like me, encrypting my javascript to secure my javascript source code (even though the web browser can read it). My concern is standard practices. Is it a standard????

[Dexter]

Further, how much of a risk is it? Is it common that people are accessing web.configs across ASP.net websites all over the web? I mean, IIS can suffer an irrecoverable error and accidentally display the web.config as it is trying to read the web.config and display some website for a brief moment. Do we really have to plan for such an astronomically rare occurrence? Most PHP website also use some sort of settings.php or config.php to protect their database password, and only change its read permissions. They don't encrypt that either (even in production servers).

[John Saunders]

Do keep in mind that all the lovely code we develop must eventually be deployed to nasty real hardware in order to be useful. It will have to be managed by real Operations people, in real life. Developers having the ability to make random changes to Production data is a real problem, and not only in terms of attacks. A developer running a manual DELETE statement but forgetting one of the terms in the WHERE clause could really ruin your day.

[Dexter]

Thank you for clearly explaining the risks. I think you've well-earned best answer. I do still think that if they have exploited a vulnerability in IIS / ASP.NET, then they have already gained unpredictable access to your system. I feel that it is more a protection against INSIDE threats (developers who are malicious or accidentally damage data) than OUTSIDE threats (exploitation etc). However, I understand there could always be low-chance risks.

[Monkey Code]

Try with other extensions like .old, .bak, .old1