Java 安全現狀警鐘：XSS、SQL注入、本地方法成三大隱患

背景：Fortify 年度掃描報告

• JavaOne 大會：Fortify 首席科學家 Brian Chess 連兩年發布《Java 12 大技術陷阱》
• Fortify Open Review 專案：用 FindBugs 掃描 Apache、Azureus、Tomcat 等開源項目
• 結果震驚：缺陷密度達「天文數字」級 —— Net Trust 專案每 1000 行代碼 12215 個缺陷
• 諷刺：Net Trust 是 Google 單點登錄項目，「像沒寫完作業的學生」

三大核心弱點類別

XSS 深度剖析：為什麼成了「新緩衝區溢出」？

• 利用門檻極低：買本 Java 書就能學會 XSS，無需理解 CPU 架構、棧佈局、Shellcode
• 瀏覽器即執行環境：注入腳本在受害者瀏覽器運行，繞過服務端防禦
• 存儲型/反射型/DOM 型 全棧覆蓋，防禦面極廣

Sun 官方文檔中的反面教材

try {
    firstname = request.getParameter("firstname");
} catch (Exception e) { e.printStackTrace(); }
userName = firstname;
// ...
pw.print("Thanks for your feedback, " + userName + "!");

攻擊者輸入：<script>sendDataToMotherShip()</script> → 受害者瀏覽器執行惡意代碼。

正確防禦姿勢

1. 輸出編碼：HTML 實體編碼 (<→<)、JS 編碼、CSS 編碼、URL 編碼
2. 模板引擎自動轉義：Thymeleaf、FreeMarker、JSP EL ${} 默認轉義
3. CSP (Content Security Policy)：Content-Security-Policy: script-src 'self' 禁用內聯腳本
4. HttpOnly + Secure Cookie：緩解 Cookie 竊取
5. 輸入驗證：白名單校驗，但不能替代輸出編碼

SQL 注入：經久不衰的頭號殺手

• 根因：數據與代碼未分離
• 唯一徹底方案：參數化查詢 (PreparedStatement) / ORM 安全 API
• 補充：最小權限賬號、WAF、存儲過程 (需參數化)、輸入長度限制

本地方法：隱形殺手

• JNI 打破 Java 記憶體安全邊界，C 代碼崩潰 → JVM 進程崩潰
• 審計重點：GetByteArrayElements/ReleaseByteArrayElements 配對、邊界檢查、異常處理、ExceptionCheck()
• 現代替代：JNA (純 Java)、Foreign Function & Memory API (JEP 454, JDK 22+) 受控內存訪問

為什麼開源項目也淪陷？

1. 貢獻者水平參差不齊，安全意識薄弱
2. 缺乏專職安全審計、CI 無靜態分析 (SAST) 門禁
3. 依賴傳遞性漏洞：commons-collections 反序列化、log4j2 JNDI 注入

解決之道：體系化防禦

給開發者的行動清單

• 🔴 立即檢查：所有 request.getParameter() 直接輸出到 HTML/JS/CSQL 的點
• 🟡 本周完成：項目接入 SpotBugs + FindSecBugs 插件、啟用 CI 門禁
• 🟢 本月完成：依賴掃描修復高危 CVE、配置 CSP/HttpOnly、補全輸出編碼工具類

安全不是功能，是質量屬性。「開發者承擔全部責任」 —— 沒有銀彈，唯有體系化工程紀律能築起防線。