[toc]
# 邏輯漏洞
可安裝webbug3.0系統模擬攻擊
## 邏輯漏洞基礎信息
之所以稱為邏輯漏洞,是因為代碼之后是人的邏輯,人更容易犯錯,是編寫完程序后隨著人的思維邏輯產生的不足。
sql注入、xss等漏洞可以通過安全框架等避免,這種攻擊流量非法,對原始程序進行了破壞,防火墻可以檢測
而邏輯漏洞是通過合法合理的方式達到破壞,分別為不安全對象引用和功能級別訪問控制缺失。
* 不安全對象引用,指的是平行權限的訪問控制缺失,
比方說,A 和 B 兩個同為一個網站的普通用戶,他們之間的個人資料是相互保密的,A用戶的個人資料可以被 B 用戶利用程序訪問控制的缺失惡意查看,由于 A 用戶和 B用戶之間是一個同級的賬號,因此稱為平行權限的訪問控制缺失。
* 功能級別訪問控制缺失,指的是垂直權限的訪問控制缺失
比方說,A 賬號為普通賬號、B 賬號為管理員賬號,B 賬號的管理頁面時必須是以管理員權限登錄后方可查看,但 A 賬號可通過直接輸入管理頁面 URL 的方式繞過管理員登錄限制查看管理頁面,由于 A用戶和 B用戶的權限是垂直關系,因此稱為垂直權限的訪問控制缺失。
該類型屬于業務設計缺陷的安全問題,因此傳統的掃描器是無法發現的,只能通過手工的滲透測試去進行檢查。在金融平臺中以平行權限的訪問控制缺失較為常見。
建議在烏云鏡像站多看看別人挖掘邏輯漏洞的過程
### 常見的邏輯漏洞:
1. 越權修改
2. 越權查詢
3. 驗證碼回傳
4. 未進行登陸憑證驗證
5. 訂單金額任意修改
6. 密碼重置
7. 突破限制等
### 挖掘邏輯漏洞的環節:
把握住傳參就能把握住邏輯漏洞的命脈
1. 確定業務流程
2. 尋找流程中可以被操控的環節
3. 分析可被操控環節中可能產生的邏輯問題
4. 嘗試修改參數觸發邏輯問題
## 1??越權訪問
越權訪問(Broken Access Control,簡稱BAC)是Web應用程序中一種常見的漏洞,在實際的代碼審計中,這種漏洞往往很難通過工具進行自動化監測,因此在實際應用中危害很大。
### 原理說明
如果使用A用戶的權限去操作B用戶的數據,A的權限小于B的權限,如果能夠成功操作,則稱之為越權操作。 越權漏洞形成的原因是后臺使用了不合理的權限校驗規則導致的。
一般越權漏洞容易出現在權限頁面(需要登錄的頁面)增、刪、改、查的的地方,當用戶對權限頁面內的信息進行這些操作時,后臺需要對當前用戶的權限進行校驗,看其是否具備操作的權限,從而給出響應,而如果校驗的規則過于簡單則容易出現越權漏洞。
如果有waf的時候,優先考慮越權漏洞和邏輯漏洞
### 1、水平越權:
**權限類型不變,權限ID改變**
水平越權訪問是一種【基于數據的訪問控制】設計缺陷引起的漏洞。由于服務器端在接收到請求數據進行操作時沒有判斷數據的所屬人/所屬部門而導致的越權數據訪問漏洞。?
水平越權測試方法:主要通過看看能否通過A用戶操作影響到B用戶
### 2、垂直越權:
**權限ID不變,權限類型改變**
垂直越權是一種【基于URL的訪問控制】設計缺陷引起的漏洞,又叫做權限提升攻擊。
垂直越權測試思路:看看低權限用戶是否能越權使用高權限用戶的功能,比如普通用戶可以使用管理員的功能。
先抓包高權限用戶的某一操作,在抓包低權限用戶包,將低權限用戶cookie等復制到高權限包中,看能否完成同樣的操作
### 真實案例:XX網參數越權
---
問題描述:測試過程中發現,用戶在“地址管理”功能模塊可越權查看任意收貨信息,造成用戶敏感信息泄露。
1、在地址管理中,選擇“修改”,此時用抓包工具截斷GET請求:
```
#抓包數據鏈接為:
http://www.XXXX.cn/index.php?app=treasure&mod=Order&act=findId&address_id=1111
#將address_id參數值替換為任意數值如2222:
#提交后發現返回了對應用戶的收貨信息
```
### 越權漏洞突破思路
1. 一般管理頁面可能存在越權漏洞
如果是白盒測試的話
找到admin相關 需要管理員賬號才可以訪問的文件
針對于前端繞過 訪問該目錄,可能會有一個js攔截,我們利用瀏覽器隱私安全性設置找到javascrip禁用 添加網站,再次進入可能會成功
針對于后端繞過
對于沒有判斷登錄狀態refer或者判斷不標準,抓包修改為合法的refer就可以繞過
2. 有的對于用戶管理的地方可能有,例如更改用戶收貨地址等
先用自己的賬號登錄,之后抓包,將id等改變一下,查看返回值驗證
3. 有時候通過將cookie修改為他人的,也可以實現越權
4. 參數也可能有越權漏洞,例如訂單編號等等
5. 注冊過程中,輸入已經注冊過的郵箱,在相應信息中可能有返回信息的
6. 還有修改密碼如果沒有對手機號位數限制(數字位數,或者空格等特殊符號)也可能有漏洞
小結:在找越權的時候,對參數要有很強的關注,可以每一個都試一試
## 2??交易支付中的邏輯問題:
---
### 支付的邏輯漏洞的一般思路
一種是少充多得,比如充值100元時通過篡改金額改成10元,最終充值完畢后賬戶變成了100元,而實際付款卻只有10元;
一種是繞過活動頁金額限制,比如很多公司做活動強制用戶充值金額不能低于10000,而通過攔截修改金額,可以充值任意金額。
一般購物流程:
1. 挑選商品加入購物車
2. 確認購物車信息
3. 輸入物流及收貨人信息
4. 確認訂單進入支付環節
5. 交易成功等待發貨
購物流程中可能的邏輯問題:
1. 加入購物車時是否可以修改購買數量為負數,商品價格是否可以修改.
2. 確認購物車信息時是否可以修改商品數量為負數,是否存在折扣限制突破問題,是否可以修改商品總金額.
3. 輸入物流信息時是否可以控制運費,如果可以,嘗試修改為負數.
4. 確認訂單后跳轉支付接口時是否可以修改支付金額,可否不支付直接跳轉到交易成功環節.
### 預防思路:
---
增加多重檢驗,訂單較大時增加人工審核。
### 實案例:信用卡還款服務費被繞過
---
問題分析:測試發現,微錢包信用卡還款功能處存在服務費可繞過漏洞,測試過程如下:
1、選擇信用卡還款功能,填寫相關還款數值后,截斷信用卡還款GET請求,將f參數值修改為1:
2、提交修改后的請求,頁面返回成功:
## 3??密碼修改邏輯漏洞:
重置密碼對一個系統來說是非常重要的存在,所以存在的問題也是非常致命。
1. 用戶在重置密碼頁面,通過修改用戶ID對所改用戶密碼進行重置;
2. 對密碼重置頁面驗證碼繞過,然后爆破進行等。
### 密碼修改邏輯漏洞驗證

* 首先走一遍正常的密碼修改流程,把過程中所有環節的數據包全部保存.
* 分析流程中哪些步驟使用了哪些身份認證信息,使用了哪些認證方法.
* 分析哪個步驟是可以跳過,或者可以直接訪問某個步驟.
* 分析每個認證方法是否存在缺陷,可否越權?
* 首先嘗試正常密碼找回流程,選擇不同找回方式,如郵箱,手機,密碼提示問題等.
* 分析各種找回機制所采用的驗證手段,如驗證碼的有效期,有效次數,生成規律,是否與用戶信息相關聯等.
* 抓取修改密碼步驟的所有數據包,嘗試修改關鍵信息,如用戶名,用戶ID,郵箱地址,手機號碼等。詳細看以下案例:
>http://www.wooyun.org/bugs/wooyun-2010-011435
>http://www.wooyun.org/bugs/wooyun-2010-08573
>http://www.wooyun.org/bugs/wooyun-2010-012365
>http://www.wooyun.org/bugs/wooyun-2010-021818
>http://www.wooyun.org/bugs/wooyun-2010-020625
>http://www.wooyun.org/bugs/wooyun-2010-020588
>http://www.wooyun.org/bugs/wooyun-2010-019769
>http://www.wooyun.org/bugs/wooyun-2010-018722
### 預防思路:
系統后臺在重置密碼頁面驗證是否為本用戶等。
## 4??驗證碼回傳:
### 漏洞原因
這個漏洞主要是發生在前端驗證處,只要攔截數據包就可以獲取敏感信息,并且經常發生的位置在:賬號密碼找回、賬號注冊、支付訂單等。驗證碼主要發送途徑郵箱郵件 、手機短信。黑客只需要抓取Response數據包便知道驗證碼是多少。
### 預防思路:
response數據內不包含驗證碼,驗證方式主要采取后端驗證,但是缺點是服務器的運算壓力也會隨之增加;要進行前端驗證的話使用加密進行。
## 5??接口無限制枚舉:
有些關鍵性的接口因為沒有做驗證或者其它預防機制,容易遭到枚舉攻擊。
### 真實案例:用戶激活郵件炸彈攻擊
問題描述:測試發現,用戶使用郵箱注冊時,發送激活郵件功能可進行郵件炸彈攻擊。測試過程如下:
1. 用戶在激活賬號過程中選擇“重新發送”:
2. 將GET請求中的uid參數值為其他uid(需要此uid的用戶也使用郵箱注冊):
3. 重放此數據包,可形成郵件炸彈攻擊,響應包中提示發送成功:
### 防范措施:
1. 使用最小權限原則對用戶進行賦權;
2. 永遠不要相信來自用戶的輸入,使用合理(嚴格)的權限校驗規則;
3. 使用后臺登錄態作為條件進行權限判斷,別動不動就瞎用前端傳進來的條件;
4. cookie中設定多個驗證,比如自如APP的cookie中,需要sign和ssid兩個參數配對,才能返回數據。
5. 用戶的cookie數據加密應嚴格使用標準加密算法,并注意密鑰管理。
6. 用戶的cookie的生成過程中最好帶入用戶的密碼,一旦密碼改變,cookie的值也會改變。
7. cookie中設定session參數,以防cookie可以長時間生效。
## 6 邏輯漏洞導致的問題
### 業務安全問題
一些生產環境中可能出現的實際問題,我認為這不只是滲透測試工程師需要針對的,也是一些開發人員需要意識到的
### 賬戶安全
盜號、撞庫等身份盜用問題
“撞庫”攻擊的形式
* 嘗試登錄大量【用戶名+密碼】組合
* 利用已泄露的多家網站用戶數據庫
* “盜號”產生的風險
* 用戶隱私受影響
* 賬戶資金受影響
* 企業投訴和賠付率上升
### 資源濫用
1. 刷單/惡意下單
供應商刷單賺取信用
競爭對手互相下單
報復性下單
2. 控制庫存影響正常銷售
自動加購物車,自動下單
購物車過期后,重復上一步驟
正常用戶不能購買
企業商品無法售出
3. 惡意調用短信發送接口
封裝多個網站短信發送接口為一個API
向指定手機發送短信炸彈,強制對方關機
企業遭受客戶投訴導致短信通道被迫關停
4. 注冊檢查薄弱被利用接口
利用簡單的注冊判斷接口,檢查全國手機號是否在網站注冊
放大這個請求,結果是災難……為盲目“撞庫”提前篩選用戶名
5. 惡意注冊產生“馬甲”用戶
搶占正常用戶資源
影響企業營銷效果
產生虛假數據
隱藏的“炸彈”
- src導航站
- kali和msf
- 信息收集
- 收集域名信息
- Whois 查詢
- 備案信息查詢
- 信用信息查詢
- IP反查站點的站
- 瀏覽器插件
- 收集子域名信息
- 在線平臺
- 工具枚舉
- ssl與證書透明度
- DNS歷史解析
- DNS域傳送漏洞
- C段探測
- JS文件域名&ip探測
- 搜索引擎&情報社區
- google黑客
- 威脅情報
- 鐘馗之眼
- 收集相關應用信息
- 微信公眾號&微博
- APP收集&反編譯
- 收集常用端口信息
- 常見端口&解析&總結
- 掃描工具
- 網絡空間引擎搜索
- 瀏覽器插件
- nmap掃描
- 收集敏感信息
- 源碼泄露
- 郵箱信息收集
- 備份文件泄露
- 目錄&后臺掃描
- 公網網盤
- 歷史資產
- 指紋&WAF&CDN識別
- 指紋識別
- CDN識別
- 繞過CDN查找真實IP
- WAF識別
- 漏洞資源和社工
- 漏洞公共資源庫
- 社會工程
- 資產梳理
- 各種對滲透有幫助的平臺
- 掃描器
- 掃描器對比
- AppScan(IBM)_web和系統
- AWVS_web掃描
- X-Scan_系統掃描
- WebInspect_HP_WEB
- Netsparker_web
- WVSS_綠盟_web
- 安恒明鑒
- Nessus_系統
- nexpose_系統
- 啟明天鏡_web_系統
- SQL注入
- 常用函數
- sql注入步驟
- union注入和information_schema庫
- 函數和報錯注入
- SQL盲注
- 其他注入方式
- 防止SQL注入解決方案
- Access數據庫注入
- MSSQL數據庫注入
- MYSQL數據庫注入
- 神器SQLmap
- xss跨站腳本攻擊
- xss原理和分類
- xss案例和修復
- xss繞過技巧
- xss案例
- 文件上傳下載包含
- 常有用文件路徑
- 文件上傳漏洞
- 文件下載漏洞
- 文件包含漏洞
- upload-labs上傳漏洞練習
- XXE、SSRF、CSRF
- SSRF原理基礎
- SSRF案例實戰
- CSRF原理基礎
- CSRF案例及防范
- XXE之XML_DTD基礎
- XXE之payload與修復
- XXE結合SSRF
- 遠程命令執行與反序列化
- 遠程命令和代碼執行漏洞
- 反序列化漏洞
- 驗證碼與暴力破解
- 爆破與驗證碼原理
- CS架構暴力破解
- BS架構暴力破解
- WEB編輯器漏洞
- 編輯器漏洞基礎
- Ewebeditor編輯器
- FCKeditor編輯器
- 其他編輯器
- web中間件漏洞
- 中間件解析漏洞
- Tomcat常見的漏洞總結
- Jboss漏洞利用總結
- Weblogic漏洞利用總結
- WEB具體步驟
- 旁注和越權
- CDN繞過
- 越權與邏輯漏洞
- WEB應用常見其他漏洞
- WEB登陸頁面滲透思路
- 獲取WEBshell思路
- 社工、釣魚、apt
- 社工和信息收集
- 域名欺騙
- 釣魚郵件
- 一些釣魚用的掛馬工具
- 代碼審計
- 代碼審計工具
- WAF繞過
- WAF基礎及云WAF
- 各種WAF繞過方法
- 繞過WAF上傳文件
- 系統提權
- windows系統提權
- linux系統提權
- 數據庫提權操作系統
- 內網橫向滲透
- 內網穿透方式
- 一些內網第三方應用提權
- ARP與DOS
- ARP欺騙
- DOS與DDOS
- 一些DOS工具