在用JSP制作的電子商務網站多如牛毛。但是對于JSP網站而言，安全性真的能夠讓人放心嗎？面對層出不窮的黑客攻擊和病毒襲擊，JSP網站的服務器能夠比其他網站的服務器器更加安全嗎？前段時間，應朋友之邀，我對他們托管的三臺服務器的主機進行了測試，發(fā)現(xiàn)了JSP網站存在的幾個問題。
　　入侵測試第一步：掃描
　　掃描是入侵的第一步，它可以讓你對即將入侵的目標有一個全面的了解。同時掃描還有可能發(fā)現(xiàn)掃描對象的漏洞，為入侵提供一個指導方向。
　　朋友的兩臺服務器為Linux，一臺為Windows系統(tǒng)，在路由器后面還有一臺Cisco PIX 525對三臺主機進行保護，只允許外部用戶連接不同主機的部分端口，例如80,25,110。
　　根據(jù)檢測，Cisco PIX防火墻過濾規(guī)則設置比較嚴密，基本上沒有多余端口允許外部用戶訪問。細致分析后，我發(fā)現(xiàn)，目標網絡的主機通過地址轉換來提供對外訪問，內部使用192.168.*.*地址段。
　　先不考慮那么多，找個掃描軟件來看看主機的安全情況。我找來了X-Scan，在外部對這幾臺主機進行了端口掃描之后，生成了一份關于端口的報表，發(fā)現(xiàn)其中有一個Tomcat服務器，解釋的自然就是JSP文件了。
　　小知識：
　　Tomcat Web服務器是一款開源的適合于各種平臺的免費網絡服務器。eBay.com與Dell 計算機等知名網站都采用或者曾經采用Tomcat的container容器執(zhí)行Servlet 與JSP。
　　看來，只能通過Web服務進行間接攻擊。首先檢查TCP 80端口的服務。我發(fā)現(xiàn)，新聞搜索的功能是由端口8080提供的，輸入http:// 202.103.*.168:8080/之后，得到了一個系統(tǒng)管理登錄頁面，簡單地測試了一下，輸入“test/test”作為“用戶名/口令”，似乎認證成功，但實際上并不能進入下一個頁面。
　　專家支招：對于掃描來說，它很容易暴露我們網站的弱勢方面。應對掃描，我們可以架設一個蜜罐來誤導掃描者，蜜罐可以讓系統(tǒng)偽裝成到處是漏洞，從而遮蔽真正存在的漏洞，也可以偽裝成沒有任何漏洞，讓入侵者不知道從何入手。
　　入侵測試第二步：漏洞嘗試
　　嘗試JSP各種已知漏洞，這個是在掃描結果中無法獲得任何有效信息指導入侵的情況下，被迫使用的方法。這種方法雖然效果不一定好，但是往往能夠起到意想不到的效果，從而讓入侵繼續(xù)下去。
　　我進行了JSP大小寫的測試，因為JSP對大小寫是敏感的，Tomcat只會將小寫的jsp后綴的文件當作是正常的JSP文件來執(zhí)行，如果大寫了就會引起Tomcat將index.JSP當作是一個可以下載的文件讓客戶下載，若干測試后，我發(fā)現(xiàn)這個方法并不奏效，可能管理員已經在服務器軟件的網站上下載了最新的補丁。
　　我發(fā)現(xiàn)大部分的JSP應用程序在當前目錄下都會有一個WEB-INF目錄，這個目錄通常存放的是JavaBeans編譯后的class 文件，如果不給這個目錄設置正常的權限，所有的class就會曝光。
　　而采用JAD軟件對下載的class文件反編譯后，原始的Java文件甚至變量名都不會改變。如果網頁制作者開始把數(shù)據(jù)庫的用戶名密碼都寫在了Java代碼中，反編譯后，說不定還能看到數(shù)據(jù)庫的重要信息。那么，怎么得到這些文件呢？
　　Tomcat版本的缺省“/admin”目錄是很容易訪問的。輸入：http://202.103.*.168/admin/，管理員目錄赫然在列。默認情況下，“User Name”應該是admin，“Password”應該是空，輸入用戶和密碼后，并點擊“Login”按鈕，不能進入，陸續(xù)使用了幾個比較常見的密碼，也無濟于事。
　　默認情況下，Tomcat打開了目錄瀏覽功能，而一般的管理員又很容易忽視這個問題。也就是說，當要求的資源直接映射到服務器上的一個目錄時，由于在目錄中缺少缺省的index.jsp等文件，Tomcat將不返回找不到資源的404錯誤，而是返回HTML格式的目錄列表。
　　想到了這點后，我打開剛才用X-Scan掃描后生成的報表文件，找到“安全漏洞及解決方案”欄目，看到了幾個可能會有CGI漏洞的目錄。在地址欄輸入其中之一，返回結果如圖1所示。

一些很典型的JSP文件和JS文件都列出來了。大喜之下，隨便選擇一個文件，點擊右鍵，然后，選擇“用FlashGet下載全部鏈接”選項，于是，這個目錄下的所有文件都被我下載到了本地。
其中最有價值的是一個名字為dbconn.js的文件，看來程序設計者是為了方便省事，把一些數(shù)據(jù)庫連接的密碼和連接地址都寫在里面了（這是很多開發(fā)者可能會忽略的問題）。不過，我現(xiàn)在最關心的還是Tomcat的管理員密碼。
　　簡單破解后，發(fā)現(xiàn)Tomcat系統(tǒng)中的admin用戶使用了非常簡單的口令：web123456。利用這個漏洞，有了這個密碼，下面的工作就相對簡單了。
　　專家支招：對于網站中的漏洞，我們要即時打上各種補丁，然后對幾個已知的安全弱勢方面進行加強，比如我們可以將“/admin”目錄進行修改，讓入侵者不容易找到管理路徑。然后關閉Tomcat的目錄瀏覽功能，讓入侵者的漏洞嘗試徹底失敗。
　　入侵測試第三步：注入攻擊
　　很多網站對于注入防范做得都很不到位，注入攻擊可以讓網站暴露出自己的數(shù)據(jù)庫信息以至于暴露數(shù)據(jù)庫表中的管理員賬號和密碼。
　　重新登錄Tomcat的管理界面，點擊“Context （Admin）”這個鏈接，列出了WEB目錄下的一些文件和目錄的名稱，現(xiàn)在就可以對Tomcat的Context進行管理，例如查看、增加、刪除Context。
　　回到Tomcat的管理界，我發(fā)現(xiàn)了一個上傳文件的組件，并且網站還有一個論壇。于是，我編寫了一個input.jsp文件，并將它當作一般的Web 應用程序，通過上傳的組件上傳到對方的WEB目錄里。打開input.jsp這個頁面（圖2）。

　　網頁對查詢窗體不會做任何輸入驗證，但是對用戶名稱的窗體則會。將數(shù)據(jù)填入窗體，來測試一下網頁的漏洞，例子如下：
　?。?）將javascript">alert(document.cookie)填入搜索字段，以便用XSS 來顯示進程的cookie。
　?。?）將填入搜索字段來示范HTML 注入攻擊。
　　通過這些方法，我得到了一些論壇的用戶信息，當然，這些都是針對JSP做的一些測試，以驗證Web應用程序中的所有輸入字段。有了用戶信息，卻沒有密碼，怎么辦？在登錄時，我發(fā)現(xiàn)了一個8888端口，這會是個什么服務呢？
　　專家支招：在網頁連接數(shù)據(jù)庫的設計中，網頁設計人員要加入對一些敏感符號的審核機制，屏蔽一些在數(shù)據(jù)庫中有作用的符號，這可以在很大程度上成功防御注入攻擊。
　　入侵第四步：攻其“軟肋”
　　根據(jù)入侵的逐漸深入，系統(tǒng)存在的安全問題也漸漸清楚，下面就是針對網站的安全“軟肋”進行攻擊。一般針對安全“軟肋”的攻擊會使入侵成功。
　　打開地址后，我發(fā)現(xiàn)這個端口運行的是Apache PHP。也就是說，這臺主機還可以編譯PHP。從經驗分析來看，管理員在JSP主機上同時安裝PHP的主要目的可能是為了管理MySQL數(shù)據(jù)庫。因此，這個端口很可能有phpMyadmin這款MySQL數(shù)據(jù)庫管理軟件。這個端口上會不會有數(shù)據(jù)庫管理目錄呢？果然不出我所料，在輸入這個目錄之后我發(fā)現(xiàn)，我進入了一個phpMyadmin的管理界面，可以對MySQL數(shù)據(jù)庫進行任意操作。它支持從本地操作系統(tǒng)讀入或者寫入數(shù)據(jù)。更不可理解的是，管理員居然用root賬戶寫在了數(shù)據(jù)庫鏈接里面，想不控制這個數(shù)據(jù)庫都不行了。
　　打開其中的一個數(shù)據(jù)庫，在“SQL”中輸入“SELECT * FROM `administer`”，administer表中的數(shù)據(jù)全部顯示出來了。和我前面用JSP探測的用戶類型大致一致。至于他們的表和數(shù)據(jù)的刪改權限，現(xiàn)在則完全在我的掌握之中了。
　　專家支招：使用了一些軟件的時候，我們盡量修改它的默認目錄，將它改為一個不容易被猜解到的名字。同時在訪問該目錄的時候加入密碼審核機制，就算入侵者找到了這個管理目錄也無法獲得進入目錄的密碼。

最新評論