OWASP TOP 10 漏洞詳解以及防護方案

OWASP介紹

• 官網：http://www.owasp.org.cn/
• OWASP TOP10 指出了 WEB 應用面臨最大風險的 10 類問題，是目前 WEB 應用安全方面最權威的項目。
• OWASP 是一個開源的、非盈利全球性安全組織，致力於應用軟件的安全研究。OWASP 的使命是應用軟件更加安全，使企業和組織能夠對應用安全風險作出更清晰的決策。 目前 OWASP 全球擁有 140 個分會近四萬名員，共同推動了安全標准、安全測試工具、安全指導手冊等應用安全技術的發展。

OWASP TOP 10

• A1：2017 注入
• A2：2017 失效的身份認證
• A3：2017 敏感數據泄露
• A4：2017 XML外部實體
• A5：2017 失效的訪問控制
• A6：2017 安全配置錯誤
• A7：2017 跨站請求腳本（XSS）
• A8：2013 跨站請求偽造（CSRF）
• A8：2017 不安全的反序列化
• A9：2017 使用含有已知漏洞的組件
• A10：2017 不足的日志記錄和監控

A1 2017注入injection

注入：用戶的輸入被當成命令/代碼執行或者解析了

將不受信用的數據作為命令或查詢的一部分發送到解析器時，會產生諸如SQL注入、NoSQL注入、OS注入（操作系統命令）和LDAP（輕量目錄訪問協議）注入的注入缺陷。攻擊者的惡意數據可以誘使解析器在沒有適當授權的情況下執行非預期命令或訪問數據。

用戶的輸入並非固定位置，可能存在於：

• 輸入框
• 搜索欄
• 提交表單
• URL鏈接
• 所有的GET/POST請求的請求頭和請求包頭
• 留言
• 評論
• 幾乎任何數據源都有可能成為注入載體，只要是能被發出的數據位置

可被執行的代碼：

• SQL
• LDAP
• Xpath or NoSQL
• 系統命令
• XML語言
• SMTP包頭
• 表達式語句
• ORM查詢語句
• 危害：該代碼能做什么即是危害

注入的分類

通常的注入有sql注入和命令注入

SQL注入攻擊

動態頁面有時會通過腳本引擎將用戶輸入的參數按照預先設定的規則構造成SQL語句來進行數據庫操作。SQL注入攻擊指的是通過構造特殊的輸入作為參數傳入Web應用程序，改變原有的SQL語句的語義來執行攻擊者所要的操作，其主要原因是程序沒有采取必要的措施避免用戶輸入內容改變原有SQL語句的語義。

SQL注入的危害：

• 繞過登陸驗證：使用萬能密碼登陸網站后台等
• 獲取敏感數據：獲取網站管理員賬號、密碼等
• 文件系統操作：列目錄、讀取或寫入文件等
• 注冊表操作：讀取、寫入、刪除注冊表等
• 執行系統命令：遠程執行命令

參考鏈接：https://www.zhiji.icu/2021/03/06/qian-tan-sql-zhu-ru/

防護方案

1、關閉 SQL 錯誤回顯
2、前端輸入字符白名單驗證（長度、類型等）
3、對輸入的特殊字符使用轉義處理
4、SQL 操作使用 PreParedStatement
5、SQL 服務運行於專門的賬號，並且使用最小權限
6、限制 SQL 服務的遠程訪問，只開放給特定開發人員
7、代碼審計，最有效的檢測應用程序的注入風險的方法之一
8、使用成熟的 waf

命令注入攻擊

WEB應用代碼中，有時會允許接收用戶輸入一段代碼，之后在web應用服務器上執行這段代碼並將結果返回給用戶，如果這段代碼沒有進行限制，用戶就可能執行惡意代碼。

防護方案

1、白名單效驗命令參數

2、單引號禁止命令解析功能

A2 2017 失效的身份認證

通過錯誤使用應用程序的身份認證和會話管理功能，攻擊者能夠破譯密碼、密鑰或會話令牌，或者暫時或永久的冒充其他用戶的身份。

危害：

這些漏洞可能導致部分甚至全部賬戶遭受攻擊，一旦攻擊成功，攻擊者就能執行合法的任何操作

防護方案

1、使用內置的會話管理功能

2、通過認證的問候

3、使用單一的入口點

4、確保在一開始登錄SSL保護的網頁

A3 2017 敏感數據泄露

一般我們的敏感信息包括密碼、財務數據、醫療數據等，由於web應用或者API未加密或不正確的保護敏感數據，這些數據極易遭到攻擊者利用，攻擊者可能使用這些數據來進行一些犯罪行為，因此，未加密的信息極易遭到破壞和利用，我們應該加強對敏感數據的保護，web應用應該在傳輸過程中數據、存儲的數據以及和瀏覽器的交互時的數據進行加密，保證數據安全。

實例場景

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

防護方案

1、對於 github 泄露，定期對倉庫掃描

2、對於應用網站目錄定期掃描

3、使用強壯的網絡協議與算法

4、注重對敏感數據的保護

A4 2017 XML外部實體（XXE）

XXE 全稱為XML External Entity attack 即XML(可擴展標記語言) 外部實體注入攻擊，早期或配置錯誤的XML處理器評估了XML文件外部實體引用，攻擊者可以利用這個漏洞竊取URI(統一資源標識符)文件處理器的內部文件和共享文件、監聽內部掃描端口、執行遠程代碼和實施拒絕服務攻擊。

攻擊方式

當應用程序解析 XML文件時包含了對外部實體的引用，攻擊者傳遞惡意包含 XML 代碼的文件，讀取指定的服務器資源。

漏洞原因

XML 協議文檔本身的設計特性，可以引入外部的資源；定義 XML 文件時使用的外部實體引入功能

漏洞影響

讀取服務器敏感資料，如、/etc/password
讀取應用程序源碼

防護方案

1、關閉 DTD (Data Type Definition)
2、禁止外部實體引入

2.1 使用開發語言提供的禁用外部實體的方法
PHP：

libxml_disable_entity_loader(true);

其他語言:

https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet

3、過濾用戶提交的XML數據

關鍵詞

system
file://
public
http://
expect
...

A5 2017 無效的訪問控制（業務邏輯漏洞）

失效的訪問控制就是越權訪問漏洞

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

垂直越權：

低權限用戶可以訪問更高權限才能訪問的頁面

水平越權：

同級別權限用戶的權限控制失效，攻擊者可以從普通用戶A的權限提升到普通用戶B的權限訪問應用程序

防護方案

1、對參數的白名單過濾

2、對權限的控制管理重新設計與限制

3、限制下載文件的類型

A6：2017 安全配置錯誤

安全配置錯誤是比較常見的漏洞，由於操作者的不當配置(默認配置，臨時配置，開源雲存儲，http標頭配置，以及包含敏感信息的詳細錯誤)，導致攻擊者可以利用這些配置獲取到更高的權限，安全配置錯誤可以發生在各個層面，包含平台、web服務器、應用服務器、數據庫、架構和代碼。

如 python 開發中對於 Django 框架在生產環境啟用了 Debug 模式

可能受到攻擊的應用程序：

• 缺少適當的安全加固、雲服務的權限配置錯誤
• 應用程序啟用或安裝了不必要的功能（端口、服務、網頁、賬戶或權限等）
• 默認賬戶的密碼仍然沒有更改
• 錯誤處理機制向用戶披露堆棧跟蹤或其他大量錯誤信息
• 對於更新的系統，禁用或不安全地配置最新的安全功能
• 應用程序服務器、應用程序框架（如：Struts、Spring、ASP.NET）、庫文件、數據庫等沒有進行安全配置
• 服務器不發送安全標頭或指令，或未對服務器進行安全配置
• 應用軟件已過期或易受攻擊

漏洞影響

可讓攻擊者獲取到敏感數據、提升權限，如未修改應用程序配置的默認密碼，未刪除應用程序安裝程序目錄文件等

防護方案

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

A7：2017 跨站腳本（XSS）

當應用程序的新網頁中包含不受信任的、未經恰當驗證、轉義的數據或可以使用HTML、JavaScript的瀏覽器API更新的現有網頁時，就會出現xss漏洞，跨站腳本攻擊是最普遍的web應用安全漏洞，甚至在某些安全平台都存在xss漏洞。xss會執行攻擊者在瀏覽器中執行的腳本，並劫持用戶會話，破壞網站或用戶重定向到惡意站點，使用xss還可以執行拒絕服務攻擊。

存在三種XSS類型，通常針對用戶的瀏覽器：

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

典型的XSS攻擊可導致盜取session、賬戶、繞過MFA、DIV替換、對用戶瀏覽器的攻擊（如：惡意軟件下載、鍵盤記錄）

防護方案

XSS 過濾器的作用是過濾用戶（瀏覽器客戶端）提交的有害信息，從而達到防范XSS 攻擊的效果。

1、輸入過濾

輸入驗證

• 對用戶提交的信息進行“有效性”驗證。
• 僅接受指定長度
• 僅包含合法字符
• 僅接收指定范圍
• 特殊的格式，例如，email 、IP 地址。

數據消毒

• 過濾或凈化掉有害的輸入

$code = str_replace('script','',$xsscode);

2、輸出編碼

HTML 編碼是HTML 實體編碼。

$code = htmlspecialchars($xsscode);

3、黑白名單策略

不管是采用輸入過濾還是輸出編碼，都是針對信息進行黑、白名單式的過濾。

• 黑名單，非允許的內容
• 白名單，允許的內容

4、防御DOM 型XSS

避免客戶端文檔重寫，重定向或其他敏感操作。

A8 2017 不安全的反序列化

不安全的反序列化可以導致遠程代碼執行、重放攻擊、注入攻擊或特權升級攻擊

對反序列化的利用是有點困難的。因為在不更改或調整底層可被利用代碼的情況下，現場的反序列化漏洞很難被使用

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

• 如果應用中存在可以在反序列化過程中或者之后被改變行為的類，則攻擊者可以通過改變應用邏輯或者實現遠程代碼執行攻擊。我們將其稱為對象和數據結構攻擊
• 典型的數據篡改攻擊，如訪問控制相關的攻擊，其中使用了現有的數據結構，但內容發生了變化

防護方案

1、對數據對象簽名，並作完整檢查

2、數據對象中的數據做嚴格的類型檢查，限制一部分惡意攻擊

3、隔離反序列化操作環境

A9 2017 使用含有已知漏洞的組件

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

對於一些漏洞很容易找到其利用程序，但對其他的漏洞則需要定制開發

這種安全漏洞普遍存在。基於組件開發的模式使得多數開發團隊根本不了解其應用或API中使用的組件，更談不上及時更新這些組件了

經常爆出漏洞的組件：

• Weblogic
• Strust-2

防護方案

1、及時更新、修復組件漏洞

2、移除不再使用的依賴組件

A10 2017 日志記錄和監控不足

對於日志記錄的監控不足，以及事件響應缺失或無效的集成，使得攻擊者攻擊系統、應用、盜取數據等操作無法被發現和追查。讓其能夠進一步攻擊系統、保持持續性的或攻擊更多的系統，以及對數據的不當操作。

防護方案

1、啟用日志監控、告警機制

2、啟用異地監控，C/S架構的監制機制

3、盡可能的完整記錄所有日志

A11 2013 跨站請求偽造（CSRF）

它強制終端用戶在當前對其進行身份驗證后（登陸 cookie session）的Web 應用程序上執行，非本意操作的攻擊。 CSRF 攻擊的重點在於更改狀態的請求，而不是盜取數據，因為攻擊者無法查看偽造請求的響應。

借助於社工的一些幫助，例如，通過電子郵件或聊天發送鏈接，攻擊者可以誘騙用戶執行攻擊者選擇的操作。

如果受害者是普通用戶，則成功的CSRF 攻擊可以強制用戶執行更改狀態的請求，例如轉移資金、修改密碼等操作。

如果受害者是管理賬戶，CSRF 攻擊會危及整個Web 應用程序.

關鍵點

用戶沒有退出登陸

CSRF 是一種欺騙受害者提交惡意請求的攻擊。它繼承了受害者的身份和特權，代表受害者執行非本意 的、惡意的操作。

對於大多數站點，瀏覽器請求會自動發送與站點關聯的所有憑據，例如用戶的會話Cookie，IP 地址， Windows 域憑據等。因此，如果用戶已對當前站點進行了身份驗證，則該站點沒有辦法區分一個請求 是受害者發送的合法請求還是攻擊者偽造受害者身份發送的非法請求。

目標

CSRF 的目標是更改用戶賬戶的狀態，攻擊者利用CSRF 發送的請求都是更改狀態的請求，比如，轉賬、 更改密碼，購買商品等等。

CSRF 的場景中，攻擊者是沒有辦法獲得服務器的響應。

防護方案

無效的防御

• 使用秘密的Cookie
• 僅接收POST 請求（get請求容易泄露消息）
• 多步交易 （有可能被惡意攻擊者預測）
• URL 重寫 （用戶身份信息會暴露在url中）
• HTTPS （所有安全機制的前提）

有效的防御

• 驗證Referer 字段

• 添加Token 驗證，可以參考dvwa csrf最高級別

一串隨機字符串 每次客戶端請求，服務器都會刷新token 服務器創建了一個token值，存儲在服務器中並下發到瀏覽器 下次瀏覽器請求，需要提交該token值，服務器根據瀏覽器提交的token 與服務器中存儲的token進行 對比， 如果二者一致說明請求是正常。 如果二者不一致說明請求可能來自惡意的攻擊者 token的設計，在php中通常利用session機制

• 二次驗證

在關鍵操作之前，再輸入密碼或者驗證碼。