OWASP Top 10 2021

發佈日期: 作者:

OWASP Top 10 是由全球知名的非營利組織「開放式網路應用安全計畫（OWASP, The Open Web Application Security Project）」所制定，旨在識別並揭露最具代表性的十大網路應用程式安全風險。

這份風險清單並非單純的統計排名，而是結合了來自全球數以萬計的實際攻擊數據、漏洞通報、專家評估與社群問卷調查，針對風險的「技術嚴重性」、「被利用的可能性」、「業界關注程度」等多面向進行權重衡量後所得出的結果。OWASP提到的弱點如下：

  • A01:2021 – 存取控制失效（Broken Access Control）
  • A02:2021 – 加密失效（Cryptographic Failures）
  • A03:2021 – 注入攻擊（Injection）
  • A04:2021 – 設計不良（Insecure Design）
  • A05:2021 – 安全設定錯誤（Security Misconfiguration）
  • A06:2021 – 使用有漏洞或過期元件（Vulnerable and Outdated Components）
  • A07:2021 – 身份驗證與管理失效（Identification and Authentication Failures）
  • A08:2021 – 軟體與資料完整性失效（Software and Data Integrity Failures）
  • A09:2021 – 安全日誌與監控失效（Security Logging and Monitoring Failures）
  • A10:2021 – 伺服器端請求偽造（Server-Side Request Forgery, SSRF）

refer：https://owasp.org/Top10

1.Broken Access Control

存取控制的核心在於確保使用者無法逾越其授權範圍執行操作。一旦控管失效，將導致未授權的資料洩漏、竄改、刪除，或讓使用者執行其權限外的業務功能。這類漏洞往往源自權限驗證邏輯不足、URL直接存取資源、未正確實作物件層級存取控制等問題。
以下為常見的存取控制漏洞類型：

案例：參數篡改（Parameter Tampering）

java程式碼：這段程式將使用者提交的 acct 參數（帳戶編號）直接帶入SQL查詢中，並沒有做任何權限驗證或檢查。

pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery();

攻擊方式： 攻擊者只需要打開瀏覽器，把網址中的 acct 參數修改成其他帳號，就能查詢到不屬於自己的帳戶資料，因為應用程式完全相信使用者傳來的帳戶編號，沒有驗證「這個使用者是否真的有權限查詢該帳號」。

https://example.com/app/accountInfo?acct=notmyacct

問題核心： 缺乏權限驗證邏輯，只根據使用者輸入的參數進行查詢，導致任意帳號查詢（Insecure Direct Object References, IDOR）。

更多案例可參考：

2.Cryptographic Failures

加密失效不再僅聚焦於「資料外洩」這種結果性問題，而是回歸檢討「資料保護需求是否正確落實」這個根本原因。針對傳輸中與靜態資料（如密碼、信用卡資訊、健康紀錄、企業機密等），必須依據GDPR、PCI DSS等法規，實施適當的加密與保護措施。弱加密、錯誤配置或憑證管理不當，均會導致加密失效的風險。

案例：Hash演算法導致密碼洩漏

某系統將使用者密碼以未加Salt的簡單雜湊（如MD5、SHA-1）方式儲存於資料庫中。由於存在檔案上傳漏洞，攻擊者成功將整個密碼雜湊資料庫下載。由於這些雜湊未經過Salt處理，攻擊者可直接使用預先計算好的「彩虹表（Rainbow Table）」進行反查，迅速破解大量使用者密碼。

即使有些密碼加上了Salt，若系統使用的是運算速度過快的雜湊演算法（如MD5或SHA-1），攻擊者仍可透過GPU進行暴力破解（Brute Force），在短時間內猜測出大量密碼。

3.Injection

當應用程式未對用戶輸入進行嚴謹的驗證、過濾或轉義，並直接將這些資料帶入動態查詢語句或命令中時，將會暴露於各類注入攻擊風險，包括SQL、NoSQL、OS指令、LDAP、EL/OGNL等。良好的參數化查詢、ORM防禦設計與輸入驗證是防範關鍵。程式碼審查（SAST）、動態測試（DAST）、互動測試（IAST）應整合至CI/CD流程，確保漏洞能於上線前被攔截。

案例：SQL 語句拼接導致注入漏洞

某應用程式在組合SQL查詢語句時，直接將來自用戶輸入的 id 參數嵌入至SQL查詢字串中，未經任何過濾或參數化處理：

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

攻擊者只需將網址中的 id 參數修改為惡意SQL語句，即可造成SQL Injection。例如：

http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--

這段payload會將原本的SQL語句修改為：

SELECT * FROM accounts WHERE custID='' UNION SELECT SLEEP(10);--

攻擊者透過注入UNION語法與SLEEP延遲指令，可以用來測試SQL注入是否成功。若應用程式將資料庫查詢結果回傳給使用者，攻擊者甚至能夠取得完整的帳戶資料或進一步執行資料修改與刪除操作。

更多案例可參考：

4.Insecure Design

「設計不良」代表的是在系統架構與業務流程設計階段即存在的安全控制缺陷。這類問題無法單純依賴完善的實作去補救，因為從一開始便缺乏針對性防禦機制。威脅建模、安全設計模式與風險導向架構設計，應成為開發早期的標準流程，以降低設計層級的資安風險。

案例：業務邏輯缺陷 — 大規模濫用群體訂票機制

某連鎖電影院針對團體訂票提供折扣優惠，並訂有15人以上需預付訂金的規範。然而，若應用程式未針對異常訂票行為進行邏輯防護，一旦攻擊者發現系統對大量訂票請求未進行限制或驗證，就可在短時間內完成600個座位的預訂，甚至將全國所有場次一併鎖定。這類攻擊會造成票房收入損失，並干擾實際消費者的購票體驗，屬於業務邏輯漏洞（Business Logic Vulnerability）的典型案例。

更多案例可參考：

5.Security Misconfiguration

安全設定錯誤涵蓋範圍極廣，包含應用程式堆疊未進行強化（Hardening）、雲端資源權限配置錯誤、不必要功能未停用、預設帳號未移除、錯誤訊息過度詳盡、伺服器與框架安全參數未正確設定、缺乏安全標頭（HTTP Security Headers）等。組織應制定標準化、可重複執行的安全配置流程，以降低因人為疏忽而產生的設定風險。

案例：過度詳盡的錯誤訊息回應 — 資訊洩漏風險

伺服器設定不當，使得應用程式在異常發生時，將詳細錯誤訊息（例如Stack Trace、伺服器端例外訊息）回傳給終端使用者。這些錯誤訊息中可能包含敏感資訊，例如框架或元件版本、資料庫連線字串、應用程式邏輯細節等，讓攻擊者能夠進一步了解系統架構與潛在漏洞，加速入侵行動。

更多案例可參考：

6.Vulnerable and Outdated Components

許多企業對所使用元件（含前端與後端）的版本與依賴關係缺乏完整掌握，導致未能即時得知哪些元件已不再維護或存在已知漏洞。定期進行元件掃描、訂閱安全公告並建立風險導向的修補與升級流程，是解決這類問題的關鍵。此外，開發階段需驗證元件升級的相容性，以避免因升級而產生額外風險。

案例：高風險漏洞導致系統入侵

應用程式所使用的第三方元件（Components），通常會以與應用程式相同的權限執行。一旦這些元件存在漏洞，無論是開發疏失（如程式錯誤）或惡意植入（如後門程式），都可能直接導致系統被完全控制，造成重大資安風險。

以 Apache Struts 2 CVE-2017-5638 為例，該漏洞為遠端程式碼執行（Remote Code Execution, RCE）漏洞，攻擊者僅需透過精心構造的HTTP請求，即可在伺服器上執行任意指令。該漏洞被歸咎為多起全球性資安事件的主要原因，顯示出元件漏洞帶來的巨大衝擊。

7.Identification and Authentication Failures

此類風險涵蓋驗證流程中的各種缺陷，如允許自動化攻擊（憑證填充、暴力破解）、使用弱密碼或預設密碼、憑證回復機制設計不當、憑證儲存不安全（明文、弱雜湊）、缺乏多因素驗證（MFA）、會話識別碼曝露於URL或重複使用等。企業應採用標準化驗證框架、實施強化的帳號安全政策，並確保會話管理與身份驗證流程具備抵禦攻擊的能力。

案例：憑證填充攻擊（Credential Stuffing）— 密碼驗證探測器

憑證填充（Credential Stuffing）是攻擊者利用已洩漏的帳號密碼清單，對其他網站或應用程式進行自動化登入嘗試的常見攻擊手法。若應用程式未實作自動化威脅防護（如 CAPTCHA、人機驗證）或憑證填充防禦機制，攻擊者即可透過大量帳號密碼組合進行驗證，並將應用程式作為「密碼探測器（Password Oracle）」來判斷帳密是否有效，進而造成大規模帳號入侵事件。

更多案例可參考：

8.Software and Data Integrity Failures

當應用程式仰賴來自不受信任來源（如第三方套件庫、CDN）的元件、外掛或模組，卻未進行完整性驗證時，即暴露於完整性失效風險。同樣，CI/CD流程中若缺乏權限控管與簽章驗證，也可能導致惡意程式被引入至正式環境。自動更新機制若無完整性驗證，也可能成為攻擊者的散播途徑。不安全的反序列化（Insecure Deserialization）亦屬於此類範疇。

案例1：未驗證簽章的更新機制（Unsigned Firmware Updates）

許多家用路由器、機上盒、物聯網設備等產品，韌體更新時並未進行簽章驗證（Firmware Signing Verification）。這類設備缺乏數位簽章檢查機制，使攻擊者能輕易將惡意韌體（Malicious Firmware）植入設備中，造成後門、資料竊取或遠端控制的風險。更嚴重的是，許多設備並沒有針對韌體完整性的即時修補機制，僅能透過發布新版韌體進行修正，導致先前版本在市場上長期處於無法有效修補的高風險狀態。

案例2：SolarWinds 惡意更新事件 — 供應鏈攻擊經典案例

供應鏈攻擊（Supply Chain Attack）並非新興手法，但 SolarWinds Orion 惡意更新事件堪稱史上最具破壞力的攻擊之一。攻擊者鎖定 SolarWinds 這家知名 IT 管理軟體廠商，成功滲透其安全的軟體建置與更新發佈流程，將精心打造的惡意程式碼植入更新檔案中。該惡意更新被超過 18,000 家組織 安裝，雖然實際受害的約有 100 家左右，但影響層面涵蓋政府機關、國防產業與大型企業，顯示即使是具備完整更新驗證機制的廠商，仍可能遭受供應鏈攻擊所帶來的災難性後果。

案例3：不安全反序列化（Insecure Deserialization）導致遠端程式碼執行

某應用系統採用 React 前端搭配 Spring Boot 微服務架構。為了維持應用狀態的「不可變性（Immutability）」，開發團隊選擇將使用者狀態物件進行序列化（Serialization），並於每次請求時傳遞於前後端之間。攻擊者在分析請求時，發現參數中包含 “rO0” 這類 Java 物件序列化特徵（Base64編碼）。利用已知工具 Java Serial Killer，攻擊者成功將惡意 Payload 反序列化至伺服器記憶體中，進而執行任意指令（Remote Code Execution, RCE），取得伺服器控制權限。

更多案例可參考：

9.Security Logging and Monitoring Failures

若無法即時監測與記錄關鍵事件（如登入、異常交易、錯誤警告），將使組織無法有效偵測與應對入侵行動。常見問題包括未記錄重要事件、日誌紀錄不完整或過於模糊、缺乏異常行為監測機制、日誌僅儲存於本地、無有效告警與應變程序等。企業應將日誌與監控納入安全架構核心，並確保滲透測試與DAST掃描能觸發相應告警。

案例：缺乏監控與日誌記錄導致長期未偵測的資料外洩事件

某兒童健康保險網站因未實施有效的監控與日誌記錄機制，導致資安事件長期未被發現。該事件最終是由第三方外部通報才得知，攻擊者已成功入侵並竄改了超過 350 萬名兒童的敏感健康資料。事件後的資安調查顯示，網站開發團隊未針對關鍵性漏洞進行修補，系統更未有日誌記錄或異常行為監測，推測資料外洩可能已從 2013 年持續進行超過七年，才終於被揭露。

10.Server-Side Request Forgery(SSRF)

當應用程式允許使用者指定URL並由伺服器端發起請求，卻未對該URL進行嚴格驗證與過濾時，便可能被攻擊者利用進行SSRF攻擊。攻擊者可藉此繞過防火牆或內部網路ACL，對內部資源進行掃描、存取雲端元數據服務，甚至觸發後續複合式攻擊。隨著雲端架構與微服務的普及，SSRF的嚴重性與影響層級亦日益提升。

案例：對內部伺服器進行 Port Scanning

若企業內部網路架構未進行有效區隔，攻擊者可利用 SSRF 進行橫向移動，發送針對內部伺服器的連線請求，以確認特定 Port 是否開啟或封鎖。攻擊者可透過連線結果或請求回應時間的差異，進一步描繪出內部網路拓撲圖，達到內網偵察（Internal Reconnaissance）的目的。

更多案例可參考：