業務 Web 漏洞攻擊與防禦的思考
隨著網路安全觀念的進一步強化，以及在開發過程中越來越成熟的自動化防護機制使得基礎 web 漏洞的挖掘和利用變得越來越困難，所以加強對業務安全邏輯漏洞的學習和利用變得尤其重要，這篇文章也算是我學習和思考的一個記錄。
0X01 為什麼學習業務安全
其實除了我個人在實戰中深刻的體會到基礎 Web 漏洞的挖掘困難以外(常常是 xss 或者 csrf之類的，sqli 都少之又少)，我還從一些安全事件(比如 pdd 的百元優惠券)中發現業務邏輯的安全漏洞可能造成的危害更大，涉及到的經濟利益也更多，這也成為了不法分子重點關注的物件，我們作為安全研究人員也要重點學習研究。
0X02 業務安全測試的一般流程
1.前期熟悉
要去了解當前系統的規模、已經具備的安全措施、系統的部署情況等
2.場景建模
掌握重要的系統功能，並將每個系統功能劃分成待測試的模組，如下圖所示
3.功能梳理
對每個不同的模組的運作流程進行梳理，通常分為以下兩個維度：
(1)使用者端、管理員端
(2)客戶端、伺服器端
如下圖：
4.風險分析
可能存在的風險點如下圖
(1)業務環節存在的風險
主要是使用者可見的，如註冊登入等是否有完善的身份驗證機制，cookie session 機制，驗證碼能否被爆破等
(2)支撐系統存在的風險
使用者訪問控制機制是否完善，是否存在水平或垂直越權，使用者資料是否加密儲存，是否明文傳輸，是否存在未授權的介面呼叫，重放遍歷等
(3)業務環節間存在的風險
業務流程是否存在亂序，是否可以跳過、回退或者是重放。環節間的資料傳輸是否有一致性校驗以及加密機制，是否可以被監聽、竊取、篡改或者重放。
(4)支撐系統間存在的風險
系統間傳遞的引數是否加密，是否能監聽竊取或者篡改，是否有著完備的過濾機制來預防 SQLi XSS 等攻擊
(5)業務環節與支撐系統間存在的風險
資料傳輸是否加密，是否用不完善的加密機制(如：前端加密，簡單的md5等),是否能比較好的處理請求的併發，防止出現條件競爭，是否有完善的過濾和編碼機制預防 SQLi XSS 等攻擊。
5.開始測試
手工與自動化工具結合，白盒和黑盒相結合的方式進行測試
6.撰寫報告
根據不同企業或者公司的要求進行撰寫，詳細說明漏洞點，觸發條件以及修復建議等
0X03 業務測試技術
1.登入認證模組
(1)暴力破解
[測試方法]
常常使用 Bp 結合字典對賬號密碼進行暴力破解
注意：
1.intercept is on 關閉的時候瀏覽器的請求依然會經過 Bp 只是不被攔截，所有的請求可以在 history 中檢視
[修復建議]
1.設定登入驗證碼，並在嘗試登入後改變，同時驗證碼的強度不能過低，防止攻擊者使用 OCR 識別
2.設定登入失敗次數限制，相同使用者五分鐘內失敗6次則三小時內禁止登入
3.可增加手機簡訊校驗等輔助校驗方式
(2)本地加密傳輸測試
[測試方法]
(1)首先檢視是否使用了 SSL(HTTPS)，如果沒有使用 SSL 的話，使用 Bp 獲登入資料包，檢視是否存在明文傳輸，如圖所示
此時可判定存在風險
(2)如果是使用了 SSL 可以使用 wireshark 抓包看一下是不是真的加密了，如圖所示
[修復建議]
1.部署有效的 SSL 證書
2.及時部署了 SSL 也儘可能不要使用純明文傳輸，降低被攻擊的風險
(3)Session測試
1.Session 會話固定測試
[漏洞原理]
在使用者進入登入頁面，但還未登入時，就已經產生了一個session，使用者輸入資訊，登入以後，session的id不會改變，也就是說沒有建立新session，原來的session也沒有被銷燬）。攻擊者事先訪問系統並建立一個會話，誘使受害者使用此會話登入系統，然後攻擊者再使用該會話訪問系統即可登入受害者的賬戶。會話固定攻擊的原理及流程如下圖所示：
[測試方法]
(1)開啟登入頁面
(2)使用 Bp 檢視登入前的 cookie 中的 SESSID(如果沒有可以嘗試登入然後偽造一個)，登陸後再檢視 SESSID 如果沒有更新則說明存在該漏洞
[修復建議]
在使用者輸入正確的使用者名稱和密碼以後(使用者的許可權級別發生了變化)，系統需要強制更新 SESSION，並強制原始會話失效。
2.Session 會話登出測試
[漏洞原理]
在使用者退出登入或者登出之後，服務端應將使用者的會話標識 SESSID 在服務端立即登出，如果不及時登出，將導致其在退出後依然有效，攻擊者在非法獲取其識別符號後可進行無認證登入
[測試方法]
登陸後使用 Bp 截獲資料包，然後退出登入後，對該資料包進行重放，如果重放成功則證明漏洞存在
[修復建議]
退出登入後服務端應及時清除 SESSION 會話識別符號，並清空客戶端瀏覽器的 SESSID
3.Session 會話超時測試
[漏洞原理]
客戶登陸後如果長時間與伺服器沒有互動操作，session 應在規定的時間內自動失效，並要求重新登入，否則可能會存在資訊洩露風險。
[測試方法]
登陸後使用 Bp 截獲資料包，然後等待20~30分鐘，對該資料包進行重放，如果重放成功則證明漏洞存在。
[修復建議]
建議設定會話的生存時間不要超過30分鐘
(4)Cookie 偽造測試
[漏洞原理]
服務端為了鑑別使用者身份將使用者的身份資訊儲存在 cookie 中並通過瀏覽器儲存在使用者本地的檔案中，但這些資訊是明文儲存的，攻擊者一旦通過某種攻擊手段獲取了使用者的 cookie 就可以篡改使用者的資訊然後偽裝成其他使用者甚至是更高許可權的使用者進行登入。
[測試方法]
通過 Bp 抓包然後，嘗試修改使用者的 cookie 部分內容，比如修改使用者 id 或者使用者名稱等，然後重放，看是否能未授權訪問其他使用者資訊
[修復建議]
使用 session 機制解決，並設定 cookie 為 http-only ,設定 cookie 的 secure 屬性(至於 cookie 和 session 機制的比較請看我的這篇文章 )
(5)密文比對認證測試
[漏洞原理]
一般網站在輸入密碼以後會在伺服器端進行 hash 加密然後再與資料庫中的資訊進行比對來判斷密碼正誤，但是有些網站的在輸入密碼以後會在客戶端本地(前端)進行 hash 加密然後再傳到伺服器端進行驗證，這樣就會洩露加密方式和金鑰資訊。
[測試方法]
使用 Bp 檢查傳輸的密碼的形式是不是經過了加密，然後我們可以去前端尋找有沒有對應的前端加密程式碼，並判斷加密方式和使用的金鑰，然後我們可以對密碼字典進行對應的加密以後再進行暴力破解
[修復建議]
請不要使用前端對密碼進行加密的方式，加密處理要放在後臺進行。
(6)登入失敗資訊測試
[漏洞原理]
在登入失敗時會明確提示 使用者名稱錯誤或者密碼錯誤的資訊，而不是模糊的使用者名稱密碼錯誤，這樣攻擊者就能通過返回的資訊對使用者名稱和密碼進行暴力破解
[測試方法]
使用正確的賬號登入時輸入錯誤的密碼，看返回資訊是否是密碼錯誤，如果是則說明漏洞存在。
[修復建議]
不管是使用者名稱錯誤還是密碼錯誤都不能明確的提示，返回統一的提示 “使用者名稱或密碼錯誤”
2.業務辦理模組
(1)訂單ID篡改測試
[漏洞原理]
攻擊者只要註冊一個普通使用者的賬號就能通過遍歷訂單的 ID 來越權檢視其它使用者的訂單，其中可能包含使用者的身份證資訊，家庭住址，電話等敏感資訊。
[測試方法]
通過抓包檢視是否可以有訂單號資訊可以直接修改等進行越權測試
[修復建議]
檢視訂單的時候要通過 session 校驗檢視訂單者的身份，防止平行越權
(2)手機號碼篡改測試
[漏洞原理]
有時候手機號碼作為鑑定使用者身份的引數，在登入成功以後，開發者可能對一些頁面的身份校驗出現缺失，這樣就可以通過篡改使用者的手機號來進行越權
[測試方法]
通過抓包檢視是否可以有手機號資訊可以直接修改從而進行越權測試
[修復建議]
通過 session 來校驗身份，防止平行越權，另外對於APP，不要完全相信從手機中讀取的手機號，要做好完善的身份認證。
(3)使用者ID篡改測試
[漏洞原理]
有時候使用者 ID 作為鑑定使用者身份的引數，在登入成功以後，開發者可能對一些頁面的身份校驗出現缺失，這樣就可以通過篡改使用者的手機號來進行越權
[測試方法]
通過抓包檢視是否可以有手機號資訊可以直接修改從而進行越權測試
[修復建議]
通過 session 判斷使用者的身份，不要輕易相信使用者傳過來的 ID ，如果想通過 id 判斷，那也要與 session 進行對比
(4)郵箱和使用者篡改測試
[漏洞原理]
傳送郵件的時候篡改其中的發件人引數可能會使得攻擊者偽造發件人進行釣魚攻擊，
[測試方法]
通過抓包檢視是否可以有發件人資訊可以直接修改從而進行偽造
[修復建議]
發訊息時要通過 session 判斷使用者的身份，只有 發件人 id 和 session 一致的時候伺服器才會接受該郵件
(5)商品編號篡改測試
[漏洞原理]
在生成訂單跳轉支付頁面的時候，如果抓包可以篡改商品的金額，那麼就能實現小金額購買商品，同樣，除了篡改金額，還能夠篡改商品的編號，即使用一個商品的價格來購買另一件商品。
[測試方法]
通過抓包檢視是否可以有金額或者商品編號資訊可以直接修改從而進行偽造
[修復建議]
商品的金額不要在客戶端傳入，防止被惡意篡改，如果必須在客戶端輸入，交易之前必須要驗證
(6)條件競爭測試
[漏洞原理]
在服務端邏輯與資料庫讀寫存在時序問題時，可能會存在條件競爭，攻擊者可以多執行緒併發請求，在資料庫餘額更新以前多次兌換積分或者購買商品。
[測試方法]
攻擊者在提交訂單的時候抓包，並使用多執行緒的方式重放此包，部分包就可能繞過金額和次數的判斷從而請求成功。
[修復建議]
處理訂單業務的時候使用鎖的方式，保證業務的原子性
3.業務授權訪問模組
(1)未授權訪問測試
[漏洞原理]
使用者在沒有授權的情況下能直接訪問需要授權才能訪問的頁面，
[測試方法]
嘗試在登入後臺等需要授權訪問的頁面以後，把 URL 複製到別的瀏覽器中看是否能訪問成功
[修復建議]
對需要許可權的頁面進行 SESSION 認證，對使用者訪問的每一個 URL 做身份鑑別，正確校驗使用者的身份和 token
(2)越權測試測試
[漏洞原理]
水平越權：普通使用者之間操作可互相影響
垂直越權：低許可權使用者能操作高許可權使用者才能操作的東西
[測試方法]
Bp 抓包檢視並修改低許可權使用者的身份資訊為同等許可權的其他使用者或者是高許可權使用者後進行重放，如果成功則說明漏洞存在
[修復建議]
對需要許可權的頁面進行 SESSION 認證，對使用者訪問的每一個 URL 做身份鑑別，正確校驗使用者的身份和 token
4.回退模組測試
(1)回退訪問測試
[漏洞原理]
很多 web 應用存在修改密碼等模組，那麼在修改成功後點擊瀏覽器的回退按鈕，發現依然能重複之前的操作，這樣就破壞了分步驟進行
[測試方法]
很多 web 應用存在修改密碼等模組，那麼在修改成功後點擊瀏覽器的回退按鈕，發現依然能重複進行的就說明存在漏洞
[修復建議]
對於業務流程有多步的情況，收下判斷該步的請求是不是由上一步發起的，如果不是則返回錯誤或者是頁面失效
5.驗證碼機制測試
(1)驗證碼暴力破解測試
[漏洞原理]
有些驗證碼是 4~6 位數字，或者是有一定可控區間的數字字元，如果沒有設定好驗證碼的失效時間或者最大的嘗試次數嗎，那麼攻擊者就可以對其進行暴力破解。
[測試方法]
Bp 抓取填寫驗證碼的資料包，然後對其進行暴力破解攻擊，如果在跑了數十個可能的值以後返回值沒有出現失效或者出錯的問題的話，那麼判斷漏洞存在
[修復建議]
(1)增加驗證碼的強度
(2)合理設定驗證碼的失效時間
(3)限制一定時間內的重複嘗試次數
(2)驗證碼重複使用測試
[漏洞原理]
如果驗證碼驗證成功後沒有將 session 及時清空，驗證碼即可重複使用。
[測試方法]
Bp 抓取提交驗證碼的請求包，在首次驗證成功以後重複提交，如果依然提交成功則說明漏洞存在。
[修復建議]
驗證碼在一次認證成功以後，服務端便清空認證成功的 session ，防止驗證碼被重複利用。
(3)驗證碼客戶端回顯測試
[漏洞原理]
瀏覽器請求伺服器傳送如手機驗證碼的同時在瀏覽器中檢視返回包，如果此時驗證碼也在返回包中出現則會洩露驗證資訊
[測試方法]
瀏覽器請求伺服器傳送如手機驗證碼的同時在瀏覽器中檢視返回包，如果此時驗證碼也在返回包中則說明漏洞存在
[修復建議]
禁止驗證碼本地生成，或者驗證，要採取伺服器端生成並驗證的方式
(4)驗證結果篡改測試
[漏洞原理]
我們可以通過 Bp 抓取返回包，對驗證結果的標誌位進行篡改，如 0 改成 1 ,然後 forward 以後欺騙驗證成功
[測試方法]
我們可以通過 Bp 抓取返回包，對驗證結果的標誌位進行篡改，如 0 改成 1 ,然後 forward 以後欺騙驗證，如果成功，則說明漏洞存在
[修復建議]
建議在伺服器端增加驗證碼的認證機制，對驗證結果進行二次校驗
(5)驗證碼自動識別測試
[漏洞原理]
驗證碼強度不夠，導致可以使用自動化工具進行 OCR 識別
[測試方法]
使用自動化識別工具對驗證碼進行識別測試，如果識別成功則說明漏洞存在
[修復建議]
(1)增加背景元素的干擾，如背景顏色背景字母等
(2)字元字型進行扭曲、粘連
(3)使用問答題作為驗證方式，如四則運算等
(4)使用和使用者有關聯的資訊作為驗證碼，如最近買過的商品等
6.業務流程亂序測試
(1)業務流程繞過測試
[漏洞原理]
例如整個業務流程分為三步，第一步：註冊傳送驗證碼，第二步：輸入驗證碼，第三步：註冊成功，那麼如果在輸入驗證碼後抓包修改使用者身份資訊可以的話，就會導致第一第二步被繞過。
[測試方法]
例如整個業務流程分為三步，第一步：註冊傳送驗證碼，第二步：輸入驗證碼，第三步：註冊成功，那麼如果在輸入驗證碼後抓包修改使用者身份資訊可以的話，則說明漏洞存在
[修復建議]
對敏感資訊如身份 ID 等進行加密處理，並要在伺服器端進行二次校驗
7.業務介面呼叫模組測試
(1)介面呼叫重放測試
[漏洞原理]
在簡訊，郵件的呼叫測試中，對簡訊郵件等介面進行重複呼叫測試可以發出多條資料
[測試方法]
在簡訊，郵件的呼叫測試中，對簡訊郵件等介面進行重複呼叫測試，如果能成功傳送多條資料則說明漏洞存在
[修復建議]
(1)對生成訂單環節進行驗證碼測試
(2)每個訂單使用唯一的 token ，提交一次 Token 失效
(2)介面未授權訪問測試
[漏洞原理]
敏感的介面的呼叫需要使用者的許可權資訊，但是由於沒有對介面進行身份校驗，攻擊者可以直接去呼叫介面的功能，對介面進行攻擊
[測試方法]
使用 Bp 的爬蟲功能對整站進行爬取，篩選出特定型別(如 json 等)的請求，然後判斷該介面是否存在敏感資訊，並直接將其放在瀏覽器中訪問，如果返回的幾結果包含敏感資訊則說明漏洞存在
[修復建議]
(1)使用 token 校驗，在 URL 中設定 Token 欄位，只有 token 驗證通過後才能使用介面，並且使用一次後 token 失效
(2)使用介面時，後端對登入狀態進行驗證，如果登陸成功則返回資料，如果失敗則返回錯誤
(3)callback自定義測試
[漏洞原理]
由於同源策略的限制，有時候我們需要使用 jsonp 的方式在不同源的兩個地址之間互動，其中 回撥函式作為 jsonp 的引數之一決定了使用的函式名，那麼如果沒有對 callback 的輸入進行白名單過濾，被攻擊者控制的話，那麼就會造成 xss 等攻擊
[測試方法]
使用 Bp 的爬蟲功能對整站進行爬取，篩選出帶有 callback 或者 jsonp 引數的請求，並對請求響應的型別進行判斷，如果是 text/html 則對該 Callback 進行注入，看能否觸發 xss
[修復建議]
(1)嚴格定義返回包的 content-type 為 applocation/json 而不是 text/html
(2)建立 callback 白名單
(3)對 callback 引數進行過濾 HTML 標籤
(4) Webservice 測試
[漏洞原理]
Webservice 這個 api 介面如果不對使用者的輸入進行過濾，則可能會受到 sql 注入攻擊
[測試方法]
通過爬蟲或者目錄掃描的方法找到伺服器的 webservice 連結，然後使用 AWVS 的 webservice editor 功能匯入各個介面函式，通過關鍵詞(如 get exec )定位到函式介面，使用 Http editor 對每一個介面的輸入引數進行測試
[修復建議]
(1)為 webservice 新增身份認證，認證成功才能呼叫
(2)後端對輸入引數進行過濾才能將其輸入到函式當中
(3)對敏感功能的函式新增密碼認證，認證通過才能使用
0X04 總結
結合著書本和資料簡單總結了一下常見的一些應用邏輯漏洞和利用方式，當然還是很不全面，未來或許還會補充完善。