OWASP (開放式Web應用程序安全項目) Top 10 榜單是全球公認的、針對Web應用最關鍵安全風險的權威指南。它不是一份詳盡無遺的清單,而是一份凝聚了安全專家共識的“高危預警”。
本文將不止于羅列這些風險,而是深入每個風險的核心,通過生動的比喻、真實的攻擊場景和攻擊者視角,幫助開發者、測試人員和運維工程師理解漏洞的本質。最重要的是,我們為每一項風險都提供了具體的防御和緩解措施,助您構建更堅固的數字堡壘。
A01:2021 - 訪問控制失效
核心問題
“系統沒分清你是誰,就讓你做了不該做的事。”
風險解讀
訪問控制旨在強制執行策略,使用戶無法在其預期權限之外執行操作。訪問控制失效就是指這些限制沒有得到正確實施。攻擊者可以利用這些缺陷,訪問未經授權的功能或數據,例如訪問其他用戶的帳戶、查看敏感文件、修改其他用戶的數據、更改訪問權限等。
常見利用場景
ID遍歷與數據爬取 (IDOR):?攻擊者編寫腳本循環請求?/api/orders/1001,?/1002...,如果系統沒有驗證ID歸屬,就能輕松爬取所有用戶的數據。
權限提升:?普通用戶嘗試直接訪問管理員URL如?/admin/dashboard,如果后端接口沒檢查角色,瞬間“變身”為管理員。
越權修改/刪除:?攻擊者抓取修改自己公司信息的API請求,把其中的公司ID改成競爭對手的,從而篡改對手數據。
CORS配置錯誤:?錯誤的CORS策略允許惡意網站讀取私有API的響應,繞過了同源策略。
防御與緩解措施
默認拒絕原則:?除了公共資源外,默認情況下應拒絕所有訪問,然后根據角色和權限逐一授權。
強制執行權限檢查:?在每個服務端功能點,都必須基于用戶的會話和角色,強制執行訪問控制檢查,切勿信任來自客戶端的任何權限聲明。
數據歸屬權驗證:?在操作任何數據記錄時(如查看、修改、刪除),必須驗證當前用戶是否是該記錄的所有者。
集中化訪問控制邏輯:?將訪問控制邏輯統一管理,避免在代碼各處分散實現,便于審計和維護。
關閉目錄列表:?防止攻擊者直接瀏覽服務器上的文件目錄。
攻擊者視角
“你前門關得再好,只要后門(API)不認人,我就能直接進去拿東西。”
A02:2021 - 加密機制失效
核心問題
“你的秘密寫在了明信片上,而不是鎖在保險箱里。”
風險解讀
此風險涵蓋了與加密技術相關的所有失敗,無論是傳輸中的數據(in-transit)還是靜態數據(at-rest)。這可能包括使用弱加密算法、未加密敏感數據、錯誤的密鑰管理或使用過時的協議。根本原因通常是對敏感數據的保護不足。
常見利用場景
拖庫與撞庫:?拖庫后發現密碼是明文或MD5/SHA1等弱哈希,立即獲得真實密碼,然后用這些密碼去嘗試登錄其他高價值網站(撞庫)。
中間人攻擊:?在公共Wi-Fi下,如果網站登錄頁或API是HTTP,攻擊者可直接監聽并竊取賬號密碼、Cookie等敏感信息。
硬編碼密鑰:?通過反編譯App或分析JS文件,找到硬編碼的API密鑰、加密密鑰,從而偽造請求或解密本地存儲的敏感數據。
URL參數泄露:?將Session ID、API Key等敏感信息直接放在URL中,容易被瀏覽器歷史、網絡日志、Referer頭記錄和泄露。
防御與緩解措施
全站強制HTTPS:?使用TLS(最新版本)加密所有傳輸中的數據,并配置HSTS(HTTP嚴格傳輸安全)頭,強制瀏覽器使用HTTPS。
強哈希算法存儲密碼:?使用Bcrypt、Scrypt或Argon2等現代的、加鹽的、慢速的哈希算法來存儲密碼和憑證。
按需加密靜態數據:?識別應用處理的所有敏感數據(如PII、支付信息),并對它們進行加密存儲。
安全的密鑰管理:?切勿硬編碼密鑰。使用安全的密鑰管理系統(如AWS KMS, HashiCorp Vault)來存儲和輪換密鑰。
禁用弱算法和協議:?在服務器配置中明確禁用過時的SSL/TLS版本和弱加密套件。
攻擊者視角
“拿到你的數據只是第一步,能讀懂它才是勝利。謝謝你沒給我增加難度。”
A03:2021 - 注入
核心問題
“你本想讓我查個名字,我卻讓你執行了我的命令。”
風險解讀
注入漏洞允許攻擊者將惡意數據作為命令或查詢的一部分發送到解釋器。當應用程序將不受信任的輸入與命令或查詢拼接在一起時,就會發生這種情況。攻擊者的惡意數據可以欺騙解釋器,執行非預期的命令或訪問未經授權的數據。最常見的包括SQL注入、NoSQL注入、OS命令注入、LDAP注入等。
常見利用場景
SQL注入登錄繞過:?在用戶名輸入?' OR '1'='1' --,讓SQL查詢永遠為真,無需密碼直接登錄管理員賬戶。
SQL注入數據竊取:?通過構造復雜的UNION SELECT語句,讓搜索結果附帶返回數據庫中其他表的敏感數據,如用戶表。
命令注入獲取Shell:?在Ping或文件轉換等功能中輸入?8.8.8.8; nc -lvp 4444 -e /bin/bash,讓服務器執行反向連接命令,從而遠程控制服務器。
跨站腳本(XSS):?注入<script>alert('xss')</script>到評論區,導致其他用戶訪問頁面時執行惡意腳本。雖然XSS在2021版中被歸類到注入,但其影響和防御方式通常被獨立討論。
防御與緩解措施
使用安全的API:?首選使用提供參數化接口的API,如預編譯語句(Prepared Statements)或參數化查詢(Parameterized Queries)。這是防御SQL注入最有效的方法。
服務端輸入驗證:?對所有輸入數據進行驗證,實施白名單策略,只接受已知的、合法的字符和格式。
上下文輸出編碼/轉義:?當必須將用戶輸入插入到HTML、SQL、OS命令中時,根據其上下文進行嚴格的編碼或轉義。
最小權限原則:?確保數據庫用戶只擁有其完成任務所必需的最小權限,避免使用root或sa賬戶。
攻擊者視角
“你程序的每個輸入框,對我來說都是一個可能的話筒,可以讓我直接對你的后端發號施令。”
A04:2021 - 不安全設計
核心問題
“你的代碼寫得沒錯,但你的邏輯本身就是個笑話。”
風險解讀
這是一個關注“設計缺陷”而非“實現錯誤”的類別。它強調安全需要從一開始就融入到軟件開發生命周期中(“安全左移”)。不安全的設計無法通過完美的實現來修復,它要求在設計階段就進行威脅建模,識別并規避業務邏輯上的漏洞。
常見利用場景
業務邏輯漏洞套利:?利用可無限次使用的優惠券、無上限的推薦獎勵,或商品加入購物車后價格鎖定等邏輯,編寫腳本自動化“薅羊毛”。
密碼重置邏輯缺陷:?利用“忘記密碼”功能對任意用戶進行短信轟炸;或利用永不失效、可預測的重置鏈接反復修改他人密碼。
無限次嘗試:?對沒有嘗試次數限制的登錄接口、兌換碼接口、支付接口進行“暴力破解”,直到成功。
缺乏流程順序校驗:?允許用戶跳過支付步驟直接訪問購買成功頁面,或跳過驗證步驟直接修改個人資料。
防御與緩解措施
進行威脅建模:?在設計階段,分析系統的資產、威脅、入口點和潛在攻擊場景,并設計相應的控制措施。
使用安全設計模式:?采用經過驗證的安全設計模式來構建訪問控制、身份驗證、工作流等關鍵模塊。
限制業務邏輯流:?對關鍵業務流程(如注冊、購買、重置密碼)實施嚴格的速率限制、順序校驗和資源消耗限制。
分離信任邊界:?明確系統內外的信任邊界,并對跨越邊界的數據和調用進行嚴格審查。
攻擊者視角
“我不需要攻擊你的代碼,我只需要利用你規則里的漏洞,就能讓你按我的劇本走。”
A05:2021 - 安全配置錯誤
核心問題
“你的房子蓋得很結實,但你忘了鎖門,還把調試后臺的地址貼在了門上。”
風險解讀
安全配置錯誤是目前最常見的安全問題。它源于不安全的默認配置、不完整的臨時配置、開放的云存儲、錯誤的HTTP頭配置,以及包含敏感信息的詳細錯誤信息。這不僅限于應用服務器,還包括平臺、Web服務器、數據庫、框架和任何其他軟件組件。
常見利用場景
默認口令入侵:?使用自動化工具掃描互聯網,用廣為人知的默認密碼(如admin/admin,?root/password)嘗試登錄數據庫、管理后臺、路由器等。
暴露的云存儲:?通過搜索引擎或專用工具發現配置為“公共讀取/寫入”的AWS S3存儲桶或Azure Blob,直接下載或上傳所有公司文檔和用戶數據。
泄露信息的錯誤頁面:?故意觸發程序錯誤,從返回的詳細堆棧跟蹤(Stack Trace)頁面中獲取服務器的操作系統、框架版本、內部文件路徑等詳細“地圖”。
未移除的調試功能:?生產環境中遺留了/debug、/status等調試頁面,暴露了系統內部狀態。
防御與緩解措施
建立安全基線:?為所有部署環境(開發、測試、生產)建立可重復、自動化的安全強化流程,確保配置一致。
最小化平臺:?移除或不安裝不必要的功能、組件、文檔和示例應用。
審查和加固配置:?定期審查云服務、服務器、框架和庫的配置,禁用不安全的默認設置,并應用最新的安全最佳實踐。
自定義錯誤頁面:?配置Web服務器和應用框架,以顯示統一的、不包含敏感信息的錯誤頁面。
自動化掃描:?使用自動化工具定期掃描系統,檢查是否存在配置錯誤。
攻擊者視角
“我最喜歡的就是懶惰的管理員。他們留下的默認設置,就是給我留的后門。”
A06:2021 - 使用含已知漏洞的組件
核心問題
“你信任了你的隊友(第三方庫),但你的隊友卻是個身中劇毒的‘內鬼’。”
風險解讀
現代應用嚴重依賴各種開源或商業的第三方組件、庫和框架。如果這些組件存在已知的安全漏洞,而你的應用又恰好使用了它們,那么你的應用就繼承了這些風險。攻擊者會主動掃描使用這些脆弱組件的系統,并發動已知的攻擊。
常見利用場景
大規模自動化利用(如Log4Shell):?向所有網站的請求頭中插入惡意JNDI查找字符串,一旦服務器使用了有漏洞的Log4j版本,攻擊者就能立即獲得其控制權。
利用過時框架漏洞:?專門尋找仍在使用老舊版本Apache Struts2、Fastjson、ThinkPHP的網站,用網上公開的漏洞利用工具(PoC/Exploit)進行一鍵式攻擊。
前端庫漏洞(XSS):?構造惡意URL,利用網站使用的舊版jQuery或AngularJS插件中的DOM-XSS漏洞,在受害者瀏覽器上執行腳本,竊取Cookie。
防御與緩解措施
建立軟件物料清單(SBOM):?清楚地知道你的應用使用了哪些組件,包括它們的版本和依賴關系。
定期漏洞掃描:?使用軟件成分分析(SCA)工具(如OWASP Dependency-Check, Snyk, Dependabot)自動掃描項目中的組件,及時發現已知漏洞。
及時更新和打補丁:?建立一個流程,用于監控安全公告,并在廠商發布安全補丁后,盡快測試和應用更新。
移除未使用組件:?定期清理項目中不再使用的依賴項、文件和功能,減少攻擊面。
虛擬補丁:?如果無法立即升級組件,可以考慮使用Web應用防火墻(WAF)等工具創建規則,臨時阻止對已知漏洞的利用。
攻擊者視角
“我不需要成為第一個發現漏洞的人,我只需要比你更勤快地關注安全新聞,然后利用你沒來得及修復的漏洞就行了。”
A07:2021 - 身份識別和身份驗證失敗
核心問題
“證明‘你是你’的過程太草率了。”
風險解讀
當與用戶身份驗證和會話管理相關的功能沒有被正確實現時,就會出現此問題。這可能允許攻擊者竊取密碼、密鑰或會話令牌,或者利用其他實現缺陷來冒充其他用戶的身份。
常見利用場景
會話固定(Session Fixation):?攻擊者將自己的會話ID通過鏈接發給受害者,受害者用這個ID登錄后,攻擊者手里的舊會話ID就“升級”為已登錄的會話。
JWT令牌配置不當:?使用算法為none的JWT,或使用永不失效、超長有效期的令牌,導致在用戶修改密碼甚至禁用賬戶后,舊令牌依然可以訪問系統。
弱密碼策略和暴力破解:?用一個包含Top 10000弱密碼的字典對允許設置弱密碼(如“123456”)的網站進行自動化嘗試,輕松破解大量賬戶。
憑證填充(Credential Stuffing):?利用從其他網站泄露的用戶名密碼對,批量嘗試登錄你的網站,成功率很高。
防御與緩解措施
強制多因素身份驗證(MFA):?為所有用戶,特別是高權限用戶,提供并強制啟用MFA。
實施強密碼策略:?要求密碼滿足一定的長度和復雜度,并使用密碼強度計進行檢查。禁止使用常見弱密碼。
防范暴力破解和憑證填充:?對登錄、密碼重置等關鍵操作實施速率限制和賬戶鎖定策略。
安全的會話管理:?用戶登錄后立即生成新的、高隨機性的會話ID。使用安全的Cookie屬性(Secure,?HttpOnly,?SameSite=Strict)。為會話設置合理的超時時間。
安全的密碼恢復機制:?確保密碼重置鏈接是單次有效、有時效性且不可預測的。
攻擊者視角
“只要你的‘門票’(會話ID)容易偽造或竊取,或者你的‘密碼鎖’一猜就開,我就能大搖大擺地冒充任何人。”
A08:2021 - 軟件和數據完整性故障
核心問題
“你收到的東西在半路上被掉了包,而你卻毫不懷疑地接受了它。”
風險解讀
這類故障涉及代碼和基礎設施,但未能防止完整性違規。一個典型的例子是,應用程序依賴于來自不受信任來源、存儲庫和內容分發網絡(CDN)的插件、庫或模塊。不安全的反序列化也屬于此類,它指的是應用程序在沒有驗證其完整性的情況下,接受并處理了可能被篡改的序列化對象。
常見利用場景
不安全的反序列化:?應用程序接收一個序列化的Java對象,攻擊者構造一段包含“執行系統命令”的惡意序列化數據(稱為“gadget chain”),當服務器反序列化時觸發該指令,導致遠程代碼執行(RCE)。
供應鏈攻擊:?入侵流行的NPM包或Python庫的維護者賬戶,在代碼中植入惡意后門并發布新版本。所有配置了自動更新的項目在構建時都會被感染。
未驗證的軟件更新:?應用程序的自動更新功能從一個HTTP URL下載更新包,攻擊者通過中間人攻擊,將合法的更新包替換成植入后門的惡意包,在設備更新時獲得其控制權。
防御與緩解措施
驗證軟件完整性:?在從任何來源(包括官方倉庫)獲取依賴庫、框架或軟件時,都應使用其數字簽名或哈希值進行完整性校驗。
保護CI/CD管道:?確保你的構建和部署流程是安全的,防止未經授權的代碼修改被注入到最終產品中。
避免不安全的反序列化:?盡可能避免使用需要反序列化的數據格式。如果必須使用,應實施嚴格的類型約束,并對反序列化過程進行完整性檢查,或使用數字簽名保護序列化對象的完整性。
使用可信賴的軟件源:?配置包管理器只從已知的、可信的內部或官方倉庫下載組件。
攻擊者視角
“攻擊你的服務器太難了,不如直接攻擊你信任的、防備更松懈的‘供應商’(第三方庫)。”
A09:2021 - 安全日志和監控失敗
核心問題
“我進來偷東西、踩點、甚至放了火,但你的監控是壞的,所以你一無所知。”
風險解讀
缺乏充分的日志記錄、監控和有效的告警機制,會嚴重阻礙對安全事件的檢測、響應和取證。沒有日志,攻擊活動可能無法被發現;即使發現了,也無法確定攻擊的范圍、路徑和根本原因,使得修復和追責變得異常困難。
常見利用場景
長時間潛伏(APT):?由于缺乏對異常行為的監控,攻擊者可以花幾個月時間在系統內悄無聲息地進行偵察、橫向移動和權限提升,最后才竊取數據或造成破壞。
暴力破解不被發現:?腳本對登錄接口進行高頻密碼嘗試,但因系統沒有對大量的登錄失敗事件進行記錄和告警,導致攻擊持續進行,無人干預。
無法溯源:?數據泄露事件發生后,由于日志記錄不充分(例如,沒有記錄源IP、操作細節),導致無法調查攻擊者的入口點、操作路徑,也無法準確評估損失和彌補漏洞。
告警風暴:?日志系統雖然記錄了信息,但產生了太多無效告警,導致真正的攻擊信號被淹沒,無人關注。
防御與緩解措施
記錄關鍵安全事件:?確保對登錄(成功和失敗)、權限變更、高價值交易、輸入驗證失敗等關鍵事件進行審計日志記錄。
日志內容標準化:?日志應包含足夠的信息以便于溯源,如時間戳、源IP、用戶ID、事件類型、操作對象等,并采用統一格式(如JSON)。
集中化日志管理:?將所有服務器和應用的日志發送到集中的、安全的日志管理系統(如ELK Stack, Splunk, SIEM),便于查詢和分析。
建立有效的監控和告警:?基于日志數據,建立對可疑活動的監控儀表盤和告警規則。例如,短時間內大量登錄失敗、非工作時間的高權限操作等。
定期測試應急響應計劃:?模擬安全事件,檢驗日志和監控系統是否能有效支持事件的發現、遏制和恢復。
攻擊者視角
“一個沒有監控的系統,就像一個黑暗的房間,我可以為所欲為,而且不會留下任何腳印。”
A10:2021 - 服務器端請求偽造 (SSRF)
核心問題
“我讓你的服務器當了我的‘代理’,去攻擊那些我本來碰不到的地方。”
風險解讀
當Web應用程序在未對用戶提供的URL進行充分驗證的情況下,從遠程資源獲取內容時,就會出現SSRF漏洞。攻擊者可以欺騙應用程序向其選擇的目標發送一個偽造的請求。這使得攻擊者能夠利用服務器的身份和網絡位置,去訪問和攻擊那些通常受防火墻保護、無法從外部直接訪問的內部系統。
常見利用場景
探測內網:?利用“從URL上傳圖片”、“WebHook回調”、“PDF生成”等功能,輸入內網地址如?http://192.168.1.1:8080,通過返回的錯誤信息或響應時間,繪制出內網的拓撲“地圖”,發現開放的端口和服務。
攻擊內網應用:?通過SSRF發現內網中一個未授權訪問的Jenkins或Redis,構造URL讓服務器代替自己去訪問這些服務的API來執行命令或讀取數據。
竊取云服務憑證:?在云環境中,通過SSRF讓服務器去請求云元數據服務地址(如AWS的http://169.254.169.254/),竊取服務器的臨時訪問憑證(IAM Role Credentials),從而獲得對整個云賬戶的控制權限。
繞過防火墻:?利用服務器作為跳板,向其他外部系統發起攻擊,從而隱藏自己的真實IP地址。
防御與緩解措施
網絡層隔離:?將處理外部請求的服務器放置在獨立的網絡區域,嚴格限制其對內網其他服務的訪問權限。
應用層強制白名單:?建立一個安全的、允許訪問的URL白名單(包括域名、IP、端口和協議)。拒絕所有不在此列表中的請求。黑名單策略(如禁止127.0.0.1)很容易被繞過。
禁用未使用的URL協議:?只允許HTTP和HTTPS協議,禁用file://、gopher://、dict://等危險的協議。
統一處理請求和響應:?不要將原始的響應體直接返回給用戶,這會泄露內網信息。應用程序應該驗證并解析響應,然后以安全的方式呈現所需數據。
不解析重定向:?在發起請求時,配置HTTP客戶端庫不自動跟隨3xx重定向,防止攻擊者繞過白名單。
攻擊者視角
“你的服務器在內網里是‘自己人’,暢通無阻。我就躲在它身后,讓它替我開路和辦事。”
thumb_upthumb_down
arrow_upward_altarrow_downward_alt