摘要：希望引起大家這些安全問題的足夠重視。允許攻擊者在受害者的瀏覽器上執(zhí)行腳本，從而劫持用戶會話危害網站或者將用戶轉向惡意網站。

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

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

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

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

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

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

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

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

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

JavaEE 同時支持聲明式和編程兩種訪問控制方式，像 Spring 等框架也支持基于注解的訪問控制，但是很多應用程序還是選擇創(chuàng)建自己的訪問控制流程，其實這是非常危險的行為。更重要的是要確保每一個暴露出去的接口和 Web 服務要有正確的訪問控制，千萬不要想當然的假設客戶應該可以控制一切，這樣黑客就可以直接訪問程序了。

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

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

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

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

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

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