JSP 架構廣泛應用於電子商務系統，但其安全性常被過高估計。受邀對友方託管的三台服務器（兩台 Linux、一台 Windows）進行授權滲透測試，前端部署 Cisco PIX 525 防火牆，僅開放 80/25/110 端口，內網採用 192.168.x.x 地址段 NAT 映射。本文記錄完整測試過程，旨在為 JSP 應用安全建設提供參考。

第一階段：資產發現與服務識別

防火牆規則嚴格，常規端口掃描受限。使用 X-Scan 對外部映射地址進行掃描，發現目標運行 Tomcat 服務器（如圖 1 所示），確認 JSP 運行環境。

小知識： Tomcat 是開源免費的 Servlet/JSP 容器，eBay、Dell 等知名企業均曾大規模採用。其默認配置若未加固，極易成為攻擊入口。

第二階段：Web 層攻擊面探測

重點檢查 TCP 80/8080 服務。訪問 https://202.103.x.168:8080/ 發現系統管理登錄頁。嘗試弱口令 test/test 通過前端驗證但無法進入後台，疑為蜜罐或雙因子認證機制。

第三階段：已知漏洞嘗試與配置缺陷挖掘

針對 JSP 大小寫敏感特性測試 index.JSP 繞過（Tomcat 僅解析小寫 .jsp），但目標已打補丁修復。轉而關注 WEB-INF 目錄保護狀態——該目錄存放編譯後的 .class 文件，若權限配置不當將導致源碼級洩露。使用 JAD 反編譯工具可還原變量名級別的 Java 源碼，若開發者將數據庫憑證硬編碼在代碼中，後果不堪設想。

第四階段：Tomcat 管理後台與目錄瀏覽漏洞利用

• 管理後台弱口令： 訪問 /admin/ 默認用戶名 admin、密碼為空，嘗試常見密碼均失效，管理層已修改默認憑證。
• 目錄瀏覽洩露： Tomcat 默認開啟目錄列表功能。缺少 index.jsp 等默認文檔時，直接返回目錄結構。結合掃描報告中的疑似 CGI 漏洞目錄，直接訪問獲取敏感路徑列表（參考圖 1）。

第五階段：敏感文件下載與源碼審計

利用目錄瀏覽定位 WEB-INF/classes/ 及 WEB-INF/lib/，批量下載 .class 文件。反編譯後發現：

1. 數據庫連接配置類中明文存儲 JDBC URL、用戶名、密碼
2. 部分業務邏輯存在 SQL 拼接，存在二階注入風險
3. 發現硬編碼的第三方支付 API Key 及加密密鑰

防禦加固清單

層面	加固措施
Tomcat 配置	關閉目錄瀏覽（web.xml 設 listings=false）；禁用/重命名 /admin、/manager 管理應用；修改默認端口 8080
應用代碼	敏感配置移至外部加密配置中心（如 Spring Cloud Config + Vault）；杜絕硬編碼憑證；使用參數化查詢/ORM 防注入
部署架構	WEB-INF 目錄嚴禁對外訪問（Nginx/Apache 層面 location ~ /WEB-INF { deny all; }）；靜態資源與動態應用分離部署
網絡邊界	防火牆僅放行業務必要端口；管理後台僅允許堡垒機/運維 IP 訪問；啟用 WAF 規則集
監控審計	部署 RASP/IAST 實時檢測反序列化、表達式注入等高危行為；定期掃描類路徑敏感信息

總結

本次測試未利用 0day 漏洞，純粹通過「配置缺陷（目錄瀏覽）→ 敏感文件洩露 → 源碼審計 → 憑證獲取」這一經典邏輯鏈即可拿下核心資產。說明 JSP 應用安全的關鍵不在框架本身，而在於：

1. 容器默認配置必須加固
2. 敏感信息絕不進代碼倉庫與編譯產物
3. 纵深防禦：網絡、應用、數據多層防護同步建設

安全是系統工程，而非單點產品的疊加。持續的滲透測試與紅藍對抗，才能在攻擊者之前發現並修復風險。