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

Question

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

当然人们说这可能是一个漏洞,因为你用明文存储密码.

但是,据我所知,IIS从不提供web.config,而web.config应该只对管理员和IIS具有读访问权限.因此,如果黑客已获得对Web服务器的访问权限,那么我使用的加密方式无关紧要,因为私钥将位于Web服务器上.

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

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

此外,当然如果我不使用SSL,我将通过HTTP以明文传输连接字符串.如果我使用SSL,那么这个问题也应该减轻.

Answer 1

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

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

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

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

这有多大的风险？我们真的必须计划这样一个天文数字罕见的事件吗？

这种缓解已经证明了它的价值:当发现ASP.NET填充oracle漏洞时.任何在Web.config中存储明文密码的人都有风险; 加密密码的人不是.你有多确定在未来几年内不会发现ASP.NET中的另一个类似漏洞？

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

因此,如果一个攻击者怎样做才能访问您的源代码吗？您正在保护的资产是什么,您关注的威胁是什么？我认为在许多情况下,源代码的价值远低于数据.(我想在这里大约关闭的,现成的商业和开源软件,任何人都可以获取.)如果你的源代码是有价值的,也许混淆是值得思考的问题.

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

ASP.NET或您的代码中的安全漏洞如何？他们不时会弹出.

我关注的是标准做法.这是一个标准吗？

Microsoft 建议加密连接字符串.

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

攻击者有多大可能发现并利用暴露Web.config的安全漏洞？根据过去的历史,我会说可能性很低(但不是"天文数字"低).
您的数据有多珍贵或敏感？如果你所存储的只是你的猫的图片,那么攻击者是否获得你的数据库密码也许并不重要.但是,如果您要存储个人身份信息,那么从法律角度来看,我会说您应采取一切可能的措施来保护您的应用程序,包括加密您的连接字符串.