OWASP TOP 10

OWASP Open Web Application Security Project

官網： https://www.owasp.org/index.p...
下載： https://www.owasp.org/index.p...:OWASP_Top_Ten_Project#tab=Main

OWASP（開放式Web應用程序安全項目）是一個501c3非盈利的全球性安全組織，致力於應用軟件的安全研究。使命是使應用軟件更加安全，使企業和組織可以對應用安全風險作出更清晰的決策。

1. 注入 Injection

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

產生緣由：

• 用戶提供的數據沒有通過應用程序的驗證、過濾或淨化。
• 動態查詢語句或非參數化的調用，在沒有上下文感知轉義的狀況下，被用於解釋器。
• 在ORM搜索參數中使用了惡意數據，這樣搜索就得到包含敏感或未受權的數據。
• 惡意數據直接被使用或鏈接，諸如SQL語句或命令在動態查詢語句、命令或存儲過程當中包含結構和惡意數據。

常見的注入：SQL、OS命令、ORM、LDAP和表達式語言（EL）或OGNL注入；
其餘：全部參數、字段、頭、cookie、JSON和XML數據輸入

防護方法：

• 最佳選擇是使用安全的API接口，徹底避免使用解釋器，或提供參數化界面的接口，或遷移到ORM或實體框架。
• 使用正確的或「白名單」的具備恰當規範化的輸入驗證方法一樣會有助於防止注入攻擊，但這不是一個完整的防護，由於許多應用程序在輸入中須要特殊字符，例如文本區域或移動應用程序的API。
• 對於任何剩餘的動態查詢，可使用該解釋器的特定轉義語法轉義特殊字符。OWASP的Java Encoder和相似的庫提供了這樣的轉義例程。
• 在查詢中使用LIMIT和其餘SQL控件，以防止在SQL注入時大量地泄露記錄。

2. 失效的身份認證 Broken Authentication

一般，經過錯誤使用應用程序的身份認證和會話管理功能，攻擊者可以破譯密碼、密鑰或會話令牌，或者利用其它開發缺陷來暫時性或永久性冒充其餘用戶的身份。

產生緣由：

• 容許憑證填充，這使得攻擊者得到有效用戶名和密碼的列表。
• 容許暴力破解或其餘自動攻擊。
• 容許默認的、弱的或衆所周知的密碼，例如「Password1」或「admin/admin」。
• 使用弱的或失效的驗證憑證，忘記密碼程序，例如「基於知識的答案」，這是不安全的。
• 使用明文、加密或弱散列密碼。
• 缺乏或失效的多因素身份驗證。
• 暴露URL中的會話ID（例如URL重寫）。
• 在成功登陸後不會更新會話ID。
• 不正確地使會話ID失效。當用戶不活躍的時候，用戶會話或認證令牌（特別是單點登陸（SSO）令牌）沒有正確註銷或失效。

防護方法：

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

3. 敏感數據泄露 Sensitive Data Exposure

許多Web應用程序和API都沒法正確保護敏感數據，例如：財務數據、醫療數據和PII數據。攻擊者能夠經過竊取或修改未加密的數據來實施信用卡詐騙、身份盜竊或其餘犯罪行爲。未加密的敏感數據容易受到破壞，所以，咱們須要對敏感數據加密，這些數據包括：傳輸過程當中的數據、存儲的數據以及瀏覽器的交互數據。

產生緣由：

• 在數據傳輸過程當中是否使用明文傳輸？這和傳輸協議相關，如：HTTP、SMTP和FTP。外部網絡流量很是危險。驗證全部的內部通訊，如：負載平衡器、Web服務器或後端系統之間的通訊
• 當數據被長期存儲時，不管存儲在哪裏，它們是否都被加密，包含備份數據？
• 不管默認條件仍是源代碼中，是否還在使用任何舊的或脆弱的加密算法？
• 是否使用默認加密密鑰，生成或重複使用脆弱的加密密鑰，或者缺乏恰當的密鑰管理或密鑰迴轉？
• 是否強制加密敏感數據，例如：用戶代理（如：瀏覽器）指令和傳輸協議是否被加密？
• 用戶代理（如：應用程序、郵件客戶端）是否未驗證服務器端證書的有效性？

防護方法：

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

4. XML外部實體 XML External Entities (XXE)

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

產生緣由：

• 應用程序直接接受XML文件或者接受XML文件上傳，特別是來自不受信任源的文件，或者將不受信任的數據插入XML文件，並提交給XML處理器解析。
• 在應用程序或基於Web服務的SOAP中，全部XML處理器都啓用了文檔類型定義（DTDs）。由於禁用DTD進程的確切機制因處理器而不一樣。
• 若是爲了實現安全性或單點登陸（SSO），您的應用程序使用SAML進行身份認證。而SAML使用XML進行身份確認，那麼您的應用程序就容易受到XXE攻擊。
• 若是您的應用程序使用第1.2版以前的SOAP，並將XML實體傳遞到SOAP框架，那麼它可能受到XXE攻擊。
• 存在XXE缺陷的應用程序更容易受到拒絕服務攻擊，包括：Billion Laughs 攻擊。

防護方法：

• 儘量使用簡單的數據格式（如：JSON），避免對敏感數據進行序列化。
• 及時修復或更新應用程序或底層操做系統使用的全部XML處理器和庫。同時，經過依賴項檢測，將SOAP更新到1.2版本或更高版本。
• 參考《OWASP Cheat Sheet 'XXE Prevention'》，在應用程序的全部XML解析器中禁用XML外部實體和DTD進程。
• 在服務器端實施積極的（「白名單」）輸入驗證、過濾和清理，.以防止在XML文檔、標題或節點中出現惡意數據.
• 驗證XML或XSL文件上傳功能是否使用XSD驗證或其餘相似驗證方法來驗證上傳的XML文件。
• 儘管在許多集成環境中，手動代碼審查是大型、複雜應用程序的最佳選擇，可是SAST 工具能夠檢測源代碼中的XXE漏洞。

5. 失效的訪問控制 Broken Access Control

未對經過身份驗證的用戶實施恰當的訪問控制。攻擊者能夠利用這些缺陷訪問未經受權的功能或數據，例如：訪問其餘用戶的賬戶、查看敏感文件、修改其餘用戶的數據、更改訪問權限等。

產生緣由：

• 經過修改 URL、內部應用程序狀態或 HTML 頁面繞過訪問控制檢查，或簡單地使用自定義的 API 攻擊工具。
• 容許將主鍵更改成其餘用戶的記錄，例如查看或編輯他人的賬戶。
• 特權提高。在不登陸的狀況下假扮用戶，或以用戶身份登陸時充當管理員。
• 元數據操做，如重放或篡改 JWT 訪問控制令牌，或做以提高權限的cookie 或隱藏字段。
• CORS配置錯誤容許未受權的API訪問。
• 以未經過身份驗證的用戶身份強制瀏覽的經過身份驗證時才能看到的頁面、或做爲標準用戶訪問具備相關權限的頁面、或API沒有對POST、PUT和DELETE強制執行訪問控制。

防護方法：

• 除公有資源外，默認狀況下拒絕訪問。
• 使用一次性的訪問控制機制，並在整個應用程序中不斷重用它們，包括最小化CORS使用。
• 創建訪問控制模型以強制執行全部權記錄，而不是接受用戶建立、讀取、更新或刪除的任何記錄。
• 域訪問控制對每一個應用程序都是惟一的，但業務限制要求應由域模型強制執行。
• 禁用 Web服務器目錄列表，並確保文件元數據（如：git）不存在於 Web的根目錄中。
• 記錄失敗的訪問控制，並在適當時向管理員告警（如：重複故障）。
• 對API和控制器的訪問進行速率限制，以最大限度地下降自動化攻擊工具的危害。
• 當用戶註銷後，服務器上的JWT令牌應失效。

6. 安全配置錯誤 Security Misconfiguration

安全配置錯誤是最多見的安全問題，這一般是因爲不安全的默認配置、不完整的臨時配置、開源雲存儲、錯誤的 HTTP 標頭配置以及包含敏感信息的詳細錯誤信息所形成的。所以，咱們不只須要對全部的操做系統、框架、庫和應用程序進行安全配置，並且必須及時修補和升級它們。

產生緣由：

• 應用程序棧堆的任何部分都缺乏適當的安全加固，或者雲服務的權限配置錯誤。
• 應用程序啓用或安裝了沒必要要的功能（例如：沒必要要的端口、服務、網頁、賬戶或權限）。
• 默認賬戶的密碼仍然可用且沒有更改。
• 錯誤處理機制向用戶披露堆棧跟蹤或其餘大量錯誤信息。
• 對於更新的系統，禁用或不安全地配置最新的安全功能。
• 應用程序服務器、應用程序框架（如：Struts、Spring、ASP.NET）、庫文件、數據庫等沒有進行安全配置。
• 服務器不發送安全標頭或指令，或者未對服務器進行安全配置。
• 您的應用軟件已過時或易受攻擊（參見：使用含有已知漏洞的組件）。

防護方法：

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

7. 跨站腳本 Cross-Site Scripting (XSS)

當應用程序的新網頁中包含不受信任的、未經恰當驗證或轉義的數據時，或者使用能夠建立 HTML或JavaScript 的瀏覽器 API 更新現有的網頁時，就會出現 XSS 缺陷。XSS 讓攻擊者可以在受害者的瀏覽器中執行腳本，並劫持用戶會話、破壞網站或將用戶重定向到惡意站點。

產生緣由：

• 反射型 Reflected XSS：應用程序或API包括未經驗證和未經轉義的用戶輸入，做爲HTML輸出的一部分。一個成功的攻擊可讓攻擊者在受害者的瀏覽器中執行任意的HTML和JavaScript。 一般，用戶將須要與指向攻擊者控制頁面的某些惡意連接進行交互，例如惡意漏洞網站，廣告或相似內容。
• 存儲型 Stored XSS：你的應用或者API將未淨化的用戶輸入存儲下來了，並在後期在其餘用戶或者管理員的頁面展現出來。 存儲型XSS通常被認爲是高危或嚴重的風險。
• DOM型 DOM XSS：會動態的將攻擊者可控的內容加入頁面的JavaScript框架、單頁面程序或API存在這種類型的漏洞。理想的來講，你應該避免將攻擊者可控的數據發送給不安全的JavaScript API。

典型的XSS攻擊可致使盜取session、帳戶、繞過MFA、DIV替換、對用戶瀏覽器的攻擊（例如：惡意軟件下載、鍵盤記錄）以及其餘用戶側的攻擊。

防護方法：

• 使用設計上就會自動編碼來解決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的深度防護策略。若是不存在能夠經過本地文件放置惡意代碼的其餘漏洞（例如：路徑遍歷覆蓋和容許在網絡中傳輸的易受攻擊的庫），則該策略是有效的。

8. 不安全的反序列化 Insecure Deserialization

不安全的反序列化會致使遠程代碼執行。即便反序列化缺陷不會致使遠程代碼執行，攻擊者也能夠利用它們來執行攻擊，包括：重播攻擊、注入攻擊和特權升級攻擊。

產生緣由：

這可能致使兩種主要類型的攻擊：

• 若是應用中存在能夠在反序列化過程當中或者以後被改變行爲的類，則攻擊者能夠經過改變應用邏輯或者實現遠程代碼執行攻擊。咱們將其稱爲對象和數據結構攻擊。
• 典型的數據篡改攻擊，如訪問控制相關的攻擊，其中使用了現有的數據結構，但內容發生了變化。

在應用程序中，序列化可能被用於:

• 遠程和進程間通訊（RPC / IPC）
• 連線協議、Web服務、消息代理
• 緩存/持久性
• 數據庫、緩存服務器、文件系統
• HTTP cookie、HTML表單參數、API身份驗證令牌

防護方法：
惟一安全的架構模式是不接受來自不受信源的序列化對象，或使用只容許原始數據類型的序列化媒體。

若是上述不可能的話，考慮使用下述方法：

• 執行完整性檢查，如：任何序列化對象的數字簽名，以防止惡意對象建立或數據篡改。
• 在建立對象以前強制執行嚴格的類型約束，由於代碼一般被指望成一組可定義的類。繞過這種技術的方法已經被證實，因此徹底依賴於它是不可取的。
• 若是可能，隔離運行那些在低特權環境中反序列化的代碼。
• 記錄反序列化的例外狀況和失敗信息，如：傳入的類型不是預期的類型，或者反序列處理引起的例外狀況。
• 限制或監視來自於容器或服務器傳入和傳出的反序列化網絡鏈接。
• 監控反序列化，當用戶持續進行反序列化時，對用戶進行警告。

9. 使用含有已知漏洞的組件 Using Components with KnownVulnerabilities

組件（例如：庫、框架和其餘軟件模塊）擁有和應用程序相同的權限。若是應用程序中含有已知漏洞的組件被攻擊者利用，可能會形成嚴重的數據丟失或服務器接管。同時，使用含有已知漏洞的組件的應用程序和API可能會破壞應用程序防護、形成各類攻擊併產生嚴重影響。

產生緣由：

• 若是你不知道全部使用的組件版本信息（包括：服務端和客戶端）。這包括了直接使用的組件或其依賴的組件。
• 若是軟件易受攻擊，再也不支持或者過期。這包括：OS、Web服務器、應用程序服務器、數據庫管理系統（DBMS）、應用程序、API和全部的組件、運行環境和庫。
• 若是你不會按期作漏洞掃描和訂閱你使用組件的安全公告。
• 若是你不基於風險並及時修復或升級底層平臺、框架和依賴庫。極可能發生這種狀況：根據變動控制，每個月或每季度進行升級，這使得組織在這段時間內會受到已修復但未修補的漏洞的威脅。
• 若是軟件工程師沒有對更新的、升級的或打過補丁的組件進行兼容性測試。
• 若是你沒有對組件進行安全配置（請參考：安全配置錯誤）。

防護方法：

• 移除不使用的依賴、不須要的功能、組件、文件和文檔。
• 利用如versions、DependencyCheck、retire.js等工具來持續的記錄客戶端和服務器端以及它們的依賴庫的版本信息。持續監控如 CVE 和 NVD 等是否發佈已使用組件的漏洞信息，可使用軟件分析工具來自動完成此功能。訂閱關於使用組件安全漏洞的警告郵件。
• 僅從官方渠道安全的獲取組件，並使用簽名機制來下降組件被篡改或加入惡意漏洞的風險。
• 監控那些再也不維護或者不發佈安全補丁的庫和組件。若是不能打補丁，能夠考慮部署虛擬補丁來監控、檢測或保護。

10. 不足的日誌記錄和監控 Insufficient Logging & Monitoring

不足的日誌記錄和監控，以及事件響應缺失或無效的集成，使攻擊者可以進一步攻擊系統、保持持續性或轉向更多系統，以及篡改、提取或銷燬數據。大多數缺陷研究顯示，缺陷被檢測出的時間超過200天，且一般經過外部檢測方檢測，而不是經過內部流程或監控檢測

產生緣由：

• 未記錄可審計性事件，如：登陸、登陸失敗和高額交易。
• 告警和錯誤事件未能產生或產生不足的和不清晰的日誌信息。
• 沒有利用應用系統和API的日誌信息來監控可疑活動。
• 日誌信息僅在本地存儲。
• 沒有定義合理的告警閾值和制定響應處理流程。
• 滲透測試和使用DAST工具（如：OWASP ZAP）掃描沒有觸發告警。
• 對於實時或準實時的攻擊，應用程序沒法檢測、處理和告警。

防護方法：

• 確保全部登陸、訪問控制失敗、輸入驗證失敗可以被記錄到日誌中去，並保留足夠的用戶上下文信息，以識別可疑或惡意賬戶，併爲後期取證預留足夠時間。
• 確保日誌以一種能被集中日誌管理解決方案使用的形式生成。
• 確保高額交易有完整性控制的審計信息，以防止篡改或刪除，例如審計信息保存在只能進行記錄增長的數據庫表中。
• 創建有效的監控和告警機制，使可疑活動在可接受的時間內被發現和應對。
• 創建或採起一個應急響應機制和恢復計劃，例如：NIST 800-61 rev 2 或更新版本。

TOP 10 風險因素總結

其它值得關注的漏洞

• CWE-352: 跨站點請求僞造（CSRF）
• CWE-400: 不受控制的資源消耗 （「資源枯竭」、「App拒絕服務」 ）
• CWE-434: 無限制上傳危險類型文件
• CWE-451: 用戶界面（UI）對關鍵信息的誤傳（點擊劫持和其餘）
• CWE-601: 未經驗證的轉發和重定向
• CWE-799: 交互頻率控制不當（反自動化）
• CWE-829:不可信控制域包含功能性（第三方內容）
• CWE-918: 服務器端請求僞造（SSRF）

本文摘自官網文檔，詳情可到官網查看。