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 服務上是如何工做的：

一、注入攻擊

在編寫程序時，任何可疑的信息輸入均可能是注入攻擊，好比 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，全部的這些注入都很是很是危險，在編寫接受數據的模塊時必定要很是很是當心。

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

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

三、Cross-Site Scripting (XSS)

若應用程序收到不可信的數據，在沒有進行適當的驗證和轉義的狀況下，就將它發送給一個網頁瀏覽器，就會產生跨站腳本攻擊（簡稱 XSS）。XSS 容許攻擊者在受害者的瀏覽器上執行腳本，從而劫持用戶會話、危害網站、或者將用戶轉向惡意網站。

四、不安全的直接對象引用

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

五、安全配置錯誤

現代 JavaEE 應用程序和框架如 Struts，Spring 都有不少的安全配置，當使用這些框架必定要確保這些配置是正確的。好比在開發 Web 應用程序時必定要小心 <security-constraint> 裏的 <http-method> 標籤，該標籤的意思是 security-constraint 只做用於標籤裏面列出的方法，黑客能夠利用這個使用列表之外的方法如：HEAD 和 PUT 進行攻擊，從而越過安全限制。大多數狀況下開發者應該刪掉 web.xml 裏面的 <http-method>標籤。

六、敏感信息泄露

Java 使用擴展庫的方式實現加解密，Java 提供通用的接口，任何用戶，只須要簡單的配置，均可以根據接口來實現加密，這樣的好處是擴展性很強，弊端是如何正確使用密碼庫是很是不容易事情：第一步，找一個基於 JCE 的頂級加密庫，提供簡單、安全的加密方法，Jasypt 與 ESAPI 就很是不錯。第二步，應該使用強加密算法如：加密用 AES，哈希用 SHA256，像密碼這種敏感信息，廣哈希是不夠的，黑客能夠經過 Rainbow 表來破譯，所以需使用自適應安全算法如 bcrypt 或 PBKDF2。任何使用不當均可能形成敏感信息泄露。

七、功能級訪問控制缺失

JavaEE 同時支持聲明式和編程兩種訪問控制方式，像 Spring 等框架也支持基於註解的訪問控制，可是不少應用程序仍是選擇建立本身的訪問控制流程，其實這是很是危險的行爲。更重要的是要確保每個暴露出去的接口和 Web 服務要有正確的訪問控制，千萬不要想固然的假設客戶應該能夠控制一切，這樣黑客就能夠直接訪問程序了。

八、 跨站請求僞造（CSRF ）

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

九、使用含有已知漏洞的組件

現代 JavaEE 應用程序一般會包括數百種庫，尤爲像依賴管理工具問世5年來，這個數目更是爆炸式的增加。普遍應用的Java 庫都包含了不少已知漏洞，這些漏洞很是危險。對這些漏洞沒有其餘辦法，只能等庫的提供商修復漏洞，及時更新到最新版本。

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

 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 極力推薦的應用程序安全保護方案，它使用很是方便，保護實時完全，容易使用，不須要修改任何應用程序代碼就能夠輕鬆實現安全保護。