關于JSP源碼泄漏問題的總結分析
JSP編程語言自從推出之日起，由于它的快速、平臺無關、可擴展、面向對象等特性得到了越來越廣泛的應用，越來越多的廠家開發出了各種各樣的支持平臺如IBM 公司的WebSphere、BEA公司的WebLogic等等，也有越來越多的網站開始將自己的平臺架構在JSP 環境中。
但是隨之而來的就是一系列的安全問題，如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等等漏洞。
一、添加特殊后綴引起JSP源碼泄露
在JSP中也存在著和asp這些漏洞類似的問題，如IBM Websphere Application Server 3.0.21、BEA Systems Weblogic 4.5.1、Tomcat一等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
等等。
例二，在Tomcat一下，在瀏覽器中本來可以正常解釋執行的是http://localhost:8080/inde.jsp，但是如果將inde.jsp改為inde.JSP或者inde.Jsp等等試試看，你會發現瀏覽器會提示你下載這個文件，下載后源代碼可以看個一干二凈。
原因是JSP是大小寫敏感的，Tomcat只會將小寫的JSP后綴的文件當作是正常的JSP文件來執行，如果大寫了就會引起Tomcat將inde.JSP當作是一個可以下載的文件讓客戶下載。老版本的WebLogic、WebShpere等都存在這個問題，現在這些公司或者發布了新版本或者發布了補丁解決了這問題。
解決辦法
解決這種由于添加后綴引起的源代碼泄漏有兩種方法，一種方法是在服務器軟件的網站上下載補丁；另外一種方法是在服務器設置中添加一些映射如.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被轉換成一個空格字符。
二、插入特殊字符串引起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 會被調用這個請求的文件會未被分析或編譯就顯示出來。
解決方法
在服務器軟件的網站下載最新的補丁。
三、路徑權限引起的文件JSP源碼泄露
這種漏洞在正常的JSP漏洞中沒有反映出來，但是我們知道，大部分的JSP應用程序在當前目錄下都會有一個WEB-INF目錄，這個目錄通常存放的是JavaBeans編譯后的class 文件，如果不給這個目錄設置正常的權限，所有的class就會曝光。
也許有人認為class是經過編譯的，就算被下載也沒有什么關系，但是現在class 反編譯為java代碼的軟件也很多，采用反編譯軟件對下載的class文件反編譯后，和原始的java文件幾乎一模一樣，連變量名都沒有變，還可以正常使用。
更大的安全問題是，有的軟件開發人員把數據庫的用戶名密碼都寫在了java代碼中，現在一反編譯誰都能看到數據庫的重要信息。通過數據庫的遠程連接功能，可以輕松的進入到數據庫中，所有信息將全部被別人掌握。
解決方法
有一個方法可以有效地解決由于路徑權限引起的代碼泄漏問題，就是將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文件里面，但也很難訪問它，這樣就算源代碼被人知道起碼數據庫是安全的。
四、文件不存在引起的絕對路徑JSP源碼泄露
這個問題現在已經出現了很多，因為微軟IIS 中也有比較多的類似問題，如微軟IIS5.0中的*.idc暴露絕對路徑漏洞。同樣的這些問題現在出現在JSP環境中，這個漏洞暴露了web程序的絕對硬盤地址，和其他漏洞結合就具有比較大的危害了。
例如：在特定的服務器軟件下，訪問一個不存在的JSP文件如
原因是由于負責JSP 執行的相關Servlet中處理異常的時候沒有過濾掉這種情況。
解決方法
對于因為文件不存在引起的絕對路徑暴露問題，有兩種解決方法。一種方法是下載最新的補丁。另一種方法是找到服務器軟件的JSP 執行映射Servlet文件(當然是class 后綴的)，將它用軟件反編譯，在反編譯后的源代碼中找到處理Eception的方法，然后將方法中的處理部分全部注釋掉，并將請求導向到一個自定義的出錯頁面中，這樣問題就解決了。
結束語
通過上面內容我們可以看出，存在著很多安全上的JSP源碼泄露問題的，客觀的說，服務器軟件的開發商在內部測試中不可能將系統中的所有BUG找出來，即使發布了軟件后，被發現的JSP源碼泄露也只會是其中的很小一部分，將來還會不斷的有新的安全問題出現，所以我們必須時刻提高警惕，并注意自己網站的安全。
【編輯推薦】
