jsp安全問題及其解決建議

js|安全|解決|問題 jsp程式設計語言自從推出之日起，由於它的快速、平台無關、可擴充、物件導向等特性得到了越來越廣泛的應用，越來越多的廠家開發出了各種各樣的支援平台如IBM 公司的WebSphere、BEA公司的WebLogic等等，也有越來越多的網站開始將自己的平台架構在jsp 環境中。

　　但是隨之而來的就是一系列的安全性漏洞問題，如原始碼暴露漏洞、遠程任意命令執行漏洞等等，更為頭疼的是，隨著jsp 的越來越廣泛的應用，安全問題也越來越多了。截止到這篇文章為止，Internet上公開的關於jsp 的漏洞問題就多達二、三十條(還不包括未公開的)。(統計資料來源於http://www.securityfocus.com)

　　不要輕視這些問題，想象一下，你辛辛苦苦開發出來的jsp 代碼就被別人這樣輕而易舉獲得了，更為重要的是，你公司網站的代碼被人下載後，別有用意的人就會看你的代碼，從中找到一些漏洞來攻擊你的公司網站，所以這些問題不容忽視。作者在sohu 上搜尋了一些用jsp做的國內網站，結果發現有一些網站確實存在各種各樣的漏洞，可以輕鬆的下載jsp原始碼。

　　本篇文章重點在於對jsp安全問題進行分類闡述和提出解決的建議，所以每種類型的安全問題只採用了一個例子，對於其它各種漏洞的具體細節如涉及到何種軟體版本何種作業系統等就不一一進行闡述了，有興趣的讀者可以到我的網站jsp 愛好者(http://jspbbs.yeah.net)或者國外的安全網站(http://www.securityfocus.com)進行查看和參考。

根據目前已經發現的jsp安全問題，我們不妨將它們分為以下幾類，原始碼暴露類、遠程程式執行類和其他類別, 下面來看看具體的東西吧。

一、原始碼暴露類

　　原始碼暴露類別主要指的是程式原始碼會以明文的方式返回給訪問者.

　　我們知道不管是jsp還是asp、php等動態程式都是在伺服器端執行的，執行後只會返回給訪問者標準的html 等代碼。這是理論上的東西，實際運行起來由於伺服器內部機制的問題就有可能引起原始碼暴露的漏洞，簡單的例子只要在程式檔案名稱後加幾個簡單的字元就可能獲得程式碼，如常見微軟asp 的global.asa+.htr、XXXX.asp%81等等漏洞。

　　1、添加特殊尾碼引起jsp原始碼暴露

　　在jsp中也存在著和asp這些漏洞類似的問題，如IBM Websphere Application Server 3.0.21、BEA Systems Weblogic 4.5.1、Tomcat3.1等jsp檔案尾碼大寫漏洞;jsp 檔案後加特殊字元如Resin1.2的%82、../漏洞；ServletExec的%2E、+漏洞等等。

　　例子：舉個老一點的JSP大寫例子，Tomcat3.1下在瀏覽器中本來是http://localhost:8080/inde.jsp，可以正常解釋執行，但是如果將inde.jsp改為inde.JSP或者inde.Jsp等等試試看，你會發現瀏覽器會提示你下載這個檔案，下載後原始碼可以看個一乾二淨。

　　原因：jsp是大小寫敏感的，Tomcat只會將小寫jsp尾碼的檔案當作是正常的jsp檔案來執行，如果大寫了就會引起Tomcat將inde.JSP當作是一個可以下載的檔案讓客戶下載。老版本的WebLogic、WebShpere等都存在這個問題，現在這些公司或者發布了新版本或者發布了補丁解決了這問題。

　　解決辦法：一是在伺服器軟體的網站上下載補丁；因為筆者以前用過asp 一段時間，接觸了很多IIS的漏洞，它的有效解決方案是去掉不必要的映射如htr、htx等，在jsp 中我們同樣可以參考IIS的解決方案，不同的是不是去掉而是添加映射，方法為在伺服器設定中添加一些映射如.JSP 、.Jsp、.jsp%2E等，將他們映射到一個自己寫的servlet，這個Servlet的唯一功能就是將請求導向一個自訂的類似404 not found的出錯頁面，不同的伺服器設定的地方也不同，請參考相應的文檔。第二種解決方案可以在沒有補丁的時候採用。

　　2、插入特殊字元串引起jsp原始碼暴露

　　還有一種是插入特殊字元串引起的漏洞，BEA WebLogic Enterprise 5.1.
檔案路徑開頭為 "/file/" 的漏洞、IBM WebSphere 3.0.2的"/servlet/file/"檔案開頭漏洞等等。

　　例子：如IBM WebSphere 3.0.2中，如果一個請求檔案的 URL 為"login.jsp":http://site.running.websphere/login.jsp，那麼訪問http://site.running.websphere/servlet/file/login.jsp將看到這個檔案的原始碼。

　　原因：因為IBM WebSphere 3.0.2是調用不同的 servlets 對不同的頁面進行處理，如果一個請求的檔案是未進行註冊管理的，WebSphere 會使用一個預設的 servlet 調用。如果檔案路徑以"/servlet/file/"作開頭這個預設的 servlet 會被調用這個請求的檔案會未被分析或編譯就顯示出來。

　　解決方案：在伺服器軟體的網站下載最新的補丁。

　　3、路徑許可權引起的檔案jsp原始碼暴露

　　這種漏洞在正常的jsp漏洞中沒有反映出來，但是筆者在寫jsp程式中曾經碰到過，頭疼了一陣子，最後總算解決了。我們知道，大部分的jsp應用程式在目前的目錄下都會有一個WEB-INF目錄，這個目錄通常存放的是JavaBeans編譯後的class 檔案，如果不給這個目錄設定正常的許可權，所有的class就會曝光。

　　例子：筆者當時採用的是Apache1.3.12加上第三方jsp軟體形式的WEB伺服器，因為Apache1.3.12預設的設定是可以讀取目錄的，如果程式在http://site.running.websphere/login.jsp，只要修改一下http://site.running.websphere/WEB-INF/所有這個目錄下以及這個目錄下的子目錄中的class檔案可以看個一乾二淨的，還可以下載到本機上。

　　也許你會說class是經過編譯的，就算被人下載也沒有什麼關係，但是現在class 反編譯為java代碼的軟體也很多，筆者當時採用JAD軟體對下載的class檔案反編譯了一下，居然和原始的java檔案幾乎一模一樣，變數名都沒有變，更驚奇的是還可以重新編譯為class檔案正常使用。

　　安全問題更大的就是，筆者開始把資料庫的使用者名稱密碼都寫在了java代碼中，現在一反編譯誰都能看到資料庫的重要訊息。通過資料庫的遠端連線功能，可以輕鬆的進入到你的資料庫中，所有資訊全部在他手中。附帶說一句，如果使用者能獲得SQL Server的使用者名稱口令(sa 的)，進入資料庫中可以執行任意的dos命令如查看c:檔案、建立和刪除目錄等，那樣整個Windows系統都不安全了(此種方法危害性更大，恕作者不公布出來)。

　　作者曾經偶然在網上看到過國內某個大型網站有同樣的問題，而且密碼也是和筆者一樣寫在JavaBean中的，極不安全。

　　解決方案：IIS以前一個有效地解決asp的漏洞就是將asp程式單獨放置一個目錄，目錄設定上使用者權限只能執行不能讀取。在jsp環境下同樣可以通過設定伺服器的環境來解決這個問題，簡單的說就是將一些比較重要的目錄如WEB-INF、classes等設定上訪問的許可權，不允許讀而取只允許執行。以apache 下解決為例，可以在httpd.conf檔案中添加一目錄WEB-INF並設定Deny from all等屬性。

　　另一種比較笨的解決方案就是在每個重要目錄下添加一個預設起始頁面如inde.htm等，這樣讀取目錄就會返回給訪問者這個檔案而不是其它了。建議採用的一種方法。

　　更為重要的是密碼的儲存問題，筆者以前在asp 開發中是採用密碼檔案儲存在系統目錄如WINNT 下的，然後寫了一個com來讀取這個檔案，這樣就算看到了asp原始碼也不知道資料庫資訊了。在jsp中我們也可以寫一個property檔案，放置在WINNT系統目錄下，然後用Bean來讀取資料庫資訊，這樣通過原始碼知道了資料庫資訊存在WINNT中的.property檔案裡面，但也很難訪問它，這樣就算原始碼被人知道起碼資料庫是安全的。

　　4、檔案不存在引起的絕對路徑暴露問題

　　這個問題相信大家都比較熟悉了，因為微軟IIS 中也有比較多的類似問題如微軟IIS5.0中的*.idc暴露絕對路徑漏洞。同樣的這些問題現在也轉到了jsp環境中，這個漏洞暴露了web程式的絕對硬碟地址，和其他漏洞結合就具有比較大的危害了，因為這個漏洞目前還沒有在國外安全網站上看到，而站長也沒有一一測試過所有的jsp伺服器程式，所以沒有辦法告訴大家那些有這個漏洞了，大家可以在自己的web伺服器上測試看看。

　　例子：在特定的伺服器軟體下，訪問一個不存在的jsp檔案如 http://localhost:8080/fdasfas.jsp，就會返回java.servlet.ServletEception: java.io.FileNotFoundEception: c:webappfadssad.jsp (???????????)這樣的錯誤，這樣就可以知道你網站在c:webapp目錄下，也許一般人不太在意，但是對於一個駭客來說就是很有協助了。

　　原因：負責jsp 執行的相關Servlet中處理異常的時候沒有過濾掉這種情況。

　　解決方案：一是下載最新的補丁；由於筆者當時的網頁伺服器軟體沒有這個補丁，經過一段時間的痛苦煎熬後，總算找到了另外一種方法，就是找到伺服器軟體的jsp 執行映射Servlet檔案(當然是class 尾碼的)，將它用JAD軟體反編譯，在反編譯後的原始碼中找到處理Eception的方法，然後將方法中的處理部分全部注釋掉，並將請求導向到一個自訂的出錯頁面中，這樣問題就解決了。

二、遠程程式執行類

　　這類漏洞的特點就是可以通過url 地址在瀏覽器中執行任意伺服器上的命令和程式，從而引起安全問題。如Allaire JRUN 2.3 遠程執行任意命令漏洞、iPlanet Web Server 4.x存在一個緩衝區溢位漏洞等等。

　　例子：Allaire 的 JRUN 伺服器 2.3上輸入下面的url地址http://jrun:8000/servlet/jsp/../../path/sample.txt，可以訪問到WEB目錄以外的檔案，如果是exe檔案，還有可能會引起執行。

　　原因：如果URL請求的目標檔案使用了首碼"/servlet/"，則JSP 解釋執行功能被啟用。這時在使用者請求的目標檔案路徑中使用"../"，就有可能訪問到 WEB 伺服器上根目錄以外的檔案。目標主機上利用該漏洞請求使用者輸入產生的一個檔案，將嚴重威脅到目標主機系統的安全。

　　解決方案：安裝最新的補丁。

三、其他類別

　　這些類別的範圍就有點大了，可以包括資料庫如SQL Server、Oracle 、DB2等的漏洞，也可以包括作業系統如WindowsNT/2000、Linu等的漏洞。這些東西的漏洞可以說都是致命的，如利用Linu的某些漏洞可以輕易的Su為管理員來遠端控制伺服器，獲得系統的完全控制許可權，這樣要獲得jsp原始碼或者摧毀伺服器比踩死一隻螞蟻還要輕鬆的多。

四、全文總結

　　通過上面內容我們可以看出jsp同asp一樣還是存在著很多安全上的問題的，客觀的說，伺服器軟體的開發商在自我裝載中不可能將系統中的所有bug 找出來，即使發布了軟體後，被發現的漏洞也只會是其中的很小一部分，將來還會不斷的有新的安全問題出現，所以我們必須時刻提高警惕，並注意自己網站的安全。

　　一個好的建議就是多看安全文章，這些安全文章一般都會有詳細的資訊如軟體的版本號碼、漏洞原因等等，最重要的是還附帶瞭解決辦法或者是補丁的下載連結，推薦的安全網站是國內的安全網站www.cnns.net或者國外的www.securityfocus.com網站；另外一個好的建議就是多裝補丁程式，訪問自己所使用的軟體公司首頁，從那上面獲得最新的補丁程式，做得比較好的就是微軟的網站，資訊安全諮詢和補丁都特別及時。

　　最後想用一句話作為全文的結尾：一個優秀的駭客不一定是個好的jsp 程式員，一個優秀的jsp程式員一定要是個好的准駭客。