当然,人们说这可能是一个漏洞,因为你用明文存储密码.
但是,从我所知道的,IIS从不服务于web.config,而web.config应该只能对管理员和IIS进行读取访问.因此,如果黑客已经访问了网络服务器,那么使用什么加密并不重要,因为私有密钥将在网络服务器上.
连接字符串加密不会被分类为安全性吗？
是否值得加密web.config连接字符串,并将私钥存储在Web服务器上？
此外,当然如果我不使用SSL,我通过HTTP传输连接字符串明文.如果我使用SSL,那么这个问题也应该被缓解.
解决方法
>如果IIS配置错误以提供Web.config怎么办？
>如果在允许任何人下载Web.config的ASP.NET(如padding oracle vulnerability)中发现安全漏洞,该怎么办？
> Web服务器的访问程度不同,从完全管理权限到服务器端代码注入.如果攻击者只能设法执行后者,他可能会读取Web.config,但可能无法访问机器密钥,尤其是在您的应用程序以部分信任方式运行时.
最后,您可以决定是否可以在Web.config中存储明文密码的风险.当然,如果Windows身份验证是一个选项,那么您可能需要考虑使用而不是sql身份验证.
更新：在谈论安全性时,最好确定资产和威胁.在这种情况下,资产是数据库中的敏感数据(如果数据不重要,那么为什么要用密码来保护它呢？),并且威胁是攻击者以某种方式获得对Web.config的访问的可能性,因此数据库以及.可能的缓解是在Web.config中加密数据库密码.
How much of a risk is it? Do we really have to plan for such an astronomically rare occurrence?
这种缓解已经证明了它的价值：当发现ASP.NET填充oracle漏洞时.任何在Web.config中存储明文密码的人都有风险;任何加密密码的人都没有.您在ASP.NET中的另一个类似的漏洞在未来几年将不会被发现？
Should we also encrypt source code and decrypt on run-time? Seems excessive to me.
那么如果攻击者可以访问你的源代码呢？你保护的资产是什么,你担心的威胁是甚么？我认为在许多情况下,源代码的价值远低于数据. (我在这里考虑任何人都可以获得的现成的商业和开放源代码软件.)如果您的源代码有价值,那么可能需要考虑混淆.
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?
Microsoft has recommended加密连接字符串.
你应该做的是评估存储明文密码的风险：
>攻击者能够发现和利用暴露Web.config的安全漏洞的可能性有多大？根据过去的历史,我会说可能性很低(但不是“天文学”).
>您的数据有多贵或敏感？如果您存储的所有内容都是您的猫的照片,那么攻击者是否可以获取您的数据库密码,可能并不重要.但是,如果您正在存储personally identifiable information,那么从法律的角度来说,我会说您应该采取一切可能的措施来保护您的应用程序,包括加密连接字符串.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
