转载

Java序列化漏洞对数百万应用造成威胁

Java环境中一个广泛存在的漏洞使得数以千计的企业暴露出严重的弱点。尽管缺乏一个好名字- ala Heartbleed，Shellshock，和POODLE——利用这个漏洞，黑客能够在互联网上摧毁很多东西。并且没有简单的方法来保护大量的应用程序集。这意味着各组织机构需要花很长的时间来找到并修复这个漏洞造成的所有不同的变种。

Contrast Security有一个解决方案，使用专利，以及强大的应用程序安全工具平台，能既快速又准确得找到解决这个问题。Contrast用IAST（交互式应用安全测试）的方法识别开发过程中的问题。Contrast也可以通过RASP（运行时应用自我保护）功能无需重新编码就能迅速打包问题或产生安全警报，以此来保护生产中的应用程序。在应用程序服务器上安装一个Contrast代理可以解决该服务器上所有Java应用相关的问题。

想要了解更多关于Java序列化漏洞的细节，请继续阅读。序列化是开发人员用以将数据结构转换为易于传输或存储的字节流的方法。反序列化则是相反的过程，在接收数据时发生。序列化的安全争议由来已久了——最早估计要到2010年以前了。请参阅完整的历史http://www.ibm.com/developerworks/library/se-lookahead。就在最近，一堆不同的Java环境被公开了漏洞——不幸的是，这似乎是使安全事件发生的唯一方法。

这些漏洞很严重，可以影响一个完整的远程命令执行过程——所有运行有接收序列化对象的应用程序的主机。

在Java中，从一个序列化流中读取一个BitSet非常简单：

ObjectInputStream in = new ObjectInputStream( inputStream );  return (Data)in.readObject();

问题是，在解码之前无法知道你到底解序列化出的是什么。所以攻击者可以序列化一堆恶意对象并将它们发送到您的应用程序。当你调用readobject()时，那就太晚了。在某些方面，它就像一个XXE问题，攻击者可以利用恶意文档在XML解析时生成攻击程序。但在这种情况下，没有简单的方法来关闭文档处理。

我们需要的是一种允许反序列化但不给攻击者创建任意类实例的机会。比如像这样：

List<Class<?>> safeClasses = Arrays.asList( BitSet.class, ArrayList.class );

这允许开发人员指定返回类型和他们希望序列化的类列表。当一些未经授权的类出现时，我们应该抛出SecurityException并阻塞解析企图。事实证明要实现这样的事情并不太难。我们只需要重载ObjectInputStream的一点实现。

这里有一个可以用来替代调用readObjec

@SuppressWarnings("unchecked")     public static <T> T safeReadObject(Class<?> type, List<Class<?>> safeClasses, InputStream in ) throws IOException, ClassNotFoundException {         return (T) new ObjectInputStream(in) {             protected Class<?> resolveClass(ObjectStreamClass d) throws IOException, ClassNotFoundException {                 Class<?> clazz = super.resolveClass(d);                 if (clazz.isArray()                     || clazz.isPrimitive()                     || clazz.equals(type)                     || clazz.equals(String.class)                     || Number.class.isAssignableFrom(clazz)                     || safeClasses.contains(clazz)) return clazz;                 throw new SecurityException("Attempt to deserialize unauthorized " + clazz);             }         }.readObject();     }

这种方法重写了ObjectInPutStream中的readClass()方法并增加检查以确保任何作为反序列化过程一部分的已加载类要么是不可利用的要么在安全类的白名单中。作为另一种选择，你也可以将你不了解的类加入到黑名单中–那些曾经被用于攻击的类–但这种方法是注定要失败的。有太多的所谓的“小工具”在现代应用程序的类路径中有效地列出所有可能的攻击路径。

这个简单的检查无需大量改动代码就能保护应用程序。第一步是搜索你的代码，找到所有脆弱的地方——明天，所有Contrast用户都会收到一个更新信息。你会知道你的应用组程序中所有由于反序列化不可信任的数据而造成的漏洞！

原文 http://www.importnew.com/19963.html

正文到此结束