考虑使用用户名和密码向安全Web服务[B]发出请求的ASP.NET Web应用程序[A]。
用于向[B]进行身份验证的密码使用web.config文件中的“best-practices”存储在[A]中并加密。
在某些时候，未加密的密码必须出现在[A]的内存中，对吗？也许Web应用程序旨在将未加密的密码缓存在静态对象/字符串中（因此它只能从web.config文件解密/读取一次）。这种“静态缓存”方法在安全性方面是更差还是相同？
是否有针对ASP.NET的攻击发布（或者是否存在此类攻击）攻击者可以访问服务器的内存，可能会泄露密码？
从[A]中拉出与[B]通信的责任并将其分配给[A]可访问但无法从互联网访问的第三个应用服务器[C]，这是一个更安全的架构吗？我只是偏执狂吗？
答案 0 :(得分：2)
如果这是一个位于用户机器上的应用程序，我会非常担心它。对于基于Web的服务器，我真的不认为您应该期望恶意用户能够访问您的内存。如果他们在那时候，你可能已经太晚了。
答案 1 :(得分：2)
首先，加密的web.config部分确实不那么安全。坦率地说，如果他们能够达到阅读web.config文件的程度，那么他们距离能够让应用程序泄露整个未加密的内容只是非常小的一步。
是的，web.config的未加密部分存在于内存中。您定义的方法都不会对所提供的安全级别产生影响。
是的，发生了内存转储的攻击。还有一些攻击，其中已经泄露了所谓的受保护文件的内容，例如web.config。你确实跟上你的补丁..对吧？
此外，如果攻击者能够将单个页面上传到您的站点，那么该页面将具有所有相同的访问权限（包括解密您的web.config）并公开该数据。
“从[A]中提取与[B]通信的责任并将其分配给[A]可访问但无法从互联网访问的第三个应用服务器[C]，这是一个更安全的架构吗？ “
嗯..没有。如果A被破解，那么你在A和B之间放置的层数是无关紧要的。您需要确保无法通过互联网访问B.此外，您的防火墙应确保可与B通信的唯一内容是A. A和B之间的通信应在线路上加密。
此外，B不应该隐含地信任A.换句话说，A应该在每次发生安全交易时向B发送适当的用户凭证。 B应负责验证这些凭据是否有权采取请求的操作。
假设B是数据库服务器，A是人们登录的网站。每次A向B发送查询时，它应包括最终用户的凭证。然后，B应检查这些凭据的身份验证和授权，以确保允许此用户执行请求的操作。当然，这要求A不能直接访问B上的运行查询..但这是一个完全不同的主题。
答案 2 :(得分：1)
无法安排.NET中的字符串进行垃圾回收。您可以将密码读入SecureString对象，在不再需要它之后可以强制进行垃圾回收。
http://msdn.microsoft.com/en-us/library/system.security.securestring.aspx
答案 3 :(得分：0)
如果攻击者可以向ASP.NET进程读取/写入任意内存，那么您无法做任何事情来防止这种情况发生。你可以做任何事情，他可以修补。即使您使用了第三台服务器C，他也可以修补“A”将密码发送给恶意服务。