JSP安全性初探

綜述：有幾種辦法可以暴露JSP代碼，不過經過大量測試，這和WEB SERVER的配置有絕對的關系，就拿IBM Websphere Commerce Suite而言，還有别的方法看到JSP源代碼，但相信是IBM HTTP SERVER的配置造成的。

如果想發現JSP暴露源代碼的BUG的話，首先需要了解JSP的工作原理。

JSP和其它的PHP、ASP工作機制不一樣，雖然它也是一種web程式設計語言。首次調用JSP檔案其實是執行一個編譯為Servlet的過程。注意我們就要在這上邊做文章，明白嗎？我們要幹的事情是，讓JSP在編譯前被浏覽器當作一個文本或其它檔案發送給用戶端，或在JSP裝載的時候不去執行編譯好的 Servlet而直接讀JSP的内容并發送給用戶端。

明白了道理及所要達到的目的就好下手了，仔細觀察調用及傳回過程可以發現：JSP被編譯為了Servlet儲存在指定的目錄下，如:http: //www.x.com/lovehacker/index.jsp很可能存放在X:\IBM\WAServer\temp\default_host\ default_app\pagecompile\_lovehacker_index_xjsp.class，這是已經編譯過的index.jsp。 _lovehacker_index_xjsp.class顯然是我們不需要的檔案，而且我們得到它的可能性也不大，我們要幹的是不去執行 _lovehacker_index_xjsp.class而是直接讀index.jsp的内容。

據分析最初的xxx.JSP暴露源代碼也是因為前邊的這種想法造成的，本來目錄中存放了一個_xxx_xjsp.class，但通路xxx.JSP本來是個合法的請求，而又找不到對應的Servlet是以就把xxx.JSP當做一個文本或其它檔案發送給了使用者。

也許這是因為IBM HTTP SERVER配置不當造成的，但相信如果能成功的話，會有一種成就感，很爽的哦！

順便說一下暴露檔案存放真實路徑可能會帶來的危害：

1．先會讓入侵者了解磁盤配置情況

2．明的入侵者甚至可以分析出管理者的水準高低

3．為入侵者修改你的首頁提供了友善（起碼不用在找你的WEB目錄在那個磁盤了）

4．可能被利用一些其它的CGI的漏洞查找到Web目錄下的檔案如XX.ASP、XX.JSP、XX.PHP等

JSP安全問題主要有哪幾方面？

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

根據目前已經發現的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下在浏覽器中本來是[url]http://localhost:8080/inde.jsp[/url]，可以正常解釋執行，但是如果将inde.jsp改為inde.JSP或者inde.Jsp等等試試看，你會發現浏覽器會提示你下載下傳這個檔案，下載下傳後源代碼可以看個一幹二淨。

原因：jsp是大小寫敏感的，Tomcat隻會将小寫的jsp字尾的檔案當作是正常的jsp檔案來執行，如果大寫了就會引起Tomcat将 index.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":[url]http://site.running.websphere/login.jsp[/url]，那麼通路http: //site.running.websphere/servlet/file/login.jsp将看到這個檔案的源代碼。

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

解決方法：在伺服器軟體的網站下載下傳最新的更新檔。

3．路徑權限引起的檔案jsp源代碼暴露

我們知道，大部分的jsp應用程式在目前目錄下都會有一個WEB-INF目錄，這個目錄通常存放的是JavaBeans編譯後的class 檔案，如果不給這個目錄設定正常的權限，所有的class就會曝光。

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

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

安全問題更大的就是，網頁制作者開始把資料庫的使用者名密碼都寫在了Java代碼中，現在一反編譯誰都能看到資料庫的重要資訊。通過資料庫的遠端連接配接功能，可以輕松的進入到你的資料庫中，所有資訊全部在他手中。附帶說一句，如果使用者能獲得SQL Server的使用者名密碼，進入資料庫中可以執行任意的dos指令如檢視c:\檔案、建立和删除目錄等，那樣整個Windows系統都不安全了。

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

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

更為重要的是密碼的儲存問題。在jsp中可以寫一個property檔案，放置在WINNT系統目錄下，然後用Bean來讀取資料庫資訊，這樣通過源代碼知道了資料庫資訊存在WINNT中的.property檔案裡面，但也很難通路它，這樣就算源代碼被人知道起碼資料庫是安全的。

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

這個問題相信大家都比較熟悉了，因為微軟IIS 中也有比較多的類似問題。如微軟IIS5.0中的*.idc暴露絕對路徑漏洞。同樣的這些問題現在也轉到了jsp環境中，這個漏洞暴露了web程式的絕對硬碟位址，和其他漏洞結合就具有比較大的危害了

例子：在特定的伺服器軟體下，通路一個不存在的jsp檔案如 [url]http://localhost:8080/fdasfas.jsp[/url]，就會傳回Java.servlet.ServletEception: Java.io.FileNotFoundEception: c:\web\app\fadssad.jsp (???????????)這樣的錯誤，這樣就可以知道網站在c:\web\app目錄下，也許一般人不太在意，但是對于一個黑客來說就是很有幫助了。

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

解決方法：一是下載下傳最新的更新檔；如果當時的web 伺服器軟體沒有這個更新檔，可以找到伺服器軟體的jsp 執行映射Servlet檔案(當然是class 字尾的)，将它用JAD軟體反編譯，在反編譯後的源代碼中找到處理Exception的方法，然後将方法中的處理部分全部注釋掉，并将請求導向到一個自定義的出錯頁面中，這樣問題就解決了。

二、遠端程式執行類

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

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

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

解決方法：安裝最新的更新檔。

三、其他類别

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

四、全文總結

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

一個好的建議就是多看安全文章，這些安全文章一般都會有詳細的資訊如軟體的版本号、漏洞原因等等，最重要的是還附帶了解決辦法或者是更新檔的下載下傳連結，推薦的安全站點是國内的安全站點[url]www.cnns.net[/url]或者國外的[url]http://www.securityfocus.com[/url]站點；另外一個好的建議就是多裝更新檔程式，通路自己所使用的軟體公司首頁，從那上面獲得最新的更新檔程式，做得比較好的就是微軟的站點，安全公告和更新檔都特别及時。

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

哪些方式可實作Java Servlet及JSP的應用安全？

一個web 應用程式可擁有多種資源，經常有許多敏感的資訊在沒有保護措施的情況下在開放性網絡上傳輸。在這種環境下，實際上許多web 應用程式有一定程度的安全性要求。大多數的servlet 容器有明确的機制和結構來達到這種安全要求。雖然保證和執行的細節可能有些不同，但是，都具有下面的特點：

1．Authentication：通訊實體互相驗證對方的行為是以一個明确的身份在進行的一種機制。

2．Access control for resources：對某組使用者來說，對資料庫的某些操作是受到限制的，或對有些程式強調可用性，完整性或保密性的一種機制。

3．Data Integrity：資料在傳遞過程中保證不被第三方修改的一種機制。

4．Confidentiality or Data Privacy：保證資料隻被那些授權使用的使用者使用，能被安全傳遞的一種機制。

Java Servlet，JSP中安全性通過如下幾種方式實作：

一、 Declarative Security

Declarative security指的是表達一個應用的安全結構，包括角色，存取控制，和在一個應用的外部表單所要求的驗證。在web application中釋出描述器是實施declarative security的一種主要的工具。

釋出者把application所要求的邏輯完整性映射為在特定運作環境下的安全政策。在運作時，servlet container使用這些政策來強迫驗證。

二 、Programmatic Security

當declarative security不能夠完全表達一個application的安全模型時，就可以使用programmatic Security。Programmatic Security包括HttpServletRequest接口的下列方法：

getRemoteUser

isUserInRole

getUserPrincipal

getRemoteUser方法傳回經過用戶端驗證的使用者名。IsUserInRole向container的安全機制詢問一個特定的使用者是否在一個給定的安全角色中。GetUserPrinciple方法傳回一個Java.security.Pricipal對象。這些APIs根據遠端使用者的邏輯角色讓servlet去完成一些邏輯判斷。它也可以讓servlet去決定目前使用者的主要名字。如果getRemoteUser傳回null值（這意味着沒有使用者被驗證），那麼isUserInRole就總會傳回false，getUserPrinciple總會傳回null。

三 、Roles

一個Roles就是由Application Developer和Assembler所定義的一個抽象的邏輯使用者組。當一個application被釋出的時候，Deployer就把這些角色映射到在運作環境中的安全認證，例如組或規則。

一個servlet container能夠為規則執行一些說明或程式設計安全，這些規則是與調用這些principal的安全屬性所輸入的要求相聯系的。例如：

1．當deployer把一個安全角色映射為操作環境下的一個使用者組，調用principle所屬的使用者組就從安全屬性中獲得。如果principle的使用者組與在操作環境下的使用者組相比對，那麼principle 就是一個安全角色。

2．當deployeer把一個安全角色映射為一個在安全方針域中的principle名時，調用principle的确principle名就被從安全屬性中提取出來。如果兩者相同的話，調用的principle就是安全的。

四、Authentication

一個web 客端能夠使用下面的一種機制來對web 伺服器驗證一個使用者。

HTTP Digest Authentication

HTTPS Client Authentication

HTTP Basic Authentication

HTTP Based Authentication

五、HTTP Basic Authentication

HTTP Basic Authentication是一個定義在HTTP/1.1規範中的驗證機制。這種機制是以使用者名和密碼為基礎的。一個web server要求一個web client去驗證一個使用者。作為request的一部分，web server 傳遞被稱之為realm的字元串，使用者就是在它裡面被驗證的。注意：Basic Authentication機制的realm字元串不一定反映任何一種安全方針域。Web client得到這些使用者名和密碼，然後把它傳遞給web server。Web server然後在一個特定的領域驗證這些使用者。

由于密碼是使用一種64位的編碼來傳遞，而且目的server沒有驗證，是以Basic Authentication不是一種安全的驗證協定。然而一些附加的保護像使用一種安全傳輸機制（HTTPS）或在網絡層使用安全措施能夠解決一些問題。

六、HTTP Digest Authentication

與HTTP Digest Authentication一樣，HTTP Digest Authentication根據使用者名和密碼驗證一個使用者。然而密碼的傳輸是通過一種加密的形式進行的，這就比Basic Authentication所使用的64位編碼形式傳遞要安全的多。這種方法沒有像HTTPS Client Authentication的個人密鑰方案安全。由于Digest Authentication目前不被廣泛使用，servlet containers不要求支援它但是鼓勵去支援它。

七、HTTPS Client Authentication

使用HTTPS（HTTP over SSL）的終端使用者驗證是一種嚴格非驗證機制。這種機制要求使用者去處理公共密鑰證明（Public Key Certification PKC）。目前，PKCs在e-commerce應用中是有用的。不适應J2EE的servlet containers不要求支援HTTPS協定。

八、Server Tracking of Authentication Information

就像映射在角色中的安全辨別一樣，運作環境是環境的說明而不是應用的說明。

1．在web application的釋出環境建立一個登入機制和政策。

2．對釋出在同一個container的application能夠使用同樣的驗證資訊來代表這些application的principal。

3．僅僅當通過安全政策域時要求使用者重新驗證。

是以，一個servlet container要求在container層來跟蹤這些驗證資訊，而不是在application層。允許一個經驗證的使用者拒絕一個使用其它資源的application，這些是通過受同樣安全性辨別限制的container管理的。

<a href="http://down.51cto.com/data/2347394" target="_blank">附件：http://down.51cto.com/data/2347394</a>

本文轉自loveme2351CTO部落格，原文連結：http://blog.51cto.com/loveme23/8526 ，如需轉載請自行聯系原作者