Java 安全性筆記：語言層面的安全機制

前言

花了三天整理 Java 沙箱安全機制，發現 Java 語言本身的安全設計更引人入勝。作業系統層面的權限管理往往需要填表、簽核、等待核准，而 Java 語言透過編譯器、位元組碼驗證器、執行期檢查，在語言層面建立了多重防線。本文聚焦 Java 語言本身的安全特性（排除 JNI 原生碼），探討其如何保護類別封裝、序列化、編譯與執行期安全。

一、存取修飾子：封裝的第一道防線

public、protected、private、package-private (預設) 四種存取層級，搭配 final 防止繼承/覆寫，構成封裝基石。優於 C++ 的指標操作：Java **無指標**，開發者無法透過記憶體位址直接讀寫私有欄位，從語言層面阻斷「偷窺」行為。

二、型別安全與強制轉型限制

• **禁止任意型別轉換**：只允許繼承關係間的上下轉型，編譯器與 JVM 雙重檢查。
• **陣列邊界檢查**：執行期自動檢查 ArrayIndexOutOfBoundsException，杜絕緩衝區溢位攻擊根源。
• **物件轉型檢查**：ClassCastException 確保型別一致性。

雖然記憶體偵錯工具仍可掃描堆疊，但語言層面已大幅提高攻擊門檻。

三、物件序列化風險與對策

序列化將物件狀態寫入檔案/網路，若被惡意篡改反序列化，可能導致：

• 繞過建構子邏輯建立非法狀態物件
• 洩露敏感欄位 (密碼、金鑰、Session ID)
• 觸發任意程式碼執行 (已知 Gadget Chain 攻擊)

防護策略

1. 避免序列化敏感類別：實作 Serializable 前三思，敏感資料標記 transient。
2. 自訂序列化邏輯：實作 writeObject/readObject 加密敏感欄位、驗證不變條件。
3. 使用序列化過濾器 (JDK 9+)：ObjectInputFilter 白名單/黑名單類別，阻擋惡意類別載入。
4. 考慮替代方案：JSON (Jackson/Gson)、Protocol Buffers、Avro 等結構化資料格式，避免 Java 原生序列化風險。

四、編譯器與位元組碼驗證器

javac 靜態檢查

• 型別檢查、存取權限檢查、未處理檢查式異常
• 功能有限：無法檢測邏輯錯誤、資源洩漏、並發問題

JVM 位元組碼驗證器 (Bytecode Verifier)

類別載入階段執行四階段驗證：

1. 檔案格式：Magic number (0xCAFEBABE)、常數池、屬性結構合法性
2. 元資料：最終類別不可繼承、final 方法不可覆寫、方法簽名一致性
3. 位元組碼：運算元組類型匹配、堆疊溢位/下溢、跳轉目標合法、區域變數型別正確
4. 符號參考：解析類別/方法/欄位是否存在、存取權限

關鍵特性：驗證發生在**類別首次使用時 (Just-in-time)**，非載入時一次性完成，平衡啟動速度與安全性。真正的執行期檢查僅包含陣列邊界與物件轉型。

五、安全管理器與權限架構

SecurityManager (JDK 17 標記棄用) 歷來是沙箱核心，透過 Permission 體系控制：

• FilePermission、SocketPermission、PropertyPermission、RuntimePermission 等
• 政策檔 java.policy 授予程式碼來源 (CodeSource) 權限

現代應用多採用容器化、OS 層面沙箱 (seccomp, gVisor, Kata Containers) 替代，但理解權限模型仍有助於遷移舊系統。

六、總結：Java 安全性的無所不在

「Java 安全觀念無所不在，其實作亦無所不在。」

從語言語法 (存取修飾子、final)、編譯期檢查、位元組碼驗證、執行期邊界/轉型檢查、序列化防護、到權限架構，Java 在每一層都內建安全防護。開發者應：

1. 善用 private/final 封裝不變條件
2. 謹慎實作 Serializable，優先選用安全序列化格式
3. 理解類別載入與驗證機制，排查 VerifyError、ClassCastException 根因
4. 遷移至現代容器安全模型，逐步移除 SecurityManager 依賴

語言層面的安全設計讓開發者能專注業務邏輯，同時擁有底層防護——這正是 Java 在企業級應用長盛不衰的關鍵原因之一。