谷歌怎么做公司网站,wordpress积分阅读,常州网站外包,庆阳东道设计本文将重点介绍如何解决与第三方库相关的问题 不能被规避 难以排除/绕过/替换 只需不提供错误修正 在这种情况下#xff0c;解决问题仍然是一项艰巨的任务。 作为这种情况的诱因#xff0c;请考虑对“哈希索引”数据结构的攻击#xff0c;例如java.util.Hashtable和java… 本文将重点介绍如何解决与第三方库相关的问题 不能被规避 难以排除/绕过/替换 只需不提供错误修正 在这种情况下解决问题仍然是一项艰巨的任务。 作为这种情况的诱因请考虑对“哈希索引”数据结构的攻击例如java.util.Hashtable和java.util.HashMap 对于不熟悉此类攻击的人我建议查看以下内容28C3 对Web应用程序进行拒绝服务攻击变得容易 。 长话短说核心问题是使用非加密哈希函数在其中查找冲突很容易。 根本原因隐藏在java.lang.String.hashCode函数中。 显而易见的方法是修补java.lang.String类这很困难原因有两个 它包含本机代码 它属于Java核心类这些Java核心类随Java安装一起提供因此不受我们的控制 第一点将迫使我们修补体系结构和特定于OS的库我们应该在可能的情况下规避这些库。 第二点是正确的但是它会更灵活一些我们将在下面看到。 好的让我们重新考虑修补本机很脏我们不急于采用这种方式–我们必须为不愿意修复其代码的其他人在本例中为SDK SDK库做一些工作。 尝试 哈希问题涉及到java.util.Hashtable和java.util.HashMap类它们不使用任何本机代码。 修补这些类非常容易因为足以为所有体系结构和OS提供一个编译的类。 我们可以使用提供的错误解决方案之一并用固定版本调整或替换原始类。 困难在于在不接触核心库的情况下修补VM –我想如果用户必须更改其JVM安装的一部分或者更糟糕的是我们的应用程序在安装过程中自动执行此操作用户将非常失望。 在某些情况下进一步引入新的自定义类加载器可能会很困难。 我们需要的是一种动态修补我们的单个应用程序的解决方案–替换有问题的类不要碰其他任何东西。 如果我们透明地执行此操作则其他软件部件甚至都不会识别任何更改在最佳情况下并保持与类的接口而无需进行任何修改。 可以通过滥用Java Instrumentation API轻松地完成此操作。 引用JavaDoc “提供允许Java编程语言代理检测运行在JVM上的程序的服务。” 这正是我们所需要的 概念证明 首先我们需要一个示例应用程序来演示该概念 public class StringChanger {public static void main(String[] args) {System.out.println(A.shout());}}public class A {public static String shout() {return A;}
} 运行此类时它仅输出A 应用我们的“补丁”之后我们希望获得以下输出已补丁 “修补的代码如下所示 public class A {public static String shout() {return Apatched;}
} 进一步我们需要一个“代理”来管理所使用的类并修补正确的类 final public class PatchingAgent implements ClassFileTransformer {private static byte[] PATCHED_BYTES;private static final String PATH_TO_FILE Apatched.class;private static final String CLASS_TO_PATCH stringchanger/A;public PatchingAgent() throws FileNotFoundException, IOException {if (PATCHED_BYTES null) {PATCHED_BYTES readPatchedCode(PATH_TO_FILE);}}public static void premain(String agentArgument,final Instrumentation instrumentation) { System.out.println(Initializing hot patcher...);PatchingAgent agent null;try {agent new PatchingAgent();} catch(Exception e) {System.out.println(terrible things happened....);}instrumentation.addTransformer(agent);}Overridepublic byte[] transform(final ClassLoader loader, String className,final Class classBeingRedefined, final ProtectionDomain protectionDomain,final byte[] classfileBuffer) throws IllegalClassFormatException {byte[] result null;if (className.equals(CLASS_TO_PATCH)) {System.out.println(Patching... className);result PATCHED_BYTES;}return result;}private byte[] readPatchedCode(final String path)throws FileNotFoundException, IOException {...}
} 不用担心–我不会在实施细节上打扰您因为这只是PoC代码远非完美巧妙快速而简洁。 除了我因为此时太懒而赶上 Exception以外我不过滤输入构建深拷贝防御性编程作为流行语这实际上不应被视为生产代码。 公共PatchingAgent 初始化代理在这种情况下将获取修补的A.class文件的字节。修补的类已编译并存储在我们可以访问它的位置。 公共静态无效premain… 在JVM初始化并准备代理后将调用此方法。 公共字节[]变换… 每当定义一个类时例如通过ClassLoader.defineClass …该函数都将被调用并且可以转换已处理的类字节 [] classfileBuffer 。 可以看出我们将为stringchanger包中的A类执行此操作。 您不受限制如何转换类只要它仍然是有效的Java 类 –例如您可以利用字节码修改框架…–为使事情简单我们假设我们将旧字节 []替换为修补的类之一只需将完整的修补A.class文件缓存到字节 []中。 这就是修补程序编码部分的全部内容……最后我们必须用一个特殊的manifest.mf文件构建一个jar容器该文件告诉JVM如何调用该代理。 清单版本1.0 X-COMMENTMain-Class将通过构建自动添加 Premain-Classstringchanger.PatchingAgent 构建完这个jar之后我们可以尝试PoC应用程序。 首先我们将在没有调用代理的必要JVM参数的情况下调用它 跑 一个 建立成功总时间0秒 它的行为符合预期并输出未修补类定义的输出。 现在我们将使用神奇的JVM参数来尝试调用代理-javaagentStringChanger.jar 跑 初始化热补丁程序… 读取修补文件。 修补…换弦器/ A 已分配 建立成功总时间0秒 Voilà该代码已成功进行了实时修补 如我们所见可以动态地对JVM进行热补丁而不用触摸交付的代码。 必须要做的是开发修补程序和修补的类。 目前我还不了解性能评估数据。 因此我不确定该解决方案对生产系统的实用性以及对应用程序性能的影响程度。 明确地说这不是一个优雅的解决方案–至少它很脏 最好的方法是修补根本原因但只要没有供应商修复程序开发人员就可以通过热修补来防止其软件运行而无需重写使用易受攻击类的每一行。 最后我希望提出意见改进或只是更好的解决方案。 非常感谢Juraj Somorovsky与我在这个问题上共同努力。 参考 JCG合作伙伴 在运行时修补Java Christopher Meyer讨论了Java安全性和相关主题 。 翻译自: https://www.javacodegeeks.com/2012/02/patching-java-at-runtime.html
