是否需要在 web.config 中保护连接字符串？答案

【问题标题】：Is there a need to secure connection string in web.config?是否需要在 web.config 中保护连接字符串？
【发布时间】：2012-05-12 02:59:57
【问题描述】：

所以我使用 SQL 身份验证在我的 web.config 中使用连接字符串。

当然人们说这可能是一个漏洞，因为您以明文形式存储密码。

但是，据我所知，IIS 从不为 web.config 提供服务，并且 web.config 无论如何都应该只有管理员和 IIS 的读取权限。因此，如果黑客已经获得了对网络服务器的访问权限，那么我使用什么加密就无关紧要了，因为私钥将在网络服务器上。

通过混淆加密连接字符串不会被归类为安全吗？

是否值得加密 web.config 连接字符串并将私钥存储在网络服务器上？

此外，当然，如果我不使用 SSL，我将通过 HTTP 以明文形式传输连接字符串。如果我使用 SSL，那么这个问题也应该得到缓解。

【问题讨论】：

标签： asp.net .net web-config database-connection connection-string

【解决方案1】：

我认为这不是来自“外部”保护，而是来自“内部”。

有时，SQL 管理员/用户和操作系统管理员是不同的人。但是操作系统管理员可以访问所有文件，因此他可以轻松读取 web.config 文件中的 SQL 凭据。但是这些凭据可以通过某种方式加密，即使是操作系统管理员也无法解密。

这几乎不是“通过默默无闻的安全”，因为没有正确的用户证书就无法解密加密的连接字符串，而且通常只有 IIS“用户”拥有那个。

【讨论】：

如果某人是操作系统管理员，他们就不能访问 IIS 用户和用户证书中包含的私钥吗？对我来说，这似乎更像是通过混淆获得的安全性。我认为它可以更好地保护对站点文件夹仅具有本地化 FTP 访问权限的用户（因此他们可以读取 web.config），而不是对网络服务器的完全访问权限。
我认为无法读取证书。我不记得确切的过程，但我相信操作系统管理员不可能读取加密。
@John Saunders 这要求您与加密文件或拥有用于在 IIS 上解密的私钥完全相同的用户。
你确定它不只是使用机器密钥吗？
@John Saunders 您可以使用多种类型的加密提供程序。机器钥匙就是其中之一。更多：msdn.microsoft.com/en-us/library/68ze1hb2.aspx

【解决方案2】：

请考虑，如果 web.config 文件中存在生产密码，则有权访问该文件的任何开发人员都可以访问生产数据库。当连接字符串中的用户名具有对数据库的读/写访问权限时，这尤其是一个问题。然后，开发人员可以在没有“修复”发生过的记录的情况下“修复”事物。

【讨论】：

是的，我同意。我认为这将保护开发人员、具有 FTP 访问权限的用户，他们可能不允许访问/更改生产数据库（并且没有网络服务器管理员访问权限）。这不是我特别关心的问题，因为开发人员很少而且经过审查。但肯定要内部讨论吧？
这还取决于您的行业是否以及如何受到监管。某些行业必须能够证明其生产数据是安全的。
我遇到过一些人，他们认为 web.config 很容易受到攻击，并且可以通过“通过系统中的其他应用程序获得访问权限”来访问。这让我大吃一惊，因为如果他们可以访问您的网络服务器，那么他们也已经拥有您的所有源代码——我们是否也对其进行加密？？？所以我相信这是对已经拥有源代码访问权限但不允许访问数据库的开发人员的某种保护。我觉得这更像是主机问题而不是开发人员问题。
请记住，我们开发的所有可爱代码最终都必须部署到令人讨厌的真实硬件上才能有用。在现实生活中，它必须由真正的运营人员管理。能够对生产数据进行随机更改的开发人员是一个真正的问题，而不仅仅是在攻击方面。运行手动DELETE 语句但忘记WHERE 子句中的一个术语的开发人员真的会毁了你的一天。

【解决方案3】：

我曾经在 IHackStuff 在线博客上阅读过一些文章。这个人解释了一些使用谷歌搜索引擎获取真正有趣信息的方法，例如：

filetype:config web.config -CVS

这产生了与生产服务器上缓存的 web.config 文件相关的多个结果，这些文件的所有信息都可供公众查看。考虑到这种可能性，只要此类信息足够有价值，我仍然建议加密 web.config 数据库访问信息。

【讨论】：

-1：对不起，我不相信你。尝试通过 IIS 提供 .config 文件，您会看到。如果您认为这是真的，请发布带有证据的链接。
202.120.107.88/incoming/WebSite1/Web.config
好吧，即使这种情况不常见，服务器上的错误配置也可能导致搜索引擎上的 web.config 信息泄露，正如这些链接所证明的那样。
没有印象。第一个是一些单站点，在我看来，这不算数。第二种情况是用于上传文件的 FTP 站点。有人在那里发布了他们的网站。在任何情况下都没有关系，因为无法通过 Internet 访问相关服务器（至少，不能从我所在的位置访问）。
尝试使用其他扩展名，如 .old、.bak、.old1

【解决方案4】：

你说得对，web.config 不会被 ASP.NET 提供给浏览器。但是开发人员很谨慎，所以当他们发布新版本时，有时他们会将已知好的 web.config 复制到 web.config.old 或 web.config.bak 之类的东西中。而且由于开发者很懒惰，发布后他们忘记删除旧的 web.config，或者将其挂起几天以防他们需要回滚发布。

现在，.old 和 .bak 文件将提供给浏览器，这意味着很容易编写脚本或工具来扫描这些文件并将它们下载给攻击者，然后攻击者可以闲暇时通过他们寻找带有用户名和密码的连接字符串，突然间，你的数据库中的信用卡号码在互联网上流传......

如果您不想使用命令行和 RSA 密钥（坦率地说，为什么会这样？），请查看 this tool 以加密您的 web.config。

【讨论】：

除了标准的 .NET 功能之外，您为什么需要其他任何东西来加密配置文件部分并在使用时自动解密它们？

【解决方案5】：

我不会说在 Web.config 中存储明文密码本身就是一个安全漏洞。但是加密密码是一种有用的纵深防御措施，而不仅仅是通过隐蔽性来保证安全：

如果 IIS 配置错误以服务 Web.config 怎么办？
如果在 ASP.NET 中发现允许任何人下载 Web.config 的安全漏洞（如 padding oracle vulnerability）怎么办？
对 Web 服务器的访问程度不同，从完全管理权限到服务器端代码注入。如果攻击者只能设法做到后者，他可能能够读取 Web.config，但可能无法访问机器密钥，尤其是当您的应用程序在部分信任下运行时。

最后，由您决定在 Web.config 中存储明文密码的风险是否可接受。当然，如果 Windows 身份验证是一个选项，那么您可能需要考虑使用它而不是 SQL 身份验证。

更新：在谈到安全性时，最好确定资产和威胁。在这种情况下，资产是数据库中的敏感数据（如果数据不重要，那为什么还要用密码保护它呢？），威胁是攻击者可能以某种方式获得对 Web.config 和数据库的访问权限也是。一个可能的缓解是在 Web.config 中加密数据库密码。

风险有多大？我们真的必须为这种天文数字般罕见的事件做好准备吗？

这种缓解措施已经证明了它的价值一次：当发现 ASP.NET padding oracle 漏洞时。任何在 Web.config 中存储明文密码的人都处于危险之中；任何加密密码的人都不是。您有多大把握在未来几年内不会发现 ASP.NET 中的另一个类似漏洞？

我们是否也应该加密源代码并在运行时解密？对我来说似乎太过分了。

如果攻击者可以访问您的源代码怎么办？您要保护的资产是什么，您担心的威胁是什么？我认为在很多情况下，源代码的价值远低于数据。（我在这里考虑的是任何人都可以获得的现成商业和开源软件。）如果您的源代码很有价值，那么可能需要考虑混淆。

我觉得如果他们已经对你的盒子进行了有限的访问，那么你的主机出现故障或者你已经安装了易受攻击的服务。

ASP.NET 或您的代码中的安全漏洞怎么样？他们确实不时弹出。

我关心的是标准做法。有标准吗？

Microsoft has recommended 加密连接字符串。

你应该做的是评估存储明文密码带来的风险：

攻击者发现和利用暴露 Web.config 的安全漏洞的可能性有多大？根据过去的历史，我会说可能性很低（但不是“天文数字”低）。
您的数据的价值或敏感性如何？如果您存储的只是猫的照片，那么攻击者是否获得您的数据库密码可能并不重要。但是，如果您要存储 personally identifiable information，那么从法律的角度来看，我会说您应该采取一切可能的措施来保护您的应用程序，包括加密您的连接字符串。

【讨论】：

1.这是默认选项，您必须手动设置它。2。然后他们也已经可以访问您的源代码了。我们是否还应该加密源代码并在运行时解密？对我来说似乎太过分了。 3. 我觉得如果他们已经对你的盒子进行了有限的访问，那么你的主机已经失败或者你已经安装了易受攻击的服务。 ---- 对我来说，加密你的 web.config 是通过混淆的安全性。就像我一样，加密我的 javascript 以保护我的 javascript 源代码（即使网络浏览器可以读取它）。我关心的是标准做法。是标准吗？？？
进一步，风险有多大？人们通过 Web 上的 ASP.net 网站访问 web.configs 是否很常见？我的意思是，IIS 可能会遇到无法恢复的错误，并在尝试读取 web.config 并在短时间内显示某个网站时意外显示 web.config。我们真的需要为这种天文数字罕见的事件做计划吗？大多数 PHP 网站也使用某种 settings.php 或 config.php 来保护他们的数据库密码，并且只更改其读取权限。他们也不加密（即使在生产服务器中）。
感谢您清楚地解释风险。我认为您已经获得了最佳答案。我仍然认为，如果他们利用了 IIS / ASP.NET 中的漏洞，那么他们已经获得了对您系统的不可预知的访问权限。我觉得它更像是针对内部威胁（恶意或意外损坏数据的开发人员）而不是外部威胁（利用等）的保护。但是，我知道风险总是很小。