【问题标题】:Assign null to string var to remove sensitive data将 null 分配给字符串 var 以删除敏感数据
【发布时间】:2015-07-31 16:51:03
【问题描述】:

在这里查看 Fortify 的一些发现,它告诉我不要将字符串数据类型用于敏感数据,因为它们可能会在内存中停留太久。如果发生不相关的内存攻击(例如 Heartbleed),这会暴露用户的数据。

如果我在使用后将字符串 var 设置为 null,该内存位置是否真的被清除了,或者是为存储 null 而创建的 var 的副本?

谢谢

【问题讨论】:

    标签: java fortify


    【解决方案1】:

    我认为你问错了问题。

    如果您将变量设置为 null,那么可以肯定,该引用指向 null。原始值可以被垃圾回收。

    问题是字符串比这要复杂一些。您应该问的问题是为什么字符串可以留在内存中?

    一个答案是字符串文字池。 Google 是您的朋友,但这是一个不错的开始:

    What is the Java string pool and how is “s” different from new String(“s”)?

    When will a string be garbage collected in java

    Garbage collection of String literals

    【讨论】:

    • 所以在阅读完所有内容之后,听起来最好的方法是 Fortify 和 @K139 的建议 - 使用 Char[ ] 并在完成后将其设为 null。
    • @DaveC 如果您担心有人会遇到读取程序内存的麻烦,那么是什么阻止他们简单地读取字符数组?
    • 我不会说 Fortify 是 100% 准确的,但逻辑是这样的。如果我加载带有敏感数据的 Char[],我可以在使用后立即擦除它,并且数据不再在内存中。像 Heartbleed 这样的攻击依赖于在内存中停留足够长的数据以被利用代码读取。使用 Char[ ] 并不能完全缓解漏洞,但是如果内存中的时间从 X 分钟数减少到 X 毫秒数,那么可能性就会大大降低。
    • 而且我有更少嘈杂的 Fortify 发现来查看每个版本。 :-D
    • 另一方面,您的同事将继承和维护奇怪的代码。一切都有代价。
    【解决方案2】:

    如果您将String 引用设置为null,则它可能不会从实际内存中删除,并且可能可供潜在的黑客使用。

    您可以使用Char[] 并将其设置为空/无效字符以避免此问题,而且最好将sensitive 数据保持为encrypted 格式。

    【讨论】:

    • 同意,加密是最好的,但在某些时候它必须是明文才能使用。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-02-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多