asp.net - 是否需要在 web.config 中保护连接字符串？

Question

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

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

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

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

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

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

Answer 1

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

如果 IIS 配置错误以提供 Web.config 服务怎么办？

如果在 ASP.NET 中发现了允许任何人下载 Web.config 的安全漏洞(如 padding oracle vulnerability)怎么办？

对 Web 服务器有不同程度的访问，从完全管理权限到服务器端代码注入(inject)。如果攻击者只能设法做到后者，他可能能够读取 Web.config 但可能无法访问机器 key ，尤其是当您的应用程序在部分信任下运行时。

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

更新:在谈论安全性时，识别 Assets 和威胁是一个好主意。在这种情况下， Assets 是数据库中的敏感数据(如果数据不重要，那为什么还要用密码保护它？)，威胁是攻击者可能以某种方式获得对 Web.config 的访问权限，从而访问数据库也是。一种可能的缓解方法是在 Web.config 中加密数据库密码。

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

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

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

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

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

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

My concern is standard practices. Is it a standard?

微软has recommended加密连接字符串。

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

攻击者能够发现和利用暴露 Web.config 的安全漏洞的可能性有多大？根据过去的历史，我会说可能性很低(但不是“天文数字”低)。

您的数据有多有值(value)或有多敏感？如果您存储的只是猫的照片，那么攻击者是否获得您的数据库密码可能并不重要。但是，如果您要存储 personally identifiable information ，那么从法律的角度来看，我会说您应该采取一切可能的措施来保护您的应用程序，包括加密您的连接字符串。