概述和溢出
一、概述
編寫安全的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;
bad = 50;這段代碼總是拋出一個Java.lang.ArrayOutOfBoundsException異常，而該異常可以由程序自行捕獲：
try {
char[] bad = new char;
bad = 50;
}
catch (ArrayOutOfBoundsException ex) {
... }
這種處理過程永遠不會導致不可預料的行為。無論用什麼方法溢出一個數組，我們總是得到ArrayOutOfBoundsException異常，而Java運行時底層環境卻能夠保護自身免受任何侵害。一般而言，用Java字符串類型處理字符串時，我們無需擔心字符串的ArrayOutOfBoundsExceptions異常，因此它是一種較為理想的選擇。
Java編程模式從根本上改變了用戶輸入的處理方法，避免了輸入緩存溢出，從而使得Java程序員擺脫了最危險的編程漏洞。
三、競爭狀態
競爭狀態即Race Condition，它是第二類最常見的應用安全漏洞。在創建（更改）資源到修改資源以禁止對資源訪問的臨界時刻，如果某個進程被允許訪問資源，此時就會出現競爭狀態。這裡的關鍵問題在於：如果一個任務由兩個必不可少的步驟構成，不管你多麼想要讓這兩個步驟一個緊接著另一個執行，操作系統並不保證這一點。例如，在數據庫中，事務機制使得兩個獨立的事件“原子化”。換言之，一個進程創建文件，然後把這個文件的權限改成禁止常規訪問；與此同時，另外一個沒有特權的進程可以處理該文件，欺騙有特權的進程錯誤地修改文件，或者在權限設置完畢之後仍繼續對原文件進行訪問。
一般地，在標准Unix和NT環境下，一些高優先級的進程能夠把自己插入到任務的多個步驟之間，但這樣的進程在Java服務器上是不存在的；同時，用純Java編寫的程序也不可能修改文件的許可權限。因此，大多數由文件訪問導致的競爭狀態在Java中不會出現，但這並不意味著Java
