歡迎加我微信：fageweiketang一起交流討論，一起學習進步。

0x00：前言

上週做滲透，有一個 sql 注入，負責安全稽核的人給開發說你們的程式既然還有 sql 注入，我一年也看不見幾個。這句話讓我又再次深刻的認識到，滲透測試常規的一些注入跨站漏洞不如以前那麼盛了，有點經驗的開發寫東西都會去考慮到了，再加上修復方法也在逐漸的完善，邏輯類的東西也應該並重的去測。

0x01：分類

我把邏輯類的問題大概總結了一下，大概可以分為十個模組，分別是登入認證模組測試、業務辦理模組測試、業務授權訪問模組測試、輸入 / 輸出模組測試、回退模組測試、驗證碼機制測試、業務資料安全測試、業務流程亂序測試、密碼找回模組測試、業務介面呼叫模組測試。

這次記錄的是第七個模組業務資料安全測試。

0x02：業務資料安全測試

1，商品支付金額篡改測試

測試方法：在一些電商系統或是支付購買商品功能處，生成訂單後去支付時，攔截其請求，看支付金額是否可以修改，修改後提交至服務區器，如果成功返回，且存在此問題。

修復方法：對於一些支付類的資訊，不能在前端控制，其校驗資訊應該由後端來完成。

2，商品訂購資料篡改測試

測試方法：這個和商品支付金額負數，提交後弱伺服器成功返回，則存在此問題。

修復方法：後端應該對其風險進行控制，對異常的交易行為進行限制和阻斷，其異常行為例如積分為負、交易商品數量為負、交易商品數量和金額不符，商品數量為 0 等。

3，前端 js 繞過測試

測試方法：例如一個促銷活動購買商品的功能，其商品有購買數量限制，比如沒人限購 1 份，這時輸入 1 傳送請求，攔截資料包修改其值，修改為多份時，如果成功提交，則存在此問題。

修復方法：對於類似的功能，其關鍵的資料資訊校驗應該由服務端完成，而不能只以前端來做判斷。例如，商品的金額，商品的折扣，商品的數量和限購等。

思路拓展：昨天沒事，隨便翻了一個網站，有一個提現餘額功能，提現時前端會有 js 判斷，其金額必須大於 50，修改前端 js 和禁用 js 出了些問題沒有利用成功，這時候前端 js 繞不過去，於是就看 js 程式碼，如果餘額大於 50 則請求的連線是什麼，然後偽造了一個其請求的資料包傳送給伺服器，其中提現金額是明文的，輸入 100 後臺返回餘額不足的資訊，猜想後臺是把餘額減去提現金額來做的功能，這時後輸入提現金額為 - 100，伺服器返回成功，返回個人中心看時，餘額變成了 100。

這個屬於典型的後臺校驗不足，修復也很簡單，後臺判斷其提現的金額即可，例如必須大於 50 且不為負數，或接收其型別時強制轉換為 int 型。

4，請求重放測試

測試方法：例如一些商品訂購功能，生成訂單時抓取其請求，然後傳送到 repeater，不斷的 go，如果一個請求可以多次成功，生成多個訂單，則存在此問題。其危害在於一次購買多次收貨。

經驗之談：除了訂購下單等功能外，可以多次請求的功能都可以做相關測試，例如新增管理員，新增一些資訊等功能，其危害在於惡意攻擊者獲取此請求後，便可操作程式。

修復方法：可以新增隨機的 token 作為驗證，一次請求後即失效。在伺服器端生成訂單的時候，要對訂單 token 對應的訂購資訊內容、使用者身份、使用者積分等一些資訊進行強制校驗。

5，業務上限測試

測試方法：說是業務上限測試，也可使說是對前幾條的總結或結合，例如一個查詢訂單功能，只能查最近 6 個月的訂單，請求後抓包，修改其值為 12 則可以檢視一年的訂單，則存在此問題。

經驗之談：上面說的幾條也可以算作業務上限問題，總結下就是在請求訂單的過程中，只要超過系統的預定值，且請求成功的，都可以算作業務上限問題，只不過在記錄報告時，需要具體的寫明哪個引數可改，這樣最好。

修復方法：修復方法：可以新增隨機的 token 作為驗證，一次請求後即失效。在伺服器端生成訂單的時候，要對訂單 token 對應的訂購資訊內容、使用者身份、使用者積分等一些資訊進行強制校驗。

0x03：總結

這次記錄了業務資料安全的一些測試方法和要點，後續會繼續記錄其他模組。

更多關於程式碼審計、WEB滲透、網路安全的運維的知識，請關注微信公眾號：發哥微課堂。