内存堆安全：字符串垃圾回收
我最近一直在为我的公司进行安全代码审查，并使用一个名为 Fortify360 的工具。它将识别代码的许多问题并描述问题。它提出了一个有趣的问题，但我没有找到任何其他信息，如下：
“如果存储在托管 String 对象中，则存储在内存中的敏感数据（例如密码）可能会泄漏。String 对象不是固定，因此垃圾收集器可以随意重新定位这些对象，并在内存中保留多个副本。默认情况下，这些对象不会加密，因此任何可以读取进程内存的人都可以看到其中的内容。内存被换出到磁盘时，字符串的未加密内容将被写入交换文件。最后，由于 String 对象是不可变的，因此从内存中删除 String 的值只能由 CLR 垃圾收集器来完成。除非 CLR 内存不足，否则不需要运行，因此无法保证何时进行垃圾收集，如果应用程序崩溃，应用程序的内存转储可能会泄露敏感数据。”
我认为所有这些都很有道理，并且在我对这个问题的研究中是相当标准的。
问题是：我该如何解决这个问题？假设有问题的一个或多个类不能从 iDisposable 继承（非常大的应用程序，并且在有问题的字符串之后很长一段时间内需要该类）。是否有手动内存管理的替代方法来处理特定字符串而不调用垃圾收集器 GC.Collect()？
提前感谢您的帮助。
亚历克斯
I have recently been doing a security code review for my company and using a tool called Fortify360. It will identify many issues with the code and describe the problems. An interesting issue it has raised that I have not found any other info on is the following:
"Sensitive data (such as passwords) stored in memory can be leaked if it is stored in a managed String object. String objects are not pinned, so the garbage collector can relocate these objects at will and leave several copies in memory. These objects are not encrypted by default, so anyone that can read the process' memory will be able to see the contents. Furthermore, if the process' memory gets swapped out to disk, the unencrypted contents of the string will be written to a swap file. Lastly, since String objects are immutable, removing the value of a String from memory can only be done by the CLR garbage collector. The garbage collector is not required to run unless the CLR is low on memory, so there is no guarantee as to when garbage collection will take place. In the event of an application crash, a memory dump of the application might reveal sensitive data."
All of this I understand to make good sense and in my research of the issue is pretty standard.
The question is: how do I solve the issue? Suppose the class or classes that are in question cannot inherit from iDisposable(very large app, and the class is needed long after the string in question). Is there an alternate way of manual memory management to dispose of a specific string without calling the garbage collector, GC.Collect()??
Appreciate the help in advance.
Alex
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您想避免这种情况，您需要使用 System.SecureString，它是
IDisposable，用于保存敏感数据，仅在所需的最短时间内保留该数据。具有讽刺意味的是，MSDN 示例代码没有显式地或通过
using封装来Dispose实例。If you want to avoid this you need to use System.SecureString, which is
IDisposable, to hold sensitive data, holding onto this only for the minimum possible time required.It's kind of ironic that the MSDN sample code does not
Disposethe instance, either explicitly or withusingencapsulation.老实说，解决这个“问题”会比它的价值更麻烦。
使用 ASP.NET 等技术时，无法阻止将用户提交的密码保留在字符串中，除非您要在发送字符串之前在客户端对其进行加密，因为 ASP.NET 会将它们作为字符串存储在表单集合等中
。如果您确实采用了 JS 加密路线，请注意任何潜在的攻击者也能够解密他从您的应用程序中恢复的字符串。
然而，如果有人闯入了 Web 服务器，他很可能会破坏整个数据库。这比从 Web 服务器堆中收集一些密码更糟糕...
现在，如果这不是 ASP.NET 应用程序，并且您可以完全控制代码中如何处理密码，那么您可以采取查看 SecureString。但您可能仍然会发现，最小的好处超过了代码复杂性的增加。这实际上取决于密码泄漏的严重程度，以及您的计算机首先受到威胁的脆弱性。如果您不担心某些远程攻击者能够调试您的进程并获取内存快照，那么这实际上不是问题。
总之：如果攻击者有能力从内存或交换中提取这些字符串，他也有能力做更糟糕的事情。
Honestly, solving this "problem" will be more trouble than it's worth.
Keeping user-submitted passwords around in strings cannot be prevented when using technologies like ASP.NET, unless you are going to encrypt the strings client-side before sending them, since ASP.NET will store them as strings in form collections, etc.
And if you did go the JS-encryption route, note that any potential attacker would also be able to decrypt the strings he recovered from your application.
However, if someone has broken into the web server, chances are good that he can compromise the entire database. And that's a much worse issue than gathering a few passwords from the heap of the web server...
Now, if this is not an ASP.NET application, and you have complete control over how passwords are processed in code, you could take a look at SecureString. But you may still find that the minimal benefits outweigh the increased code complexity. It really depends on how bad a password leak would be, and how vulnerable your machines are to being compromised in the first place. If you are not worried that some remote attacker will be able to debug your processes and take memory snapshots, this is really a non-issue.
In summary: If an attacker has the power to extract these strings from memory or swap, he also has the power to do things that are far worse.