您的Java代碼安全嗎—還是暴露在外？

摘要：雖然客戶仍然很關心您為他們構建的應用程序的可伸縮性和可用性,但他們可能變得也很關心安全性,而且要求特別嚴格.應用程序可能容易受到兩類安全性威脅的攻擊：靜態和動態.雖然開發人員不能完全控制動態威脅,但在開發應用程序時,您可以採取一些預防措施來消除靜態威脅.本文概括並解釋了 13 種類型的靜態暴露 ― 它們是系統中的缺陷,它使系統暴露在想要篡奪該系統的特權的攻擊者面前.您將學會如何處理這些暴露,以及如何發現（如果不處理這些暴露）這些暴露可能造成的影響.

在開發Java Web應用程序時,您需要確保應用程序擁有完善的安全性特徵補充.這裡在談到Java安全性時,我們並不談及Java 語言提供的安全性 API,也不涉及使用Java代碼來保護應用程序.本文將著重討論可能潛伏在您的 Java 應用程序中的 安全性暴露.安全性暴露是系統中的缺陷,它使系統無法 ― 即使系統被正常使用 ― 防止攻擊者篡奪對系統的特權、控制系統的運行、危及系統上的數據安全或者假冒未經授權的信任.相對於安全性暴露,許多開發人員更加關心網站的感官效果.

毫無疑問,客戶現在既嚴格地關注性能、可伸縮性和可用性也嚴格地關注安全性.應用程序可能容易受到兩類安全性威脅的攻擊： 動態和 靜態.動態威脅是那些同未經授權進入系統有關的威脅,或那些同跨越網路傳輸的數據的完整性、隱私和機密性有關的威脅.這些威脅同應用程序的功能代碼沒有多大關係；使用加密、加密術和認證技術來消除這些威脅.相比之下,靜態威脅卻同應用程序的功能代碼 有關；它們同進入系統的授權用戶所做的事情有關.未知用戶闖入系統是動態威脅的一個示例；授權用戶以未授權方式操作系統內的代碼或數據是靜態威脅的示例.應用程序開發人員並不能完全控制動態威脅；但開發人員在構建應用程序時卻可以採取預防措施來消除靜態威脅.

在本文中,我們討論了對付 13 種不同靜態暴露的技巧.對於每種暴露,我們解釋了不處理這些安全性問題所造成的影響.我們還為您推薦了一些準則,要開發不受這些靜態安全性暴露威脅的、健壯且安全的 Java 應用程序,您應該遵循這些準則.一有合適的時機,我們就提供代碼樣本（既有暴露的代碼也有無暴露的代碼）.

對付高嚴重性暴露的技巧

請遵循下列建議以避免高嚴重性靜態安全性暴露：

限制對變數的訪問
讓每個類和方法都成為 final,除非有足夠的理由不這樣做
不要依賴包作用域
使類不可克隆
使類不可序列化

使類不可逆序列化
避免硬編碼敏感數據
查找惡意代碼
限制對變數的訪問

如果將變數聲明為 public,那麼外部代碼就可以操作該變數.這可能會導致安全性暴露.

影響

如果實例變數為 public ,那麼就可以在類實例上直接訪問和操作該實例變數.將實例變數聲明為 protected 並不一定能解決這一問題：雖然不可能直接在類實例基礎上訪問這樣的變數,但仍然可以從派生類訪問這個變數.

清單 1 演示了帶有 public 變數的代碼,變數為 public 的,它暴露了.

清單 1. 帶有 public 變數的代碼

class Test { public int id; protected String name; Test(){ id = 1; name = "hello world"; } //code } public class MyClass extends Test{ public void methodIllegalSet(String name){ this.name = name; // this should not be allowed } public static void main(String[] args){ Test obj = new Test(); obj.id = 123; // this should not be allowed MyClass mc = new MyClass(); mc.methodIllegalSet("Illegal Set Value"); } }

建議

一般來說,應該使用取值方法而不是 public 變數.按照具體問題具體對待的原則,在確定哪些變數特別重要因而應該聲明為 private 時,請將編碼的方便程度及成本同安全性需要加以比較.清單 2 演示了以下列方式來使之安全的代碼：

清單 2. 不帶有 public 變數的代碼

class Test { private int id; private String name; Test(){ id = 1; name = "hello world"; } public void setId(int id){ this.id = id; } public void setName(String name){ this.name = name; } public int getId(){ return id; } public String getName(){ return name; } }

讓每個類和方法都為 final

不允許擴展的類和方法應該聲明為 final .這樣做防止了系統外的代碼擴展類並修改類的行為.

影響

僅僅將類聲明為非 public 並不能防止攻擊者擴展類,仍然可以從它自己的包內訪問該類.

建議

讓每個類和方法都成為 final,除非有足夠的理由不這樣做.按此建議,我們要求您放棄可擴展性,雖然它是使用諸如 Java 語言之類的面向對象語言的主要優點之一.在試圖提供安全性時,可擴展性卻成了您的敵人；可擴展性只會為攻擊者提供更多給您帶來麻煩的方法.

不要依賴包作用域

沒有顯式地標註為 public 、 private 或 protected 的類、方法和變數在它們自己的包內是可訪問的.

影響

如果 Java 包不是封閉的,那麼攻擊者就可以向包內引入新類並使用該新類來訪問您想保護的內容.諸如 java.lang 之類的一些包預設是封閉的,一些 JVM 也讓您封閉自己的包.然而,您最好假定包是不封閉的.

建議

從軟體工程觀點來看,包作用域具有重要意義,它可以阻止對您想隱藏的內容進行偶然的、無意中的訪問.但不要依靠它來獲取安全性.應該將類、方法和變數顯式標註為 public 、 private 或 protected 中適合您特定需求的那種.

使類不可克隆

克隆允許繞過構造器而輕易地複製類實例.

影響

即使您沒有有意使類可克隆,外部源仍然可以定義您的類的子類,並使該子類實現 java.lang.Cloneable .這就讓攻擊者創建了您的類的新實例.拷貝現有對象的內存映象生成了新的實例；雖然這樣做有時候是生成新對象的可接受方法,但是大多數時候是不可接受的.清單 3 說明了可克隆而暴露的代碼：

清單 3. 可克隆代碼

class MyClass{ private int id; private String name; public MyClass(){ id=1; name="HaryPorter"; } public MyClass(int id,String name){ this.id=id; this.name=name; } public void display(){ System.out.println("Id =" id "n" "Name=" name); } } // hackers code to clone the user class public class Hacker extends MyClass implements Cloneable { public static void main(String[] args){ Hacker hack=new Hacker(); try{ MyClass o=(MyClass)hack.clone(); o.display(); } catch(CloneNotSupportedException e){ e.printStackTrace(); } } }

建議

要防止類被克隆,可以將清單 4 中所示的方法添加到您的類中：

清單 4. 使您的代碼不可克隆

public final Object clone() throws java.lang.CloneNotSupportedException{ throw new java.lang.CloneNotSupportedException(); }

如果想讓您的類可克隆並且您已經考慮了這一選擇的後果,那麼您仍然可以保護您的類.要做到這一點,請在您的類中定義一個為 final 的克隆方法,並讓它依賴於您的一個超類中的一個非 final 克隆方法,如清單 5 中所示：

清單 5. 以安全的方式使您的代碼可克隆

public final Object clone() throws java.lang.CloneNotSupportedException { super.clone(); }

類中出現 clone（） 方法防止攻擊者重新定義您的 clone 方法.

使類不可序列化

序列化允許將類實例中的數據保存在外部文件中.闖入代碼可以克隆或複製實例,然後對它進行序列化.

影響

序列化是令人擔憂的,它允許外部源獲取對您的對象的內部狀態的控制.這一外部源可以將您的對象之一序列化成攻擊者隨後可以讀取的位元組數組,這是的攻擊者可以完全審查您的對象的內部狀態,包括您標記為 private 的任何欄位.它也允許攻擊者訪問您引用的任何對象的內部狀態.

建議

要防止類中的對象被序列化,請在類中定義清單 6 中的 writeObject（） 方法：

清單 6. 防止對象序列化

private final void writeObject(ObjectOutputStream out) throws java.io.NotSerializableException { throw new java.io.NotSerializableException("This object cannot be serialized"); }

通過將 writeObject（） 方法聲明為 final,防止了攻擊者覆蓋該方法.

使類不可逆序列化

通過使用逆序列化,攻擊者可以用外部數據或位元組流來實例化類.

影響

不管類是否可以序列化,都可以對它進行逆序列化.外部源可以創建逆序列化成類實例的位元組序列.這種可能為您帶來了大量風險,您不能控制逆序列化對象的狀態.請將逆序列化作為您的對象的另一種公共構造器 ― 一種您無法控制的構造器.

建議

要防止對對象的逆序列化,應該在您的類中定義清單 7 中的 readObject（） 方法：

清單 7. 防止對象逆序列化

private final void readObject(ObjectInputStream in) throws java.io.NotSerializableException { throw new java.io.NotSerializableException("This object cannot be deserialized"); }

通過將該方法聲明為 final ,防止了攻擊者覆蓋該方法.

避免硬編碼敏感數據

您可能會嘗試將諸如加密密鑰之類的秘密存放在您的應用程序或庫的代碼.對於你們開發人員來說,這樣做通常會把事情變得更簡單.

影響

任何運行您的代碼的人都可以完全訪問以這種方法存儲的秘密.沒有什麼東西可以防止心懷叵測的程序員或虛擬機窺探您的代碼並了解其秘密.

建議

可以以一種只可被您解密的方式將秘密存儲在您代碼中.在這種情形下,秘密只在於您的代碼所使用的演算法.這樣做沒有多大壞處,但不要洋洋得意,認為這樣做提供了牢固的保護.您可以 遮掩您的源代碼或位元組碼 ― 也就是,以一種為了解密必須知道加密格式的方法對源代碼或位元組碼進行加密 ― 但攻擊者極有可能能夠推斷出加密格式,對遮掩的代碼進行逆向工程從而揭露其秘密.

這一問題的一種可能解決方案是：將敏感數據保存在屬性文件中,無論什麼時候需要這些數據,都可以從該文件讀取.如果數據極其敏感,那麼在訪問屬性文件時,您的應用程序應該使用一些加密／解密技術.

查找惡意代碼

從事某個項目的某個心懷叵測的開發人員可能故意引入易受攻擊的代碼,打算日後利用它.這樣的代碼在初始化時可能會啟動一個後台進程,該進程可以為闖入者開後門.它也可以更改一些敏感數據.

這樣的惡意代碼有三類：

類中的 main 方法
定義過且未使用的方法
註釋中的死代碼

影響

入口點程序可能很危險而且有惡意.通常,Java 開發人員往往在其類中編寫 main（） 方法,這有助於測試單個類的功能.當類從測試轉移到生產環境時,帶有 main（） 方法的類就成為了對應用程序的潛在威脅,闖入者將它們用作入口點.

請檢查代碼中是否有未使用的方法出現.這些方法在測試期間將會通過所有的安全檢查,在代碼中不調用它們 ― 但它們可能含有硬編碼在它們內部的敏感數據（雖然是測試數據）.引入一小段代碼的攻擊者隨後可能調用這樣的方法.

避免最終應用程序中的死代碼（註釋內的代碼）.如果闖入者去掉了對這樣的代碼的註釋,那麼代碼可能會影響系統的功能性.

可以在清單 8 中看到所有三種類型的惡意代碼的示例：

清單 8. 潛在惡意的 Java 代碼

public void unusedMethod(){ // code written to harm the system } public void usedMethod(){ //unusedMethod(); //code in comment put with bad intentions, //might affect the system if uncommented // int x = 100; // x=x 10; //Code in comment, might affect the //functionality of the system if uncommented }

建議

應該將（除啟動應用程序的 main（） 方法之外的） main（） 方法、未使用的方法以及死代碼從應用程序代碼中除去.在軟體交付使用之前,主要開發人員應該對敏感應用程序進行一次全面的代碼評審.應該使用「Stub」或「dummy」類代替 main（） 方法以測試應用程序的功能.

對付中等嚴重性暴露的技巧

請遵循下列建議以避免中等嚴重性靜態安全性暴露：

不要依賴初始化
不要通過名稱來比較類
不要使用內部類
不要依賴初始化

您可以不運行構造器而分配對象.這些對象使用起來不安全,它們不是通過構造器初始化的.

影響

在初始化時驗證對象確保了數據的完整性.

例如,請想象為客戶創建新帳戶的 Account 對象.只有在 Account 期初餘額大於 0 時,才可以開設新帳戶.可以在構造器里執行這樣的驗證.有些人未執行構造器而創建 Account 對象,他可能創建了一個具有一些負值的新帳戶,這樣會使系統不一致,容易受到進一步的干預.

建議

在使用對象之前,請檢查對象的初始化過程.要做到這一點,每個類都應該有一個在構造器中設置的私有布爾標誌,如清單 9 中的類所示.在每個非 static 方法中,代碼在任何進一步執行之前都應該檢查該標誌的值.如果該標誌的值為 true ,那麼控制應該進一步繼續；否則,控制應該拋出一個例外並停止執行.那些從構造器調用的方法將不會檢查初始化的變數,在調用方法時沒有設置標誌.這些方法並不檢查標誌,應該將它們聲明為 private 以防止用戶直接訪問它們.

清單 9. 使用布爾標誌以檢查初始化過程

public class MyClass{ private boolean initialized = false; //Other variables public MyClass (){ //variable initialization method1(); initialized = true; } private void method1(){ //no need to check for initialization variable //code } public void method2(){ try{ if(initialized==true){ //proceed with the business logic } else{ throw new Exception("Illegal State Of the object"); } }catch(Exception e){ e.printStackTrace(); } } }

如果對象由逆序列化進行初始化,那麼上面討論的驗證機制將難以奏效,在該過程中並不調用構造器.在這種情況下,類應該實現 ObjectInputValidation 介面：

清單 10. 實現 ObjectInputValidation

interface java.io.ObjectInputValidation { public void validateObject() throws InvalidObjectException; }

所有驗證都應該在 validateObject（） 方法中執行.對象還必須調用 ObjectInputStream.RegisterValidation（） 方法以為逆序列化對象之後的驗證進行註冊. RegisterValidation（） 的第一個參數是實現 validateObject（） 的對象,通常是對對象自身的引用.註：任何實現 validateObject（） 的對象都可能充當對象驗證器,但對象通常驗證它自己對其它對象的引用. RegisterValidation（） 的第二個參數是一個確定回調順序的整數優先順序,優先順序數字大的比優先順序數字小的先回調.同一優先順序內的回調順序則不確定.

當對象已逆序列化時, ObjectInputStream 按照從高到低的優先順序順序調用每個已註冊對象上的 validateObject（） .

不要通過名稱來比較類

有時候,您可能需要比較兩個對象的類,以確定它們是否相同；或者,您可能想看看某個對象是否是某個特定類的實例. JVM 可能包括多個具有相同名稱的類（具有相同名稱但卻在不同包內的類）,您不應該根據名稱來比較類.

影響

如果根據名稱來比較類,您可能無意中將您不希望授予別人的權利授予了闖入者的類,闖入者可以定義與您的類同名的類.

例如,請假設您想確定某個對象是否是類 com.bar.Foo 的實例.清單 11 演示了完成這一任務的錯誤方法：

清單 11. 比較類的錯誤方法

if(obj.getClass().getName().equals("Foo")) // Wrong! // objects class is named Foo }else{ // object's class has some other name }

建議

在那些非得根據名稱來比較類的情況下,您必須格外小心,必須確保使用了當前類的 ClassLoader 的當前名稱空間,如清單 12 中所示：

清單 12. 比較類的更好方法

if(obj.getClass() == this.getClassLoader().loadClass("com.bar.Foo")){ // object's class is equal to //the class that this class calls "com.bar.Foo" }else{ // object's class is not equal to the class that // this class calls "com.bar.Foo" }

然而,比較類的更好方法是直接比較類對象看它們是否相等.例如,如果您想確定兩個對象 a 和 b 是否屬同一個類,那麼您就應該使用清單 13 中的代碼：

清單 13. 直接比較對象來看它們是否相等

if(a.getClass() == b.getClass()){ // objects have the same class }else{ // objects have different classes }

儘可能少用直接名稱比較.

不要使用內部類

Java 位元組碼沒有內部類的概念,編譯器將內部類轉換成了普通類,而如果沒有將內部類聲明為 private ,則同一個包內的任何代碼恰好能訪問該普通類.

影響

有這一特性,包內的惡意代碼可以訪問這些內部類.如果內部類能夠訪問括起外部類的欄位,那麼情況會變得更糟.可能已經將這些欄位聲明為 private ,這樣內部類就被轉換成了獨立類,但當內部類訪問外部類的欄位時,編譯器就將這些欄位從專用（private）的變為在包（package）的作用域內有效的.內部類暴露了已經夠糟糕的了,但更糟糕的是編譯器使您將某些欄位成為 private 的舉動成為徒勞.

建議

如果能夠不使用內部類就不要使用內部類.

對付低嚴重性暴露的技巧

請遵循下列建議以避免低嚴重性靜態安全性暴露：

避免返回可變對象
檢查本機方法
避免返回可變對象

Java 方法返回對象引用的副本.如果實際對象是可改變的,那麼使用這樣一個引用調用程序可能會改變它的內容,通常這是我們所不希望見到的.

影響

請考慮這個示例：某個方法返回一個對敏感對象的內部數組的引用,假定該方法的調用程序不改變這些對象.即使數組對象本身是不可改變的,也可以在數組對象以外操作數組的 內容,這種操作將反映在返回該數組的對象中.如果該方法返回可改變的對象,那麼事情會變得更糟；外部實體可以改變在那個類中聲明的 public 變數,這種改變將反映在實際對象中.

清單 14 演示了脆弱性. getExposedObj（） 方法返回了 Exposed 對象的 引用副本,該對象是可變的：

清單 14. 返回可變對象的引用副本

class Exposed{ private int id; private String name; public Exposed(){ } public Exposed(int id, String name){ this.id = id; this.name = name; } public int getId(){ return id; } public String getName(){ return name; } public void setId(int id){ this.id=id; } public void setName(String name){ this.name = name; } public void display(){ System.out.println("Id = " id " Name = " name); } } public class Exp12{ private Exposed exposedObj = new Exposed(1,"Harry Porter"); public Exposed getExposedObj(){ return exposedObj; //returns a reference to the object. } public static void main(String[] args){ Exp12 exp12 = new Exp12(); exp12.getExposedObj().display(); Exposed exposed = exp12.getExposedObj(); exposed.setId(10); exposed.setName("Hacker"); exp12.getExposedObj().display(); } }

建議

如果方法返回可改變的對象,但又不希望調用程序改變該對象,請修改該方法使之不返回實際對象而是返回它的副本或克隆.要改正清單 14 中的代碼,請讓它返回 Exposed 對象的 副本,如清單 15 中所示：

清單 15. 返回可變對象的副本

public Exposed getExposedObj(){ return new Exposed(exposedObj.getId(),exposedObj.getName()); }

或者,您的代碼也可以返回 Exposed 對象的克隆.

檢查本機方法

本機方法是一種 Java 方法,其實現是用另一種編程語言編寫的,如 C 或 C .有些開發人員實現本機方法,這是 Java 語言即使使用即時（just-in-time）編譯器也比許多編譯過的語言要慢.其它人需要使用本機代碼是為了在 JVM 以外實現特定於平台的功能.

影響

使用本機代碼時,請小心,對這些代碼進行驗證是不可能的,而且本機代碼可能潛在地允許 applet 繞過通常的安全性管理器（Security Manager）和 Java 對設備訪問的控制.

建議

如果非得使用本機方法,那麼請檢查這些方法以確定：

它們返回什麼
它們獲取什麼作為參數
它們是否繞過安全性檢查
它們是否是 public 、 private 等等
它們是否含有繞過包邊界從而繞過包保護的方法調用

結束語

編寫安全 Java 代碼是十分困難的,但本文描述了一些可行的實踐來幫您編寫安全 Java 代碼.這些建議並不能解決您的所有安全性問題,但它們將減少暴露數目.最佳軟體安全性實踐可以幫助確保軟體正常運行.安全至關重要和高可靠系統設計者總是花費大量精力來分析和跟蹤軟體行為.只有通過將安全性作為至關緊要的系統特性來對待 ― 並且從一開始就將它構建到應用程序中,我們才可以避免亡羊補牢似的、修修補補的安全性方法.

Tags: