16

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

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

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

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

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

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

4

5 回答 5

23

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

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

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

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

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

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

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

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

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

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

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

Microsoft建议对连接字符串进行加密。

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

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

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

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

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

于 2012-05-02T15:58:51.083 回答
3

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

于 2012-05-02T16:01:32.870 回答
1

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

filetype:config web.config -CVS

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

于 2012-05-02T16:11:37.260 回答
0

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

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

如果您不想使用命令行和 RSA 密钥（坦率地说，您为什么要这样做？），请查看这个用于加密 web.config 的工具。

于 2012-05-02T16:26:47.207 回答