【问题标题】:Hiding my security key from java reflection从 java 反射中隐藏我的安全密钥
【发布时间】:2013-02-15 21:06:33
【问题描述】:

下面的类是我用于加密的安全密钥提供者。

public class MySecretKey {
private String key="2sfdsdf7787fgrtdfg#$%@cj5";
...
//Some Util methods goes on  Here .
}

首先我不相信没有 getter 就可以访问 private 数据,但是,我的天哪,我现在可以在控制台中看到密钥了。

在其他地方使用反射我们可以看到如下代码:

public static void main(String[] args) throws Exception {
        Stacker myClass = new Stacker();
        Field key= myClass.getClass().getDeclaredField("key");
        field1.setAccessible(true);
        System.out.println(key.get(myClass));
    }

我怎样才能在课堂外隐藏我的钥匙 :( ,即使是 private 关键字在反射的情况下也无济于事。

请给我一些提示。

提前致谢。

【问题讨论】:

  • 无论如何,您的密钥都可以在编译后的代码中使用...
  • 是的。没有办法让编译到代码中的数据像那样安全。然而,正确解决方案的第一步是不要将您的代码与不受信任的代码一起编译。
  • 我认为加密密钥只是可以通过反射和 setAccesible(true) 访问的私有字段的一个示例。在某些情况下,我对库类进行了子类化,但我需要访问超类的私有字段才能正确执行,例如一个HashMap,所以我使用了这个反射技巧。当然,加密密钥不应该存在于代码中,但我认为在其他情况下,这个技巧只是破坏了封装,而不是安全性。简而言之,这个问题是关于防止反射技巧,而不是保护加密密钥。 +1
  • 我认为,总的来说,信息隐藏(使用私有/受保护/等成员)是一种有助于防止错误和防止糟糕的代码设计的技巧;不作为一种安全措施。 IE。它可能会阻止编写糟糕的(如愚蠢的)代码,而不是执行糟糕的(如恶意的)代码。

标签: java security reflection


【解决方案1】:

setAccessible

首先,如果有一个安全管理器,它的 checkPermission 方法会被调用一个ReflectPermission("suppressAccessChecks") 权限。

因此您可以通过拒绝 suppressAccessChecks 权限来防止这种情况发生。

实际上,最好避免依赖 JVM 来保持对象不可侵犯性。 Joe-E 允许 JVM 中的类之间相互怀疑,但 JVM 不是为此而设计的。

【讨论】:

    【解决方案2】:

    首选的解决方案是将密钥存储在文件中,然后使用文件系统权限来限制对文件的访问。这不是一个完美的解决方案(当然不是那么方便),但它比在代码中硬连线更好。

    【讨论】:

      【解决方案3】:

      Java 类中定义的所有字符串都可以通过在十六进制编辑器中打开类文件轻松检查,无论如何它们都不会被隐藏。更不用说可以使用反射以编程方式检索它们,正如您刚刚发现的那样。

      您用于“隐藏”私钥的机制已损坏,并且完全有缺陷。相反,您应该将密钥存储在外部文件中,例如序列化、加密的密钥存储,并通过其他方式保护 - 例如,密码或存储在其他地方的另一个密钥。

      【讨论】:

      • 这是一个很好的观点,但是仍然依赖对象不可侵犯性来保护在类加载后从SecureRandom 获得的一次性机密。我认为 OP 不排除该用例。
      • 这只是将问题向前推进...您将用于解密私钥持有者的密码隐藏在哪里?
      【解决方案4】:

      简单, 做这堂课non-instantiatable 怎么样?

      创建一个私有构造函数并让你的key字段static

      所以你的班级看起来像这样

      public class MySecretKey {
          public static String key="2sfdsdf7787fgrtdfg#$%@cj5";
          private MySecretKey(){} //Private constructor
          //No Util methods will go here.
      }
      

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2014-10-02
        • 1970-01-01
        • 1970-01-01
        • 2020-12-20
        • 2021-11-04
        • 1970-01-01
        • 2016-11-25
        相关资源
        最近更新 更多