一、概述  
當網(wǎng)絡(luò)編程越來越方便，系統(tǒng)功能越來越強大，安全性卻指數(shù)倍地下降。這恐怕就是網(wǎng)絡(luò)編程的不幸和悲哀了。各種動態(tài)內(nèi)容生成環(huán)境繁榮了WWW，它們的設(shè)計目標就是為了給開發(fā)者更多的力量，給最終用戶更多的方便。正因為如此，系統(tǒng)設(shè)計師和開發(fā)者必須明確地把安全問題作為一個考慮因素，事后追悔很難奏效。  
從安全的角度來看，服務(wù)器端WWW應(yīng)用的弱點來源于各種各樣的交互能力和傳輸通道。它們是攻擊者直接可以用來影響系統(tǒng)的工具。在攻擊者尋找和利用系統(tǒng)安全漏洞時，它們總是給系統(tǒng)安全帶來壓力。對付所有這些攻擊的通用防衛(wèi)策略就是所謂的輸入驗證。  
從同一層面考慮，主要有兩種設(shè)計上的錯誤導(dǎo)致了安全方面的問題：  
· 拙劣的訪問控制，以及  
· 對部署環(huán)境作隱含的假設(shè)。  
在有關(guān)安全的文獻中，針對訪問控制問題有著許多深入的分析。這里我們要討論的是底層實現(xiàn)（代碼和配置）上的安全管理問題，討論的環(huán)境是JSP?；蛘哒f，我們將討論惡意的用戶輸入偽裝自身以及改變應(yīng)用預(yù)定行為的各種方法，考慮如何檢驗輸入合法性以及減少對信息和應(yīng)用接口的不受歡迎的探測。  
二、JSP概述  
JSP技術(shù)允許把Java代碼邏輯嵌入到HTML和XML文檔之內(nèi)，為創(chuàng)建和管理動態(tài)WWW內(nèi)容帶來了方便。JSP頁面由JSP引擎預(yù)先處理并轉(zhuǎn)換成Java Servlet，此后如果出現(xiàn)了對JSP頁面的請求，Web服務(wù)器將用相應(yīng)的Servlet輸出結(jié)果作為應(yīng)答。雖然JSP和Servlet在功能上是等價的，但是，和Servlet相比，JSP的動態(tài)內(nèi)容生成方法恰好相反：JSP是把Java代碼嵌入到文檔之中，而不是把文檔嵌入到Java應(yīng)用之中。為訪問外部功能和可重用的對象，JSP提供了一些用來和JavaBean組件交互的額外標記，這些標記的語法和HTML標記相似。值得注意的是：HTML語法屬于JSP語法的一個子集（一個純HTML文檔是一個合法的JSP頁面），但反過來不一定正確。特別地，為了便于動態(tài)生成內(nèi)容和格式，JSP允許在標記之內(nèi)嵌入其他標記。例如，下面是一段合法的JSP代碼：  
<A HREF = "<%= request.getRemoteUser() %>">  
從本文后面可以看到，這種結(jié)構(gòu)增加了安全問題的復(fù)雜性。  
與CGI相比，JSP具有更好的性能和會話管理（即會話狀態(tài)持久化）機制。這主要通過在同一個進程之內(nèi)運用Java線程處理多個Servlet實現(xiàn)，而CGI一般要求為每一個請求分別創(chuàng)建和拆除一個進程。  
三、安全問題  
由于完全開放了對服務(wù)器資源的訪問，從JSP頁面轉(zhuǎn)換得到的不安全Servlet可能給服務(wù)器、服務(wù)器所在的網(wǎng)絡(luò)、訪問頁面的客戶機之中的任意一個或全體帶來威脅，甚至通過DDoS或蠕蟲分布式攻擊，還可能影響到整個Internet。人們往往假定，Java作為一種類型安全的、具有垃圾收集能力的、具有沙箱（Sandbox）機制的語言，它能夠奇跡般地保證軟件安全。而且事實上，許多在其他語言中存在的低層次安全問題，比如緩沖或堆溢出，很少給Java程序帶來危害。然而，這并不意味著人們很難寫出不安全的Java程序，特別是對編寫Servlet來說。驗證輸入和控制對資源的訪問是始終必須關(guān)注的問題。另外，JSP的體系結(jié)構(gòu)相當復(fù)雜，其中包含許多相互協(xié)作的子系統(tǒng)。這些子系統(tǒng)之間的交互常常是安全隱患的根源。除此之外，雖然現(xiàn)在所有的JSP實現(xiàn)都圍繞著Java，但JSP規(guī)范允許幾乎所有其他語言扮演這個角色。這樣，這些替代語言的安全問題也必須加以考慮。  
簡而言之，在JSP系統(tǒng)中產(chǎn)生安全漏洞的機會是相當多的。下面我們將討論它們中最常見的一部分。  
四、非置信用戶輸入的一般問題  
非置信的用戶輸入（Untrusted User Input）實際上包含了所有的用戶輸入。用戶輸入來源于客戶端，可以通過許多不同的途徑到達服務(wù)器端，有時甚至是偽裝的。為JSP服務(wù)器提供的用戶輸入包括（但不限于）：  
· 請求URL的參數(shù)部分，  
· HTML表單通過POST或GET請求提交的數(shù)據(jù)，  
· 在客戶端臨時保存的數(shù)據(jù)（也就是Cookie），  
· 數(shù)據(jù)庫查詢，  
· 其它進程設(shè)置的環(huán)境變量。  
用戶輸入的問題在于，它們由服務(wù)器端的應(yīng)用程序解釋，所以攻擊者可以通過修改輸入數(shù)據(jù)達到控制服務(wù)器脆弱部分的目的。服務(wù)器的脆弱部分常常表現(xiàn)為一些數(shù)據(jù)訪問點，這些數(shù)據(jù)由用戶提供的限定詞標識，或通過執(zhí)行外部程序得到。  
JSP能夠調(diào)用保存在庫里面的本地代碼（通過JNI）以及執(zhí)行外部命令。類Runtime提供了一個exec()方法。exec()方法把它的第一個參數(shù)視為一個需要在獨立的進程中執(zhí)行的命令行。如果這個命令字符串的某些部分必須從用戶輸入得到，則用戶輸入必須先進行過濾，確保系統(tǒng)所執(zhí)行的命令和它們的參數(shù)都處于意料之內(nèi)。即使命令字符串和用戶輸入沒有任何關(guān)系，執(zhí)行外部命令時仍舊必須進行必要的檢查。在某些情況下，攻擊者可能修改服務(wù)器的環(huán)境變量影響外部命令的執(zhí)行。例如，修改path環(huán)境變量，讓它指向一個惡意的程序，而這個惡意程序偽裝成了exec()所調(diào)用程序的名字。為了避免這種危險，在進行任何外部調(diào)用之前顯式地設(shè)置環(huán)境變量是一種較好的習慣。具體的設(shè)置方法是：在exec()調(diào)用中，把一個環(huán)境變量的數(shù)組作為第二個參數(shù)，數(shù)組中的元素必須是name=value格式。  
當用戶輸入用來標識程序打開的任意類型的輸入/輸出流時，類似的問題也會出現(xiàn)。訪問文件、數(shù)據(jù)庫或其他網(wǎng)絡(luò)連接時不應(yīng)該依賴于未經(jīng)檢驗的用戶輸入。另外，打開一個流之后，把用戶輸入直接發(fā)送給它是很不安全的。對于SQL查詢來說這一點尤其突出。下面訪問JDBC API的JSP代碼片斷很不安全，因為攻擊者可以在他提交的輸入中嵌入分隔命令的字符，從而達到執(zhí)行危險命令的目的：  
<%@ page import="java.sql.*" %> <!-- 這里加上一些打開SQL Server連接的代碼 --> <% Statement stmt = connection.getStatement(); String query = "SELECT * FROM USER_RECORDS WHERE USER = " + request.getParameter("username"); ResultSet result = Statement.executeQuery(query); %>
如果username包含一個分號，例如：  
http://server/db.jsp? username=joe;SELECT%20*%20FROM%20SYSTEM_RECORDS
一些版本的SQL Server會忽略整個查詢，但還有一些版本的SQL Server將執(zhí)行兩個命令。如果是后者，攻擊者就可以訪問原本沒有資格訪問的數(shù)據(jù)庫資源（假定Web服務(wù)器具有訪問權(quán)限）。  
進行適當?shù)妮斎霗z驗可以防止這類問題出現(xiàn)。  
五、輸入檢驗  
從安全的角度來看，輸入檢驗包括對來自外部數(shù)據(jù)源（非置信數(shù)據(jù)源，參見前面說明）的數(shù)據(jù)進行語法檢查，有時還要進行語義檢查。依賴于應(yīng)用的關(guān)鍵程度和其他因素，作為輸入檢驗結(jié)果而采取的動作可能是下面的一種或者多種：  
· 忽略語法上不安全的成分，  
· 用安全的代碼替換不安全的部分，  
· 中止使用受影響的代碼，  
· 報告錯誤，  
· 激活一個入侵監(jiān)測系統(tǒng)。  
輸入檢驗可以按照以下兩種模式之一進行：列舉不安全的字符并拒絕它們；定義一組安全的字符，然后排除和拒絕不安全的字符。這兩種模式分別稱為正向和反向輸入過濾。一般地，正向輸入過濾更簡單和安全一些，因為許多時候，要列舉出服務(wù)器端應(yīng)用、客戶端瀏覽器、Web服務(wù)器和操作系統(tǒng)可能誤解的字符并不是一件容易的事情。  
請參見本文下面“通過嵌入標記實現(xiàn)的攻擊”部分中輸入檢驗的例子，這個例子示范了如何避免誤解惡意提交的輸入內(nèi)容。  
六、GET請求和Cookie中的敏感數(shù)據(jù)  
就象CGI協(xié)議所定義的，把請求數(shù)據(jù)從客戶端傳輸?shù)椒?wù)器端最簡單的方法是GET請求方法。使用GET請求方法時，輸入數(shù)據(jù)附加到請求URL之后，格式如下：  
URL[?name=value[&name=value[&...]]]
顯然，對于傳輸敏感數(shù)據(jù)來說，這種編碼方式是不合適的，因為通常情況下，整個URL和請求字符串都以明文方式通過通信通道。所有路由設(shè)備都可以和服務(wù)器一樣記錄這些信息。如果要在客戶請求中傳輸敏感數(shù)據(jù)，我們應(yīng)該使用POST方法，再加上一種合適的加密機制（例如，通過SSL連接）。從JSP引擎的角度來看，在很大程度上，使用哪種傳輸方法無關(guān)緊要，因為兩者的處理方式一樣。  
在WWW的發(fā)展過程中，Netscape引入了Cookie的概念。Cookie是服務(wù)器保存到客戶端的少量信息，服務(wù)器提取這些信息以維持會話狀態(tài)或跟蹤客戶端瀏覽器的活動。JSP提供了一個response隱含對象的addCookie()方法，用來在客戶端設(shè)置Cookie；提供了一個request()對象的getCookie()方法，用來提取Cookie的內(nèi)容。Cookie是javax.servlet.http.Cookie類的實例。由于兩個原因，如果把敏感數(shù)據(jù)保存到Cookie，安全受到了威脅：第一，Cookie的全部內(nèi)容對客戶端來說都是可見的；第二，雖然瀏覽器一般不提供偽造Cookie的能力，但沒有任何東西能夠阻止用戶用完全偽造的Cookie應(yīng)答服務(wù)器。  
一般而言，任何客戶端瀏覽器提交的信息都不可以假定為絕對安全。  
七、通過嵌入標記實現(xiàn)的攻擊  
CERT Advisory CA-2000-02描述了客戶在請求中嵌入惡意HTML標記的問題。這個問題一般被稱為“cross site scripting”問題，但它的名字有些用詞不當，因為它不僅僅和腳本有關(guān)，同時，它和“跨越網(wǎng)站”（cross site）也沒有什么特別的關(guān)系。不過，這個名字出現(xiàn)時，問題還沒有被人們廣泛了解。  
這種攻擊通常包含一個由用戶提交的病態(tài)腳本，或者包含惡意的HTML（或XML）標記，JSP引擎會把這些內(nèi)容引入到動態(tài)生成的頁面。這種攻擊可能針對其他用戶進行，也可能針對服務(wù)器，但后者不太常見。“cross site scripting”攻擊的典型例子可以在論壇服務(wù)器上看到，因為這些服務(wù)器允許用戶在自己提交的文章中嵌入格式化標記。通常，被濫用的標記是那些能夠把代碼嵌入到頁面的標記，比如<SCRIPT>、<OBJECT>、<APPLET>和<EMBED>。另外還有一些標記也會帶來危險，特別地，<FORM>可能被用于欺騙瀏覽者暴露敏感信息。下面是一個包含惡意標記的請求字符串的例子：  
http://server/jsp_script.jsp?poster=evilhacker＆ message=<SCRIPT>evil_code</SCRIPT>
要防止出現(xiàn)這種問題當然要靠輸入檢查和輸出過濾。這類檢查必須在服務(wù)器端進行，不應(yīng)依賴于客戶端腳本（比如JavaScript），因為沒有任何東西能夠阻止用戶逃避客戶端檢驗過程。  
下面的代碼片斷示范了如何在服務(wù)器端檢查嵌入的標記：  
<!-- HTML代碼結(jié)束 --><% String message = request.getParameter("message"); message = message.replace ('<','_'); message = message.replace ('>','_'); message = message.replace ('"','_'); message = message.replace (''','_'); message = message.replace ('%','_'); message = message.replace (';','_'); message = message.replace ('(','_'); message = message.replace (')','_'); message = message.replace ('&','_'); message = message.replace ('+','_'); %><p>你提交的消息是：<hr/><tt><%= message %></tt><hr/></p><!-- 下面加上其他HTML代碼 -->
由于要列舉出所有不合法的字符比較困難，所以更安全的方法是進行正向過濾，即除了那些確實允許出現(xiàn)的字符之外（例如[A-Za-z0-9]），丟棄（或者轉(zhuǎn)換）所有其他字符。  
八、關(guān)于JavaBean的說明  
JSP按照JavaBean規(guī)范描述的一系列約定，在JSP頁面中快速、方便地訪問可重用的組件（Java對象）。每個JavaBean組件封裝了一些可以不依賴于調(diào)用環(huán)境而獨立使用的數(shù)據(jù)和功能。Bean包含數(shù)據(jù)成員（屬性），并通過Get和Set方法實現(xiàn)訪問這些屬性的標準API。  
為快速初始化指定Bean的所有屬性，JSP提供了一種快捷方式，即在查詢字符串中提供name=value對，并讓它匹配目標屬性的名字。考慮下面這個使用Bean的例子（以XML格式顯示）：  
<jsp:useBean id="myBasket" class="BasketBean"> <jsp:setProperty name="myBasket" property="*"/> <jsp:useBean> <html> <head><title>你的購物籃</title></head> <body> <p> 你已經(jīng)把商品： <jsp::getProperty name="myBasket" property="newItem"/> 加入到購物籃 <br/> 金額是$ <jsp::getProperty name="myBasket" property="balance"/> 準備 <a href="checkout.jsp">付款</a>
注意在setProperty方法調(diào)用中使用的通配符號“*”。這個符號指示JSP設(shè)置查詢字符串中指定的所有屬性的值。按照本意，這個腳本的調(diào)用方式如下：  
http://server/addToBasket.jsp?newItem=ITEM0105342
正常情況下，HTML表單構(gòu)造的查詢字符串就是這種形式。但問題在于，沒有任何東西能夠防止用戶設(shè)置balance屬性：  
http://server/addToBasket.jsp? newItem=ITEM0105342&balance=0
處理頁面的<jsp:setProperty>標記時，JSP容器會把這個參數(shù)映射到Bean中具有同樣名字的balance屬性，并嘗試把該屬性設(shè)置為0。  
為避免出現(xiàn)這種問題，JSP開發(fā)者必須在Bean的Set和Get方法中實現(xiàn)某種安全措施（Bean必須對屬性進行強制的訪問控制），同時，在使用<jsp:setProperty>的通配符時也應(yīng)該小心謹慎。  
九、實現(xiàn)上的漏洞與源代碼安全  
無論是哪一種JSP實現(xiàn)，在一定的階段，它們的某些版本都會出現(xiàn)給系統(tǒng)帶來危險的安全隱患，即使JSP開發(fā)者遵從了安全編程慣例也無濟于事。例如，在Allaire的JRun的一個版本中，如果請求URL包含字符串“.jsp%00”作為JSP腳本擴展名的一部分，服務(wù)器不會忽略null字節(jié)，它會把頁面視為一個靜態(tài)的非JSP頁面之類的東西。這樣，服務(wù)器會請求操作系統(tǒng)打開該頁面，而這時null字節(jié)卻被忽略，結(jié)果提供給用戶的是JSP頁面的源代碼而不是頁面的執(zhí)行結(jié)果。  
類似地，Tomcat的一個版本也有一個安全隱患。只要請求類如下面的格式，它會讓攻擊者看到JSP頁面的源代碼：  
http://server/page.js%2570
這里的情況在于，%25是URL編碼的“%”，而70是“p”的十六進制值。Web服務(wù)器不會調(diào)用JSP處理器（因為URL沒有以“.jsp”結(jié)尾），但靜態(tài)文件處理器會設(shè)法把URL映射到正確的文件名字（再一次解碼URL）。  
另外，許多Web服務(wù)器和JSP實現(xiàn)都帶有示范腳本，這些示范腳本常常包含安全隱患。在把服務(wù)器部署到一個不無惡意的環(huán)境（即Internet）之前，禁止對所有這些腳本的訪問有利于安全。  
簡而言之，JSP開發(fā)者應(yīng)該清楚：在自己正在開發(fā)的平臺上，當前有哪些安全隱患。訂閱BUGTRAQ和所有供應(yīng)商提供的郵件列表是跟蹤這類信息的好方法。  
結(jié)束語  
JSP和任何其他強大的技術(shù)一樣。如果要保證被部署系統(tǒng)的安全和可靠，應(yīng)用JSP時必須小心謹慎。在這篇文章中，我們簡要地討論了JSP腳本中常常出現(xiàn)的代碼和配置級安全問題，提出了降低由此帶來的安全風險的建議。