Java作為目前十分熱門的程序語言，其發展可謂一波三折，長期被人唱衰，但卻在一段時間的相對沉寂之后再度強勢崛起。根據最新的數據顯示，Java目前已經成為排名第一的編程語言。

中培偉業《JAVA高級開發技術實戰》培訓專家程老師在這里介紹了JavaEE中遺漏的那些重要的安全控制。程老師指出，JavaEE有一些超贊的內置安全機制，但它們遠遠不能覆蓋應用程序要面臨的所有威脅。很多常見攻擊，例如跨站點腳本攻擊(XSS)、SQL注入、跨站點偽造請求(CSRF)，以及XML外部實體(XXE)絲毫沒有涵蓋。你可以阻止 web 應用程序和web服務暴露于這些攻擊，但這需要一定量的工作和測試。幸運的是，Open Web Application Security Project(OWASP)公布了“10大最關鍵的web應用程序安全風險”的報告。 

讓我們來看看這些關鍵的風險如何應用于JavaEE的web應用程序和web服務：

　　1. 注入

注入發生在開發人員獲取不可信的信息，例如request.getParameter()，request.getCookie()，或request.getHeader()，并在命令接口中使用它的任何時候。例如，SQL注入在你連接不可信的數據到常規SQL查詢，如“SELECT * FROM users WHERE username=‘“ + request.getParameter (“user”) + “‘AND password=‘“ + request.getParameter (“pass”) = “‘“時發生。開發人員應該使用PreparedStatement來防止攻擊者改變查詢的含義和接管數據庫主機。還有許多其他類型的注入，如Command注入、LDAP注入以及Expression Language(EL)注入，所有這些都極度危險，因此在發送數據到這些解釋器的時候要格外小心。

　　2. 損壞的驗證和會話管理

JavaEE支持身份驗證和會話管理，但這里有很多容易出錯的地方。你必須確保所有經過驗證流量都通過SSL，沒有例外。如果你曾經暴露JSESSIONID，那么它就可被用來在你不知情的情況下劫持用戶會話。你應該旋轉JSESSIONID，在用戶進行身份驗證以防止會話固定攻擊(Session Fixation attack)的時候。你應該避免使用response.encodeURL()，因為它會添加用戶的JSESSIONID到URL，使得更容易被披露或被盜。

　　3. 跨站點腳本攻擊(XSS)

XSS發生在當JavaEE開發人員從HTTP請求獲取不可信的信息，并把它放到HTTP響應中，而沒有適當的上下文輸出編碼的時候。攻擊者可以利用這個行為將他們的腳本注入網站，然后在這個網站上劫持會話和竊取數據。為了防止這些攻擊，開發人員需要執行敏感的上下文輸出編碼。

如果你把數據轉換成 HTML，使用&#xx;格式。請務必括號HTML屬性，因為有很多不同字符而不帶括號的屬性會被終止。如果你把不可信的數據放到JavaScript，URL或CSS中，那么對于每一個你都應該使用相應的轉義方法。并且在和嵌套上下文，如一個用Javascript寫的在 HTML 屬性中的URL打交道時，要非常小心。你可能會想要編碼庫，例如OWASP ESAPI的幫助。

　　4. 不安全的直接對象引用

任何時候應用程序暴露了一個內部標識符，例如數據庫密鑰，文件名，或hashmap索引，攻擊者就可以嘗試操縱這些標識符來訪問未經授權的數據。例如，如果你將來自于HTTP請求的不可信的數據傳遞到Java文件構造器，攻擊者就可以利用“../”或空字節攻擊來欺騙你的驗證。你應該考慮對你的數據使用間接引用，以防止這種類型的攻擊。ESAPI 庫支持促進這種間接引用的ReferenceMaps。

5. 錯誤的安全配置

現代的JavaEE應用程序和框架，例如Struts和Spring中有著大量的安全設置。確定你已經瀏覽過這些安全設置，并按你想要的那樣設置。例如，小心<security-constraint>中的<http-method>標簽。這表明安全約束僅適用于列出的方法，允許攻擊者使用其他HTTP方法，如HEAD和PUT，來繞過整個安全約束。也許你應該刪除 web.xml 中的<http-method>標簽

　　6. 敏感數據暴露

Java有大量的加密庫，但它們不容易正確使用。你應該找到一個建立在JCE基礎上的庫，并且它能夠方便、安全地提供有用的加密方法。比如Jasypt和ESAPI就是這樣的庫。你應該使用強大的算法，如AES用于加密，以及SHA256用于hashes。但是要小心密碼hashes，因為它們可以利用Rainbow Table被解密，所以要使用自適應算法，如bcrypt或PBKDF2。

　　7. 缺少功能級訪問控制

JavaEE支持聲明式和程序式的訪問控制，但很多應用程序仍然會選擇創造它們自己的方案。像Spring框架也有基于注釋的訪問控制基元。最重要的事情是要確保每一個暴露的端口都要有適當的訪問控制檢查，包括web服務。不要以為客戶端可以控制任何東西，因為攻擊者會直接訪問你的端點。

8. 跨站點偽造請求(CSRF)

每個改變狀態的端點需要驗證請求有沒有被偽造。開發人員應該在每個用戶的會話中放入隨機令牌，然后當請求到達的時候驗證它。否則，攻擊者就可以通過鏈接到未受保護的應用程序的惡意IMG，SCRIPT, FRAME或FORM標簽等創建“攻擊”頁面。當受害者瀏覽這種頁面時，瀏覽器會生成一個“偽造”的HTTP請求到URL在標簽中被指定的任何內容，并且自動包括受害人的認證信息。

　　9. 使用帶有已知漏洞的組件

現代的JavaEE應用程序有數百個庫。依賴性解析工具，如Maven，導致了這個數字在過去五年時間里出現爆炸式增長。許多廣泛使用的Java庫都有一些已知的漏洞，會讓web應用程序被完全顛覆。解決的辦法是及時更新庫。不要只運行單一掃描，因為新的漏洞每天都在發布。

10. 未經驗證的轉址和轉送

任何時候你的應用程序使用不可信的數據，例如request.getParameter()或 request.getCookie()，在調用 response.sendRedirect()時，攻擊者可以強制受害者的瀏覽器轉到一個不受信任的網站，目的在于安裝惡意軟件。forward也存在著類似的問題，不同之處在于攻擊者可以轉送他們自己到未經授權的功能，如管理頁面。一定要仔細驗證轉址和轉送目標。