JSP中的源代碼泄漏問題

摘要:在JSP技術得到廣泛應用的同時,由於源代碼泄漏而引起的JSP安全性也受到了廣泛的關注。本文分析了幾種造成源代碼泄漏的因素,並針對每種因素提出了各自的解決方法。 
關鍵詞:JSP  源代碼 泄漏  
引言 
JSP編程語言自從推出之日起,由於它的快速、平臺無關、可擴展、面向對象等特性得到了越來越廣泛的應用,越來越多的廠家開發出了各種各樣的支持平臺如IBM 公司的WebSphere、BEA公司的WebLogic等等,也有越來越多的網站開始將自己的平臺架構在JSP 環境中。 
   但是隨之而來的就是一系列的安全問題,如源代碼暴露漏洞、遠程任意命令執行漏洞等等,一些用JSP做的網站,由於存在各種各樣的漏洞,可以被黑客輕鬆的下載程序的源代碼,對網站的安全構成威脅。 
造成JSP源代碼暴露的原因 
服務器漏洞是安全問題的起源,黑客對網站的攻擊也大多是從查找對方的漏洞開始的。所以只有瞭解自身的漏洞,網站管理人員才能採取相應的對策,阻止外來的攻擊。 
雖然JSP也是一種web編程語言,但是它和其它的web編程語言如PHP、ASP的工作機制是不一樣的。 
首次調用JSP文件其實是執行一個編譯爲Servlet的過程。試圖下載JSP源代碼的人(比如黑客)往往利用JSP的各種漏洞,讓JSP文件在編譯前被瀏覽器當作一個文本或其它文件發送給客戶端,或在JSP裝載的時候不去執行編譯好的Servlet而直接讀JSP的內容併發送給客戶端,從而讓源代碼一覽無餘。 
JSP源代碼泄漏的幾種類型 
源代碼暴露類別主要指的是程序源代碼會以明文的方式返回給訪問者. 
  我們知道不管是JSP還是ASP、PHP等動態程序都是在服務器端執行的,執行後只會返回給訪問者標準的html 等代碼。這是理論上的東西,實際運行起來由於服務器內部機制的問題就有可能引起源代碼暴露的漏洞,簡單的例子是只要在程序文件名後加幾個簡單的字符就可能獲得程序代碼,如常見微軟ASP 的global.asa+.htr、XXXX.asp%81等等漏洞。 
3.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、+漏洞、%2E、+、%2B、\ 、%5C、%20、%00 等。 
  黑客如果利用該漏洞,將導致泄露指定的JSP文件的源代碼。例一:使用下面的任意一個URL請求將輸出指定的JSP文件的源代碼: 
1)http://target/directory/jsp/file.jsp.  
  2)http://target/directory/jsp/file.jsp%2E 
  3)http://target/directory/jsp/file.jsp+  
  4)http://target/directory/jsp/file.jsp%2B 
  5)http://target/directory/jsp/file.jsp\  
  6)http://target/directory/jsp/file.jsp%5C 
  7)http://target/directory/jsp/file.jsp%20  
  8)http://target/directory/jsp/file.jsp%00  
等等。 
  例二,在Tomcat3.1下,在瀏覽器中本來可以正常解釋執行的是http://localhost:8080/inde.jsp,但是如果將inde.jsp改爲inde.JSP或者inde.Jsp等等試試看,你會發現瀏覽器會提示你下載這個文件,下載後源代碼可以看個一乾二淨。 
  原因是JSP是大小寫敏感的,Tomcat只會將小寫的JSP後綴的文件當作是正常的JSP文件來執行,如果大寫了就會引起Tomcat將inde.JSP當作是一個可以下載的文件讓客戶下載。老版本的WebLogic、WebShpere等都存在這個問題,現在這些公司或者發佈了新版本或者發佈了補丁解決了這問題。 
3.1.1 解決辦法 
解決這種由於添加後綴引起的源代碼泄漏有兩種方法,一種方法是在服務器軟件的網站上下載補丁;另外一種方法是在服務器設置中添加一些映射如.JSP 、.Jsp、.jsp%2E等,將他們映射到一個自己寫的servlet,這個Servlet的唯一功能就是將請求導向一個自定義的類似404 not found的出錯頁面,不同的服務器設置的地方也不同。 
如果沒有使用任何靜態頁面或圖像,可以配置一個默認的 servlet,並將"/"映射到這個默認的 servlet。這樣當收到一個未映射到某個 servlet 的 URL 時,這個默認的servlet 就會被調用。在這種情況下,默認的 servlet 可以僅僅返回"未找到文件"。如果使用了靜態的頁面或圖像,仍然可以作這樣的配置,但是需要讓這個默認的servlet 處理對合法的靜態頁面和圖像的請求。 
  另一種可能就是將*.jsp+、*.jsp.和*.jsp\等映射到一個 servlet,而該servlet只是返回"未找到文件"。對於*.jsp%00和*.jsp%20這樣的情況,映射應以未經編碼的形式輸入。例如,對於*.jsp%20的映射應輸入"*.jsp "。注意%20被轉換成一個空格字符。 
3.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.2.1  解決方法 
在服務器軟件的網站下載最新的補丁。 
3. 3  路徑權限引起的文件JSP源代碼暴露 
這種漏洞在正常的JSP漏洞中沒有反映出來,但是我們知道,大部分的JSP應用程序在當前目錄下都會有一個WEB-INF目錄,這個目錄通常存放的是JavaBeans編譯後的class 文件,如果不給這個目錄設置正常的權限,所有的class就會曝光。 
  也許有人認爲class是經過編譯的,就算被下載也沒有什麼關係,但是現在class 反編譯爲java代碼的軟件也很多,採用反編譯軟件對下載的class文件反編譯後,和原始的java文件幾乎一模一樣,連變量名都沒有變,還可以正常使用。 
  更大的安全問題是,有的軟件開發人員把數據庫的用戶名密碼都寫在了java代碼中,現在一反編譯誰都能看到數據庫的重要信息。通過數據庫的遠程連接功能,可以輕鬆的進入到數據庫中,所有信息將全部被別人掌握。 
3.3.1 解決方法 
有一個方法可以有效地解決由於路徑權限引起的代碼泄漏問題,就是將ASP程序單獨放置一個目錄,設置該目錄上的用戶權限只能執行不能讀取。在JSP環境下同樣可以通過設置服務器的環境來解決這個問題:將一些比較重要的目錄如WEB-INF、classes等設置上訪問的權限,不允許讀而取只允許執行。以Apache 下解決爲例,可以在httpd.conf文件中添加一目錄WEB-INF並設置Deny from all等屬性。 
  另一種解決方法就是在每個重要目錄下添加一個默認起始頁面如index.htm等,這樣讀取目錄就會返回給訪問者這個文件而不是其它了。 
相比較而言,建議採用第一種方法。 
  更爲重要的是密碼的保存問題,在ASP 開發中,可以將密碼文件保存在系統目錄如WINNT 下,然後用一個com來讀取這個文件,這樣就算看到了ASP源代碼也不知道數據庫信息了。在JSP中我們也可以寫一個property文件,放置在WINNT系統目錄下,然後用Bean來讀取數據庫信息,這樣通過源代碼知道了數據庫信息存在WINNT中的.property文件裏面,但也很難訪問它,這樣就算源代碼被人知道起碼數據庫是安全的。 
3. 4  文件不存在引起的絕對路徑暴露問題 
這個問題現在已經出現了很多,因爲微軟IIS 中也有比較多的類似問題,如微軟IIS5.0中的*.idc暴露絕對路徑漏洞。同樣的這些問題現在出現在JSP環境中,這個漏洞暴露了web程序的絕對硬盤地址,和其他漏洞結合就具有比較大的危害了。 
  例如:在特定的服務器軟件下,訪問一個不存在的JSP文件如 <http://localhost:8080/fdasfas.jsp>,就會返回java.servlet.ServletEception: java.io.FileNotFoundEception: c:\web\app\fadssad.jsp (???????????)這樣的錯誤,這樣就可以知道你網站在c:\web\app目錄下,也許一般人不太在意,但是對於一個黑客來說足夠了。 
  原因是由於負責JSP 執行的相關Servlet中處理異常的時候沒有過濾掉這種情況。 
3.4.1  解決方法 
對於因爲文件不存在引起的絕對路徑暴露問題,有兩種解決方法。一種方法是下載最新的補丁。另一種方法是找到服務器軟件的JSP 執行映射Servlet文件(當然是class 後綴的),將它用軟件反編譯,在反編譯後的源代碼中找到處理Eception的方法,然後將方法中的處理部分全部註釋掉,並將請求導向到一個自定義的出錯頁面中,這樣問題就解決了。 
結束語 
通過上面內容我們可以看出,JSP還是存在着很多安全上的問題的,客觀的說,服務器軟件的開發商在內部測試中不可能將系統中的所有BUG找出來,即使發佈了軟件後,被發現的漏洞也只會是其中的很小一部分,將來還會不斷的有新的安全問題出現,所以我們必須時刻提高警惕,並注意自己網站的安全。 


參考文獻 
Bergsten 著,《JSP設計》,中國電力出版社 
http://www.99net.net 
http://www.mhdn.net 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章