Java服務器端編程安全必讀

一、概述
編寫安全的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（訪問控制表，Aclearcase/" target="_blank" >ccess Control List）的安全標記，保
護要在它下面創建文件的目錄。NT的新文件一般從它的父目錄繼承訪問許可。請參見
NT文檔了解更多信息。

原文轉自：http://www.anti-gravitydesign.com