實戰經驗還是比較少，但是打 CTF（水比賽）的經歷很多🐶，感慨自己對於漏洞的理解不夠深刻，於是準備開始從邏輯漏洞先開始總結
參考大佬們的經驗，簡單總結了下邏輯漏洞的思維導圖
一些常見的邏輯漏洞分析#
任意密碼找回 / 任意手機號修改#
經典流程：
驗證 old 手機號 /old 密碼 -> 提供新的手機號 / 密碼 -> 提交修改
第一步，驗證原有手機號或者密碼，如果可以修改返回的 response 包，那麼就可以繞過這一步驟，
此時如果第三步沒有驗證第一步認證是否成功，則可以任意綁定手機號 / 修改任意密碼
並發抽獎 / 簽到#
抽獎、簽到並發問題，通過多次重放可以累計登錄天數，獲得多個抽獎券等
一般的解決辦法都是通過 CAS 操作來進行的，CAS 操作包含三個參數：
- 內存位置 V
- 期望的原值 A
- 新值 B
CAS 首先檢查 V 種的當前值是否和 A 匹配，如果匹配，則更新為 B，否則不作操作。這裡的整個操作都是原子的，從而保證同步
前端 JS#
多翻翻前端 JS，可以找到很多點，如：
- 隱藏的接口
- js source map 文件
主要參考這篇：
[https://xz.aliyun.com/t/9453]
登錄態洩露#
在一些 H5 場景、小程序場景中，很多開發者偷懶，其實也是因為登錄態的設計過於複雜，導致簡單的通過 openid 等方式直接驗證
這種案例就比較多了，多見於微信生態體系下
報錯頁面#
報錯頁面也是可以返回很多信息的，最常見的就是 CTF 種通過報錯頁面來實現模版注入
實戰場景中，報錯頁面可能會洩露很多敏感的信息，比如登錄態🐶(還真遇到過
Google hacking 擴展#
知道了這麼多邏輯漏洞，怎麼去測試呢？
通過 Google hacking 語法能找到很多的站點，一個個測就好了，比如我們找支付功能的，就可以通過這樣搜素
inurl:m intitle:訂單詳情 inurl:id=
我的訂單 訂單詳情
inurl:order 訂單詳情
inurl:wap intitle:訂單詳情
inurl:m intitle:訂單詳情
inurl:php intitle:訂單詳情
title:訂單詳情 手機號
site:.com title:訂單詳情
title:訂單詳情 身份證
通過這個思路就能找到很多實際的支付站點，並且一個個去驗證測試
如果漏洞比較通用的話，就可以編寫下 poc 集成到 xray 或者其他被動掃描工具了
預計下一篇就來分享下對這些站點的挖掘🤔，先水完這一篇好了