.NET对内存中对象的安全性
本文关键字：安全性 对象 内存 NET | 更新日期: 2023-09-27 18:21:20
考虑一个ASP.NET web应用程序[A]，它使用用户名和密码向安全web服务[B]发出请求。
用于对[B]进行身份验证的密码使用web.config文件中的"最佳实践"存储在[A]上并进行加密。
在某个时刻，未加密的密码必须存在于[A]的内存中，对吧？也许web应用程序被设计为将未加密的密码缓存在静态对象/字符串中（因此它只解密/读取web.config文件一次）。在安全性方面，这种"静态缓存"方法是更糟糕还是相同？
是否曾经发布过针对ASP.NET的攻击（或者是否存在此类攻击的可能性），攻击者可以访问服务器的内存，从而可能泄露密码？
从[a]中提取与[B]通信的职责，并将其分配给[a]可以访问但无法从互联网访问的第三应用程序服务器[C]，这会是一种更安全的架构吗？我是不是有点偏执？
.NET中的字符串不能被安排用于垃圾收集。您可以将密码读取到SecureString对象中，在不再需要该对象后，可以强制对其进行垃圾收集。
http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx
如果这是一个用户机器上的应用程序，我会很担心。对于一个基于web的服务器，我真的不认为恶意用户会访问你的内存。如果他们在那一点上，对你来说可能已经太晚了。
首先，加密的web.config节确实不那么安全。坦率地说，如果他们能够阅读web.config文件，那么他们离让应用程序泄露其全部未加密内容只有很小的一步之遥。
是的，web.config的未加密部分存在于内存中。您定义的两种方法都不会对所提供的安全级别产生真正的影响。
是的，曾经发生过内存转储的攻击。还发生了一些攻击，据称受保护的文件（如web.config）的内容被泄露。你确实跟上了你的补丁。。正确的
此外，如果攻击者能够将单个页面上传到您的网站，那么该页面将具有所有相同的访问权限（包括解密您的web.config）并公开该数据。
"将与[B]通信的职责从[a]中删除，并将其分配给[a]可以访问但无法从互联网访问的第三个应用程序服务器[C]，这会是一个更安全的架构吗？"
嗯。。不。如果A有裂缝，那么你在A和B之间的层数是无关紧要的。
您需要确保无法通过Internet访问B。此外，你的防火墙应该确保唯一可以与B通话的是A。A和B之间的通信应该在网络上加密。
此外，B不应该隐含地信任A。换句话说，每次发生安全事务时，A都应该向B发送适当的USER凭据。B应负责验证这些凭证是否被授权采取所要求的行动。
假设B是数据库服务器，a是人们登录的网站。每次A向B发送查询时，都应该包括最终用户的凭据。然后，B应该检查这些凭据的身份验证和授权，以确保允许该用户执行请求的操作。当然，这需要A不能直接访问B来运行查询。但这是一个完全不同的主题。
如果攻击者可以向ASP.NET进程读取/写入任意内存，那么您绝对无法对此进行保护。你能做的任何事，他都能搞定。即使你使用第三台服务器C，他也可以修补"a"，将密码发送给恶意服务。