OWASP 10 大 Web 安全問題在 JEE 體系完全失控

雖然，JavaEE 內建了一些非常優秀的安全機制，但是它不能全面應對應用程式面臨的各種威脅，尤其許多最常見的攻擊：跨站攻擊（XSS），SQL 注入，Cross-Site Request Forgery (CSRF), 與 XML eXternal Entities (XXE) 等。如果你不對系統做大量的安全測試、漏洞修補以及購買應用級安全防護工具，應用程式就完全暴露在這些攻擊之下。

幸運的是，開源 Web 應用安全組織（OWASP）已經將這下面10個 Web 問題列為最重要的安全攻擊，詳情請參見：「Ten Most Critical Web Application Security Risks」 報告。 希望引起大家這些安全問題的足夠重視。

下面就詳細解釋一下這些最著名的安全攻擊在 JavaEE 的 Web 應用程式和 Web 服務上是如何工作的：

1、注入攻擊

在編寫程式時，任何可疑的資訊輸入都可能是注入攻擊，比如 request.getParameter(), request.getCookie() 以及request.getHeader()，甚至在使用者命令列介面也存在注入風險。如果開發人員以資料和 SQL 命令拼接的方式形成 SQL 語句就存在 SQL 注入風險，比如： “SELECT * FROM users WHERE username=‘“ + request.getParameter(“user”) + “‘ AND password=‘“ + request.getParameter(“pass”) = “‘“; 開發者正確的寫法應該是用 PreparedStatement 方式避免黑客有機會改變 SQL 語句的原意進而控制資料庫。除了 SQL 注入還有很多注入攻擊的方式，包括：Command Injection, LDAP Injection, 與 Expression Language (EL) Injection，所有的這些注入都非常非常危險，在編寫接受資料的模組時一定要非常非常小心。

2、失效的身份和回話管理

JavaEE 對身份校驗和會話管理都能夠支援，但是安全方面做得很不夠，有很多種方法可以破壞。程式設計師不得不確保每個身份校驗都通過 SSL 安全通道，並且還要確保沒有異常發生。如果不幸暴露了一個 JSESSIONID，黑客只要掌握了該 JSESSIONID 就可以劫持會話，很多時候為了防止會話固定攻擊還不得不對 JSESSIONID 進行混淆。使用 response.encodeURL() 將 JSESSIONID 加到 URL 裡面是非常危險的，JSESSIONID 很容易被偷竊，這種行為一定要避免。

3、Cross-Site Scripting (XSS)

若應用程式收到不可信的資料，在沒有進行適當的驗證和轉義的情況下，就將它傳送給一個網頁瀏覽器，就會產生跨站指令碼攻擊（簡稱 XSS）。XSS 允許攻擊者在受害者的瀏覽器上執行指令碼，從而劫持使用者會話、危害網站、或者將使用者轉向惡意網站。

4、不安全的直接物件引用

當開發人員暴露一個對內部實現物件的引用時，例如，一個檔案、目錄或者資料庫密匙，就會產生一個不安全的直接物件引用。在沒有訪問控制檢測或其他保護時，攻擊者會操控這些引用去訪問未授權資料。

5、安全配置錯誤

現代 JavaEE 應用程式和框架如 Struts，Spring 都有很多的安全配置，當使用這些框架一定要確保這些配置是正確的。比如在開發 Web 應用程式時一定要當心 裡的 標籤，該標籤的意思是 security-constraint 只作用於標籤裡面列出的方法，黑客可以利用這個使用列表以外的方法如：HEAD 和 PUT 進行攻擊，從而越過安全限制。大多數情況下開發者應該刪掉 web.xml 裡面的 標籤。

6、敏感資訊洩露

Java 使用擴充套件庫的方式實現加解密，Java 提供通用的介面，任何使用者，只需要簡單的配置，都可以根據介面來實現加密，這樣的好處是擴充套件性很強，弊端是如何正確使用密碼庫是非常不容易事情：第一步，找一個基於 JCE 的頂級加密庫，提供簡單、安全的加密方法，Jasypt 與 ESAPI 就非常不錯。第二步，應該使用強加密演算法如：加密用 AES，雜湊用 SHA256，像密碼這種敏感資訊，廣雜湊是不夠的，黑客可以通過 Rainbow 表來破譯，因此需使用自適應安全演算法如 bcrypt 或 PBKDF2。任何使用不當都可能造成敏感資訊洩露。

7、功能級訪問控制缺失

JavaEE 同時支援宣告式和程式設計兩種訪問控制方式，像 Spring 等框架也支援基於註解的訪問控制，但是很多應用程式還是選擇建立自己的訪問控制流程，其實這是非常危險的行為。更重要的是要確保每一個暴露出去的介面和 Web 服務要有正確的訪問控制，千萬不要想當然的假設客戶應該可以控制一切，這樣黑客就可以直接訪問程式了。

8、 跨站請求偽造（CSRF ）

每一個狀態改變，應用程式都應該校驗該請求是否偽造，開發者在每一個使用者會話裡面放置一個隨機令牌，然後每次請求進來都進行校驗，否則攻擊者可能會建立一些包含有害標籤，例如：IMG, SCRIPT, FRAME 或者 FORM，這些標籤可能會指向沒有保護的應用程式，當受害者訪問這樣的頁面，瀏覽器就會自動產生一個偽造的 HTTP 請求到標籤裡指定的 URL，這個 URL 通常會包含受害者的憑證。

9、使用含有已知漏洞的元件

現代 JavaEE 應用程式通常會包括數百種庫，尤其像依賴管理工具問世5年來，這個數目更是爆炸式的增長。廣泛應用的Java 庫都包含了很多已知漏洞，這些漏洞非常危險。對這些漏洞沒有其他辦法，只能等庫的提供商修復漏洞，及時更新到最新版本。

10、未驗證的重定向和轉發

 Web 應用程式經常將使用者重定向或轉發到其他網頁和網站，並且利用不可信的資料去判定目的頁面。如果沒有得到適當驗證，攻擊者可以重定向受害使用者到釣魚軟體或惡意網站，或者使用轉發去訪問未授權的頁面， 在 JavaEE Web 程式裡當呼叫 response.sendRedirect() 在使用 request.getParameter() 或 request.getCookie() 去獲取不信任的資料時，經常會發生這種情況。

每個 JavaEE 程式設計師一定會經常遇到這十個安全問題，同時新的攻擊和漏洞不斷地被發現，我們現在能做的就是在開發、測試和部署的過程中不斷地用安全程式碼檢查工具對專案進行掃描，檢查不修復漏洞。

大家可以嘗試用 Eclipse 的一些免費對比外掛來檢查這些漏洞，這些不僅是靜態分析工具，C4E 是一個非常有代表意義的工具，它利用 Java Instrumentation API 去見監控應用中所有和安全相關的內容。 它還可以實時分析整個資料流，在一個複雜的應用裡從請求開始跟蹤資料。 比如 JavaEE Web 應用裡常見的資料流如下：程式碼從 request 取得引數，用 base64 解碼，把資料存到 Map 裡，再將 Map 存到一個 Bean 裡面，然後將這個Bean 放到 Session 裡作為 attribute，最後從 JSP 裡取出，使用 EL 語言將這個 Bean 值填入頁面。Eclipse 對比工具就可以跟蹤這個資料流並報告是否存在 XSS 漏洞。這個工具非常方便，甚至對使用了非常複雜的框架和庫的應用程式也管用，較現有的很多分析工具在速度，準確性和易用性上都有明顯優勢。

當然，還有現在非常流行的 RASP（Runtime Aplication Security Protector），也是對付這十大安全問題的利器，它將程式碼實時檢查和實時攔截相結合，將安全保護程式碼和應用程式結合在一起，像疫苗一樣使應用程式具備自我免疫的能力。這是 Gartner 極力推薦的應用程式安全保護方案，它使用非常方便，保護實時徹底，容易使用，不需要修改任何應用程式程式碼就可以輕鬆實現安全保護。