Java序列化的狀態
多年來，Java的序列化功能飽受 安全漏洞 和zero-day攻擊，為此贏得了“ 持續奉獻的禮物 ”和“ 第四個不可饒恕的詛咒 ”的綽號。
作為回應，OpenJDK貢獻者團隊討論了一些用于限制序列化訪問的方法，例如將其 提取到可以被移除的jigsaw模塊中 ，讓黑客無法攻擊那些不存在的東西。
一些文章（例如“ 序列化必須死 ”）提出了這樣的建議，將有助于防止 某些流行軟件（如VCenter 6.5）的漏洞被利用 。
什么是序列化？自從1997年發布 JDK 1.1 以來，序列化已經存在于Java平臺中。
它用于在套接字之間共享對象表示，或者將對象及其狀態保存起來以供將來使用（反序列化）。
在JDK 10及更低版本中，序列化作為java.base包和java.io.Serializable方法的一部分存在于所有的系統中。
GeeksForGeeks對 序列化的工作原理 進行了詳細的描述。
有關更多如何使用序列化的代碼示例，可以參看Baeldung對 Java序列化的介紹 。
序列化的挑戰和局限序列化的局限主要表現在以下兩個方面：
出現了新的對象傳輸策略，例如JSON、XML、Apache Avro、Protocol Buffers等。 1997年的序列化策略無法預見現代互聯網服務的構建和攻擊方式。進行序列化漏洞攻擊的基本前提是找到對反序列化的數據執行特權操作的類，然后傳給它們惡意的代碼。為了理解完整的攻擊過程，可以參看Matthias Kaiser在2015年發表的“ Exploiting Deserialization Vulnerabilities in Java ”一文，其中幻燈片第14頁開始提供了相關示例。
其他大部分與序列號有關的安全研究 都是基于Chris Frohoff、Gabriel Lawrence和Alvaro Munoz的工作成果。
序列化在哪里？如何知道我的應用程序是否用到了序列化？要移除序列化，需要從java.io包開始，這個包是java.base模塊的一部分。最常見的使用場景是：
實現Serializable接口和（可選）serialversionuid長整型字段。 使用ObjectInputStream或ObjectOutputStream。 使用 嚴重依賴序列化 的庫，例如：Xstream、Kryo、BlazeDS和 大多數應用程序服務器 。使用這些方法的開發人員應考慮使用其他存儲和讀回數據的替代方法。Eishay Smith發布了 幾個不同序列化庫的性能指標 。在評估性能時，需要在基準度量指標中包含安全方面的考慮。默認的Java序列化“更快”一些，但漏洞也會以同樣的速度找上門來。
我們該如何降低序列化缺陷的影響？項目Amber 包含了一個關于將序列化API隔離出來的討論。我們的想法是將序列化從java.base移動到單獨的模塊，這樣應用程序就可以完全移除它。在確定 JDK 11功能集 時并沒有針對該提議得出任何結果，但可能會在未來的Java版本中繼續進行討論。
通過運行時保護來減少序列化暴露一個可以監控風險并自動化可重復安全專業知識的系統對于很多企業來說都是很有用的。Java應用程序可以將JVMTI工具嵌入到安全監控系統中，通過插樁的方式將傳感器植入到應用程序中。Contrast Security是這個領域的一個免費產品，它是JavaOne大會的 Duke’s Choice大獎得主 。與其他軟件項目（如MySQL或GraalVM）類似， Contrast Security的社區版 對開發人員是免費的。
將運行時插樁應用在Java安全性上的好處是它不需要修改代碼，并且可以直接集成到JRE中。
它有點類似于面向切面編程，將非侵入式字節碼嵌入到源端（遠程數據進入應用程序的入口）、接收端（以不安全的方式使用數據）和轉移（安全跟蹤需要從一個對象移動到另一個對象）。
通過集成每個“接收端”（如ObjectInputStream），運行時保護機制可以添加額外的功能。在從JDK 9移植反序列化過濾器之前，這個功能對序列化和其他攻擊的類型（如SQL注入）來說至關重要。
集成這個運行時保護機制只需要修改啟動標志，將javaagent添加到啟動選項中。例如，在Tomcat中，可以在bin/setenv.sh中添加這個標志：
CATALINA_OPTS=-javaagent:/Users/ecostlow/Downloads/Contrast/contrast.jar
啟動后，Tomcat將會初始化運行時保護機制，并將其注入到應用程序中。關注點的分離讓應用程序可以專注在業務邏輯上，而安全分析器可以在正確的位置處理安全性。
其他有用的安全技術在進行維護時，可以不需要手動列出一長串東西，而是使用像 OWASP Dependency-Check 這樣的系統，它可以識別出已知安全漏洞的依賴關系，并提示進行升級。也可以考慮通過像 DependABot 這樣的系統進行庫的自動更新。
雖然用意很好，但默認的 Oracle序列化過濾器 存在與SecurityManager和相關沙箱漏洞相同的設計缺陷。因為需要混淆角色權限并要求提前了解不可知的事物，限制了這個功能的大規模采用：系統管理員不知道代碼的內容，所以無法列出類文件，而開發人員不了解環境，甚至DevOps團隊通常也不知道系統其他部分（如應用程序服務器）的需求。
移除未使用模塊的安全隱患Java 9的模塊化JDK能夠 創建自定義運行時鏡像 ，移除不必要的模塊，可以使用名為jlink的工具將其移除。這種方法的好處是黑客無法攻擊那些不存在的東西。
從提出模塊化序列化到應用程序能夠實際使用以及使用其他序列化的新功能需要一段時間，但正如一句諺語所說：“種樹的最佳時間是二十年前，其次是現在”。
剝離Java的原生序列化功能還應該為大多數應用程序和微服務提供更好的互操作性。通過使用標準格式（如JSON或XML），開發人員可以更輕松地在使用不同語言開發的服務之間進行通信——與Java 7的二進制blob相比，python微服務通常具有更好的讀取JSON文檔的集成能力。不過，雖然JSON格式簡化了對象共享，針對Java和.NET解析器的“ Friday the 13th JSON attacks ”證明了銀彈是不存在的（ 白皮書 ）。
在進行剝離之前，序列化讓然保留在java.base中。這些技術可以降低與其他模塊相關的風險，在序列化被模塊化之后，仍然可以使用這些技術。
為Apache Tomcat 8.5.31模塊化JDK 10的示例在這個示例中，我們將使用模塊化的JRE來運行Apache Tomcat，并移除任何不需要的JDK模塊。我們將得到一個自定義的JRE，它具有更小的攻擊表面，仍然能夠用于運行應用程序。
確定需要用到哪些模塊第一步是檢查應用程序實際使用的模塊。OpenJDK工具jdeps可以對JAR文件的字節碼執行掃描，并列出這些模塊。像大多數用戶一樣，對于那些不是自己編寫的代碼，我們根本就不知道它們需要哪些依賴項或模塊。因此，我使用掃描器來檢測并生成報告。
列出單個JAR文件所需模塊的命令是：
jdeps -s JarFile.jar
它將列出模塊信息：
tomcat-coyote.jar -> java.basetomcat-coyote.jar -> java.managementtomcat-coyote.jar -> not found
最后，每個模塊（右邊的部分）都應該被加入到一個模塊文件中，成為應用程序的基本模塊。這個文件叫作module-info.java，文件名帶有連字符，表示不遵循標準的Java約定，需要進行特殊處理。
下面的命令組合將所有模塊列在一個可用的文件中，在Tomcat根目錄運行這組命令：
find . -name *.jar ! -path './webapps/*' ! -path './temp/*' -exec jdeps -s {} ; | sed -En 's/.* -> (.*)/ requires 1;/p' | sort | uniq | grep -v 'not found' | xargs -0 printf 'module com.infoq.jdk.TomcatModuleExample{n%s}n'
這組命令的輸出將被寫入lib/module-info.java文件，如下所示：
module com.infoq.jdk.TomcatModuleExample{ requires java.base; requires java.compiler; requires java.desktop; requires java.instrument; requires java.logging; requires java.management; requires java.naming; requires java.security.jgss; requires java.sql; requires java.xml.ws.annotation; requires java.xml.ws; requires java.xml;}
這個列表比整個Java模塊列表要短得多。
下一步是將這個文件放入JAR中：
javac lib/module-info.javajar -cf lib/Tomcat.jar lib/module-info.class
最后，為應用程序創建一個JRE：
jlink --module-path lib:$JAVA_HOME/jmods --add-modules ThanksInfoQ_Costlow --output dist
這個命令的輸出是一個運行時，包含了運行應用程序所需的恰到好處的模塊，沒有任何性能開銷，也沒有了未使用模塊中可能存在的安全風險。
與基礎JDK 10相比，只用了98個核心模塊中的19個。
java --list-modulescom.infoq.jdk.TomcatModuleExamplejava.activation@10.0.1java.base@10.0.1java.compiler@10.0.1java.datatransfer@10.0.1java.desktop@10.0.1java.instrument@10.0.1java.logging@10.0.1java.management@10.0.1java.naming@10.0.1java.prefs@10.0.1java.security.jgss@10.0.1java.security.sasl@10.0.1java.sql@10.0.1java.xml@10.0.1java.xml.bind@10.0.1java.xml.ws@10.0.1java.xml.ws.annotation@10.0.1jdk.httpserver@10.0.1jdk.unsupported@10.0.1
運行這個命令后，就可以使用dist文件夾中的運行時來運行應用程序。
看看這個列表：部署插件（applet）消失了，JDBC（SQL）消失了，JavaFX也不見了，很多其他模塊也消失了。從性能角度來看，這些模塊不再產生任何影響。從安全角度來看，黑客無法攻擊那些不存在的東西。保留應用程序所需的模塊非常重要，因為如果缺少這些模塊，應用程序也無法正常運行。
關于作者
Erik Costlow 是甲骨文的Java 8和9產品經理，專注于安全性和性能。他的安全專業知識涉及威脅建模、代碼分析和安全傳感器增強。在進入技術領域之前，Erik是一位馬戲團演員，可以在三輪垂直獨輪車上玩火。
查看英文原文： The State of Java Serialization
來自：http://www.infoq.com/cn/articles/java-serialization-aug18
相關文章：
網公網安備