其實我相信還有幾種辦法可以暴露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:IBMWAServerempdefault_hostdefault_apppagecompile\_lov
~~~~
ehacker_index_xjsp.class
~~~~~~~~~~~~~~~~~~~~~~~~
已經過編譯的index.jsp(順便說一下,IBM WCS我至少發現了三種以上獲得文件存放真實路徑的辦法,但可笑的是我和IBM的工程師聊到這事的時候他們不以為然)

回到正題,也就是說_lovehacker_index_xjsp.class顯然是我們不需要的文件,而且我們得到它的可能性也不大,我們要干的是不去執行_lovehacker_index_xjsp.class而是直接讀index.jsp的內容.我在我的SERVER上已經完成了這個工作,源代碼盡收眼底,你呢？是否也已經想好了辦法？那還等什么趕快去實踐吧！

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

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

順便說一下暴露文件存放真實路徑可能會帶來的危害:
首先會讓入侵者了解磁盤配置情況
聰明的入侵者甚至可以分析出管理員的水平高低
為入侵者修改你的首頁提供了方便(起碼不用在找你的WEB目錄在那個磁盤了)
可能被利用一些其它的CGI的漏洞查看到web目錄下的文件如XX.ASP,XX.JSP,XX.PHP等.