JavaEE中遺漏的10個最重要的安全控制

盛夏光年lll發表於2016-04-29

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”——剩下的就交給它辦吧。

作者:小峰來源:碼農網

譯文連結:http://www.codeceo.com/article/10-security-controls-in-javaee.html

英文原文:The 10 Most Important Security Controls Missing in JavaEE

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31098481/viewspace-2090623/,如需轉載,請註明出處,否則將追究法律責任。

相關文章