JavaEE中遺漏的10個最重要的安全控制
英文原文：The 10 Most Important Security Controls Missing in 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 也存在著類似的問題，不同之處在于攻擊者可以轉送他們自己到未經授權的功能，如管理頁面。一定要仔細驗證轉址和轉送目標。
你應該持續留意這些問題。新的攻擊和漏洞總是在被發現。理想情況下，你可以集成安全檢查到現有的構建、測試和部署過程。
要在應用程序中檢查這些問題，可以嘗試免費的 Contrast for Eclipse 插件 。這不是一個簡單的靜態分析工具。相反，C4E 利用 Java 儀表化 API，來監視應用程序中與安全相關的一切。 C4E 甚至能實時地做到完整的數據流分析，因此它可以跟蹤來自于請求的數據，通過一個復雜的應用程序。例如，假設你的代碼獲取了一個參數值，用 base64 解碼它，再存儲于 map 中，把 map 放到數據 bean 中，再將 bean 存儲到一個會話屬性中，在 JSP 中獲取 bean 的值，并使用 EL 將這個值插入到網頁。Contrast for Eclipse 可以跟蹤這些數據并報告 XSS 漏洞。哪怕你正在使用的是復雜的框架和庫。沒有其他工具能在速度，精度和易用性方面與之媲美。
你可以在 Eclipse Marketplace 找到 Contrast for Eclipse。然后，只需轉到服務器選項卡“Start with Contrast”——剩下的就交給它辦吧。
來自: www.codeceo.com