JSP應用程序開發中安全問題的實例解析

2019-11-18 19:15:37

字體：大中小

來源：轉載

供稿：網友

選擇自 hf1650 的 Blog

　一、概述

　　當網絡編程越來越方便，系統功能越來越強大，安全性卻指數倍地下降。這恐怕就是網絡編程的不幸和悲哀了。各種動態內容生成環境繁榮了WWW，它們的設計目標就是為了給開發者更多的力量，給最終用戶更多的方便。正因為如此，系統設計師和開發者必須明確地把安全問題作為一個考慮因素，事后追悔很難奏效。

　　從安全的角度來看，服務器端WWW應用的弱點來源于各種各樣的交互能力和傳輸通道。它們是攻擊者直接可以用來影響系統的工具。在攻擊者尋找和利用系統安全漏洞時，它們總是給系統安全帶來壓力。對付所有這些攻擊的通用防衛策略就是所謂的輸入驗證。

　　從同一層面考慮，主要有兩種設計上的錯誤導致了安全方面的問題：

· 拙劣的訪問控制。

· 對部署環境作隱含的假設。

　　在有關安全的文獻中，針對訪問控制問題有著許多深入的分析。這里我們要討論的是底層實現（代碼和配置）上的安全管理問題，討論的環境是jsp?；蛘哒f，我們將討論惡意的用戶輸入偽裝自身以及改變應用預定行為的各種方法，考慮如何檢驗輸入合法性以及減少對信息和應用接口的不受歡迎的探測。

　　二、JSP概述

　　JSP技術允許把java代碼邏輯嵌入到HTML和xml文檔之內，為創建和管理動態WWW內容帶來了方便。JSP頁面由JSP引擎預先處理并轉換成Java Servlet，此后如果出現了對JSP頁面的請求，Web服務器將用相應的Servlet輸出結果作為應答。

　　雖然JSP和Servlet在功能上是等價的，但是，和Servlet相比，JSP的動態內容生成方法恰好相反：JSP是把Java代碼嵌入到文檔之中，而不是把文檔嵌入到Java應用之中。為訪問外部功能和可重用的對象，JSP提供了一些用來和JavaBean組件交互的額外標記，這些標記的語法和HTML標記相似。

　　值得注意的是：HTML語法屬于JSP語法的一個子集（一個純HTML文檔是一個合法的JSP頁面），但反過來不一定正確。特別地，為了便于動態生成內容和格式，JSP允許在標記之內嵌入其他標記。例如，下面是一段合法的JSP代碼：

　　從本文后面可以看到，這種結構增加了安全問題的復雜性。

　　與CGI相比，JSP具有更好的性能和會話管理（即會話狀態持久化）機制。這主要通過在同一個進程之內運用Java線程處理多個Servlet實現，而CGI一般要求為每一個請求分別創建和拆除一個進程。

　　三、安全問題

　　由于完全開放了對服務器資源的訪問，從JSP頁面轉換得到的不安全Servlet可能給服務器、服務器所在的網絡、訪問頁面的客戶機之中的任意一個或全體帶來威脅，甚至通過DDoS或蠕蟲分布式攻擊，還可能影響到整個Internet。

　　人們往往假定，Java作為一種類型安全的、具有垃圾收集能力的、具有沙箱（Sandbox）機制的語言，它能夠奇跡般地保證軟件安全。而且事實上，許多在其他語言中存在的低層次安全問題，比如緩沖或堆溢出，很少給Java程序帶來危害。

　　然而，這并不意味著人們很難寫出不安全的Java程序，特別是對編寫Servlet來說。驗證輸入和控制對資源的訪問是始終必須關注的問題。另外，JSP的體系結構相當復雜，其中包含許多相互協作的子系統。這些子系統之間的交互常常是安全隱患的根源。

　　除此之外，雖然現在所有的JSP實現都圍繞著Java，但JSP規范允許幾乎所有其他語言扮演這個角色。這樣，這些替代語言的安全問題也必須加以考慮。

　　簡而言之，在JSP系統中產生安全漏洞的機會是相當多的。下面我們將討論它們中最常見的一部分。

　　四、非置信用戶輸入的一般問題

　　非置信的用戶輸入（Untrusted User Input）實際上包含了所有的用戶輸入。用戶輸入來源于客戶端，可以通過許多不同的途徑到達服務器端，有時甚至是偽裝的。為JSP服務器提供的用戶輸入包括（但不限于）：

· 請求URL的參數部分；

· HTML表單通過POST或GET請求提交的數據；

· 在客戶端臨時保存的數據（也就是Cookie）；

· 數據庫查詢；

· 其它進程設置的環境變量；

　　用戶輸入的問題在于，它們由服務器端的應用程序解釋，所以攻擊者可以通過修改輸入數據達到控制服務器脆弱部分的目的。服務器的脆弱部分常常表現為一些數據訪問點，這些數據由用戶提供的限定詞標識，或通過執行外部程序得到。

　　JSP能夠調用保存在庫里面的本地代碼（通過JNI）以及執行外部命令。類Runtime提供了一個exec()方法。exec()方法把它的第一個參數視為一個需要在獨立的進程中執行的命令行。如果這個命令字符串的某些部分必須從用戶輸入得到，則用戶輸入必須先進行過濾，確保系統所執行的命令和它們的參數都處于意料之內。

　　即使命令字符串和用戶輸入沒有任何關系，執行外部命令時仍舊必須進行必要的檢查。在某些情況下，攻擊者可能修改服務器的環境變量影響外部命令的執行。例如，修改path環境變量，讓它指向一個惡意的程序，而這個惡意程序偽裝成了exec()所調用程序的名字。

　　為了避免這種危險，在進行任何外部調用之前顯式地設置環境變量是一種較好的習慣。具體的設置方法是：在exec()調用中，把一個環境變量的數組作為第二個參數，數組中的元素必須是name=value格式。

　　當用戶輸入用來標識程序打開的任意類型的輸入/輸出流時，類似的問題也會出現。訪問文件、數據庫或其他網絡連接時不應該依賴于未經檢驗的用戶輸入。另外，打開一個流之后，把用戶輸入直接發送給它是很不安全的。

　　對于SQL查詢來說這一點尤其突出。下面訪問JDBC API的JSP代碼片斷很不安全，因為攻擊者可以在他提交的輸入中嵌入分隔命令的字符，從而達到執行危險命令的目的：

<%@ page import="java.sql.*" %>

<% 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將執行兩個命令。如果是后者，攻擊者就可以訪問原本沒有資格訪問的數據庫資源（假定Web服務器具有訪問權限），進行適當的輸入檢驗可以防止這類問題出現。

　　五、輸入檢驗

　　從安全的角度來看，輸入檢驗包括對來自外部數據源（非置信數據源，參見前面說明）的數據進行語法檢查，有時還要進行語義檢查。依賴于應用的關鍵程度和其他因素，作為輸入檢驗結果而采取的動作可能是下面的一種或者多種：

· 忽略語法上不安全的成分；

· 用安全的代碼替換不安全的部分；

· 中止使用受影響的代碼；

· 報告錯誤；

· 激活一個入侵監測系統；

　　輸入檢驗可以按照以下兩種模式之一進行：列舉不安全的字符并拒絕它們；定義一組安全的字符，然后排除和拒絕不安全的字符。這兩種模式分別稱為正向和反向輸入過濾。一般地，正向輸入過濾更簡單和安全一些，因為許多時候，要列舉出服務器端應用、客戶端瀏覽器、Web服務器和操作系統可能誤解的字符并不是一件容易的事情。

　　六、GET請求和Cookie中的敏感數據

　　就象CGI協議所定義的，把請求數據從客戶端傳輸到服務器端最簡單的方法是GET請求方法。使用GET請求方法時，輸入數據附加到請求URL之后，格式如下：

URL[?name=value[&name=value[&...]]]

　　顯然，對于傳輸敏感數據來說，這種編碼方式是不合適的，因為通常情況下，整個URL和請求字符串都以明文方式通過通信通道。所有路由設備都可以和服務器一樣記錄這些信息。如果要在客戶請求中傳輸敏感數據，我們應該使用POST方法，再加上一種合適的加密機制（例如，通過SSL連接）。從JSP引擎的角度來看，在很大程度上，使用哪種傳輸方法無關緊要，因為兩者的處理方式一樣。

　　在WWW的發展過程中，Netscape引入了Cookie的概念。Cookie是服務器保存到客戶端的少量信息，服務器提取這些信息以維持會話狀態或跟蹤客戶端瀏覽器的活動。JSP提供了一個response隱含對象的addCookie()方法，用來在客戶端設置Cookie；提供了一個request()對象的getCookie()方法，用來提取Cookie的內容。

　　Cookie是javax.servlet.http.Cookie類的實例。由于兩個原因，如果把敏感數據保存到Cookie，安全受到了威脅：第一，Cookie的全部內容對客戶端來說都是可見的；第二，雖然瀏覽器一般不提供偽造Cookie的能力，但沒有任何東西能夠阻止用戶用完全偽造的Cookie應答服務器。一般而言，任何客戶端瀏覽器提交的信息都不可以假定為絕對安全。

　　七、通過嵌入標記實現的攻擊

　　CERT Advisory CA-2000-02描述了客戶在請求中嵌入惡意HTML標記的問題。這個問題一般被稱為“cross site scripting”問題，但它的名字有些用詞不當，因為它不僅僅和腳本有關，同時，它和“跨越網站”（cross site）也沒有什么特別的關系。不過，這個名字出現時，問題還沒有被人們廣泛了解。

　　這種攻擊通常包含一個由用戶提交的病態腳本，或者包含惡意的HTML（或XML）標記，JSP引擎會把這些內容引入到動態生成的頁面。這種攻擊可能針對其他用戶進行，也可能針對服務器，但后者不太常見。

　　“cross site scripting”攻擊的典型例子可以在論壇服務器上看到，因為這些服務器允許用戶在自己提交的文章中嵌入格式化標記。通常，被濫用的標記是那些能夠把代碼嵌入到頁面的標記，比如：

<SCRIPT>、<OBJECT>、<APPLET>和<EMBED>。

　　另外還有一些標記也會帶來危險，特別地，　　可能被用于欺騙瀏覽者暴露敏感信息。下面是一個包含惡意標記的請求字符串的例子：

http://server/jsp_script.jsp?poster
=evilhacker＆ message=
<SCRIPT>evil_code</SCRIPT>

　　要防止出現這種問題當然要靠輸入檢查和輸出過濾。這類檢查必須在服務器端進行，不應依賴于客戶端腳本（比如Javascript），因為沒有任何東西能夠阻止用戶逃避客戶端檢驗過程。下面的代碼片斷示范了如何在服務器端檢查嵌入的標記：

<% 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>

　　你提交的消息是：

　　由于要列舉出所有不合法的字符比較困難，所以更安全的方法是進行正向過濾，即除了那些確實允許出現的字符之外（例如[A-Za-z0-9]），丟棄（或者轉換）所有其他字符。

　　八、關于JavaBean的說明

　　JSP按照JavaBean規范描述的一系列約定，在JSP頁面中快速、方便地訪問可重用的組件（Java對象）。每個JavaBean組件封裝了一些可以不依賴于調用環境而獨立使用的數據和功能。Bean包含數據成員（屬性），并通過Get和Set方法實現訪問這些屬性的標準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> 你已經把商品：
<jsp::getProperty name="myBasket"
property="newItem"/> 加入到購物籃
<br/> 金額是$ <jsp::getProperty
name="myBasket" property="balance"/>
準備 <a href="checkout.jsp">付款</a>

　　注意在setProperty方法調用中使用的通配符號“*”。這個符號指示JSP設置查詢字符串中指定的所有屬性的值。按照本意，這個腳本的調用方式如下：

http://server/addToBasket.jsp?newItem=ITEM0105342

　　正常情況下，HTML表單構造的查詢字符串就是這種形式。但問題在于，沒有任何東西能夠防止用戶設置balance屬性：

http://server/addToBasket.jsp?
newItem=ITEM0105342&balance=0

　　處理頁面的標記時，JSP容器會把這個參數映射到Bean中具有同樣名字的balance屬性，并嘗試把該屬性設置為0。

　　為避免出現這種問題，JSP開發者必須在Bean的Set和Get方法中實現某種安全措施（Bean必須對屬性進行強制的訪問控制），同時，在使用的通配符時也應該小心謹慎。

　　九、實現上的漏洞與源代碼安全

　　無論是哪一種JSP實現，在一定的階段，它們的某些版本都會出現給系統帶來危險的安全隱患，即使JSP開發者遵從了安全編程慣例也無濟于事。例如，在Allaire的JRun的一個版本中，如果請求URL包含字符串“.jsp%00”作為JSP腳本擴展名的一部分，服務器不會忽略null字節，它會把頁面視為一個靜態的非JSP頁面之類的東西。

　　這樣，服務器會請求操作系統打開該頁面，而這時null字節卻被忽略，結果提供給用戶的是JSP頁面的源代碼而不是頁面的執行結果。

　　類似地，Tomcat的一個版本也有一個安全隱患。只要請求類如下面的格式，它會讓攻擊者看到JSP頁面的源代碼：

http://server/page.js%2570

　　這里的騙局在于，%25是URL編碼的“%”，而70是“p”的十六進制值。Web服務器不會調用JSP處理器（因為URL沒有以“.jsp”結尾），但靜態文件處理器會設法把URL映射到正確的文件名字（再一次解碼URL）。

　　另外，許多Web服務器和JSP實現都帶有示范腳本，這些示范腳本常常包含安全隱患。在把服務器部署到一個不無惡意的環境（即Internet）之前，禁止對所有這些腳本的訪問有利于安全。

　　簡而言之，JSP開發者應該清楚：在自己正在開發的平臺上，當前有哪些安全隱患。訂閱BUGTRAQ和所有供應商提供的郵件列表是跟蹤這類信息的好方法。

　　結束語

　　JSP和任何其他強大的技術一樣。如果要保證被部署系統的安全和可靠，應用JSP時必須小心謹慎。在這篇文章中，我們簡要地討論了JSP腳本中常常出現的代碼和配置級安全問題，提出了降低由此帶來的安全風險的建議。

http://server/page.js%2570

　　簡而言之，JSP開發者應該清楚：在自己正在開發的平臺上，當前有哪些安全隱患。訂閱BUGTRAQ和所有供應商提供的郵件列表是跟蹤這類信息的好方法。

　　結束語

http://server/jsp_script.jsp?poster
=evilhacker＆ message=
<SCRIPT>evil_code</SCRIPT>

　　要防止出現這種問題當然要靠輸入檢查和輸出過濾。這類檢查必須在服務器端進行，不應依賴于客戶端腳本（比如JavaScript），因為沒有任何東西能夠阻止用戶逃避客戶端檢驗過程。下面的代碼片斷示范了如何在服務器端檢查嵌入的標記：

　　你提交的消息是：

　　八、關于JavaBean的說明

<jsp:useBean id="myBasket"
class="BasketBean">
<jsp:setProperty name="myBasket"
property="*"/> <jsp:useBean>
<html>
<head><title>你的購物籃</title></head>
<body> <p> 你已經把商品：
<jsp::getProperty name="myBasket"
property="newItem"/> 加入到購物籃
<br/> 金額是$ <jsp::getProperty
name="myBasket" property="balance"/>
準備 <a href="checkout.jsp">付款</a>

　　注意在setProperty方法調用中使用的通配符號“*”。這個符號指示JSP設置查詢字符串中指定的所有屬性的值。按照本意，這個腳本的調用方式如下：

http://server/addToBasket.jsp?newItem=ITEM0105342

　　正常情況下，HTML表單構造的查詢字符串就是這種形式。但問題在于，沒有任何東西能夠防止用戶設置balance屬性：

http://server/addToBasket.jsp?
newItem=ITEM0105342&balance=0

　　處理頁面的標記時，JSP容器會把這個參數映射到Bean中具有同樣名字的balance屬性，并嘗試把該屬性設置為0。

　　九、實現上的漏洞與源代碼安全

　　這樣，服務器會請求操作系統打開該頁面，而這時null字節卻被忽略，結果提供給用戶的是JSP頁面的源代碼而不是頁面的執行結果。

　　類似地，Tomcat的一個版本也有一個安全隱患。只要請求類如下面的格式，它會讓攻擊者看到JSP頁面的源代碼：

http://server/page.js%2570

　　簡而言之，JSP開發者應該清楚：在自己正在開發的平臺上，當前有哪些安全隱患。訂閱BUGTRAQ和所有供應商提供的郵件列表是跟蹤這類信息的好方法。

　　結束語

http://server/page.js%2570