大主宰,盗墓笔记小说全集

主頁 > 知識庫 > JSP應(yīng)用的安全問題

JSP應(yīng)用的安全問題

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

您可能感興趣的文章:

編寫線程安全的JSP程序
JSP安全性初探
Java線程安全中的單例模式
java編譯時出現(xiàn)使用了未經(jīng)檢查或不安全的操作解決方法
深入理解:Java是類型安全的語言,而C++是非類型安全的語言
Java語言的接口與類型安全
JSP學(xué)習(xí)之Java Web中的安全控制實(shí)例詳解

標(biāo)簽：吳忠廣元保定玉樹肇慶紹興北海潮州

巨人網(wǎng)絡(luò)通訊聲明：本文標(biāo)題《JSP應(yīng)用的安全問題》，本文關(guān)鍵詞 JSP,應(yīng),用的,安全,問題,JSP,；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題，煩請?zhí)峁┫嚓P(guān)信息告之我們，我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無關(guān)。

濮阳杆衣贸易有限公司

JSP應(yīng)用的安全問題