由於程序邏輯不嚴謹或邏輯太過復雜，導致一些邏輯分支不能正常處理或處理錯誤，統稱為業務邏輯漏洞
JSRC 安全小課堂第125期，邀請到月神作為講師就如何通過技術手段挖掘業務邏輯下的漏洞為大家進行分享。同時感謝小伙伴們的精彩討論。
京安小妹:業務邏輯漏洞常見發生位置？
月神：
要是按細節來說，每一處都可以是發生位置。
每種類型的APP都有自己的常見漏洞位置。
例如購買，出售，每一條協議的關鍵參數。
京安小妹:業務邏輯漏洞的分類？
月神：
本文中特定值指的是指當系統保存數據為int整型類型時：最大值/單價+1就是特定值了。當數量超出特定值后，又會從0開始計算
一、飲料販賣機
-
替換訂單ID，創建訂單時在支付界面，在此創建訂單替換訂單ID（高價替換低價）
-
無限新用戶優惠訂單，重復創建優惠訂單
-
替換優惠卷ID（未達到條件使用）
-
個別情況訂單數量為1.99時，客戶端只支付1元，實際上服務器認為支付了2元。
-
取貨時並發（真實案例）
二、 直播
-
快速進出房間炸房
-
無限發送點贊協議
-
修改禮物數量，0，小數，負數，特定值（一般情況下為1073741824）
-
修改禮物ID，遍歷嘗試是否有隱藏ID。
-
並發送禮物，抽獎
-
無限創建首次優惠訂單，有些首次優惠訂單是一個特殊的pid，這種的直接替換pid進行支付。有些是相同的ID，這種的提前創建訂單，記錄多個訂單號在依次修改訂單支付。
-
刷屏：發言刷屏，分享，點贊等有提示的地方刷屏
-
房間內可以申請的地方進行申請取消操作，看看是否能炸房。
-
越權踢人，增加管理員，關閉房間等操作。
-
發送的表情是否可以修改長寬（真實案例）
三、購物app
-
購買數量：為0，小數，負數，正負值（A為-1，B為2，總值為1）
-
代金卷：並發領取，遍歷領取，同一個代金卷重復使用，未滿足條件使用代金卷
-
越權：登陸，操作別人訂單，修改資料
四、外賣
-
商品數量，0，負數，小數，特定值，正負數（A為-1，B為2，總值為1）
-
送餐員評價修改，星級，打賞金額（小數，負數）
-
商品評價，星級，評論字數，上傳圖片是否可以自定義格式，
-
訂單超出送餐地址
-
強行貨到付款，取消訂單，退款
-
越權操作別人訂單，登陸
-
優惠購買會員（重復使用優惠購買）
五、交易平台
-
錢包並發提現，負數提現
-
使用錢包支付時多個訂單並發支付（是否支付金額能大於余額）
-
轉賬負數，並發轉賬
-
上架商品突破限制，例如數量，字數。
-
替換訂單，創建訂單號如果訂單狀態可修改，先進到支付界面，然后將訂單修改成更大的金額，然后支付提前進入的支付界面
-
數量修改
六、社交
強行舉報（讀取本地消息上傳那種）
強行加好友（一般嘗試重發通過好友這條協議）
自由修改號碼（靚號類）
群管理無限禁言
越權禁言，替人，拉黑
會員修改金額，數量。無限優惠購買
非會員使用會員功能
七、漫畫
-
打賞金額為負數，小數，特定值（溢出）
-
越權刪除評論，登陸
-
修改充值金額
-
付費漫畫免費看
-
評論圖片數量過多會導致客戶端加載卡死
八、音樂
唱歌類軟件修改上傳分數等參數
付費下載嘗試替換下載ID
修改付費下載金額
F12查看下是否有歌曲地址
九、網約車
-
無限叫車，重復發送協議造成市場混亂
-
修改評價分數
-
修改限時優惠叫車關鍵參數
-
替換優惠卷
-
越權操作其他訂單
京安小妹:業務邏輯漏洞的挖掘思路？
月神：
有時候你想到了一個奇葩邏輯，會通殺很多APP（我用了一個簡單的支付邏輯在4家SRC每個洞都訛到了高危）所以邏輯漏洞雖然看似簡單，如果奇葩也能通殺。我的挖掘思路就是拿到包后，先隨便測，從登陸，資料評論這些簡單的功能都過一遍，挖到低危不要緊，挖到了就是給自己建立了信心，沒白挖。
然后簡單功能過了一遍后，開始細扣每個功能例如支付這種容易出高危嚴重的地方可以先看一下，把自己積累的思路過一遍，比如先充幾塊錢，然后並發提現。或者充值5元后，用5塊錢並發支付多個5元的訂單，這個相比其他支付漏洞的出現率還是多一些的。最重要的是想別人想不到的，如果是小白，可以學習一些常見的思路，然后自己找些網站來測試，我給的建議就是別學太多，入門就行，剩下的自己在實踐中悟，這樣就不會被常識束縛住。不然挖邏輯漏洞時太容易就被已經掌握的常識所束縛了。
沒去嘗試過的東西永遠別說不可能，上學的時候微X剛出，資料只能改30個字，那時候我剛教我朋友使用手機上的內存修改器，我們平時沒事就找些網游刷一下，那天朋友突然和我說微X資料可以改內存把長度提升到100字。我第一反應是不可能，改了肯定沒用，是不是你剛學不會改看錯了。結果還真是能改。
從那以后我就告訴自己，別說不可能，沒啥不可能的，出問題了第一反應不是否認，而是站在對方的角度去想，怎么復現這個漏洞。以前在第三方平台做游戲防外掛，由於游戲是代理的，很多時候看不到玩家的數據。玩家出現作弊后，開發通知到我這邊，我這邊只能猜測漏洞如何出現，大多數都是用目前已經掌握的知識就能猜的八九不離十了。但是只有一次我印象最深，那時候剛出了一款游戲，XX農葯刷符文，大家都在玩，於是我也跟風玩了起來，然后在破解群出現了商人，代刷符文，聽到刷符文，第一反應就是負數溢出了，但是如何嘗試負溢出都不行（那個時候思路不是特別多，溢出只知道修改負數）機緣巧合下，那天我接觸到了正數溢出，在游戲里面通常最大數值就是2147483647，那么正溢出就是假如商品單價為2，那么我要做到的就是2*數量>2147483647，假如買1073741825個*2就是2147483650，在游戲中由於超出了最大值，總價格就會變成了3（超出后從0開始計算），於是去嘗試了一下，果然是這樣，經過計算后，成功刷到了符文箱。
所以一定要勇於嘗試，豐富各種各樣的奇葩思路
京安小妹:業務邏輯漏洞的案例分析
月神：
一、
先來講一個某外賣平台訂餐的軟件吧，我和朋友說我把這個軟件訂餐的數量改了，改成了負數結果成功了，然后他表示他嘗試過並沒有成功。同樣是負數為什么沒有成功呢？我一開始的思路也是將其修改為負數，在點幾個正數的保證達到送餐的數量。但是服務器有校驗，單個金額和總體金額不能為負數，你們想一下，這樣看起來就很完美了，於是我一直思考有沒有什么邏輯是被我疏忽掉的呢。想了半小時終於想出來了。參數大概是這樣的
{"total_price":"21.04","products":[{"cart_id":"0","product_id":"277976516634","product_quantity":1,"product_name":"芝麻糖餅","activity_num":1,"dish_activity":1,"cart_type":"cater"},{"cart_id":"0","product_id":"203689622554","product_quantity":2,"product_name":"鮮汁肉包(2個)"}]}
我們來看一下，其中有商品ID，單價，數量，活動優惠數量，總價，數量價格總價對不上都不讓下單，看起來環環相扣，於是我嘗試了將商品ID都改為同樣了，數量這里一個為正一個為負，也就是這樣的：
{"total_price":"XXX","products":[{"cart_id":"0","product_id":"277976516634","product_quantity":-1,"product_name":"芝麻醬糖餅","activity_num":1,"dish_activity":1,"cart_type":"cater"},{"cart_id":"0","product_id":"277976516634","product_quantity":2,"product_name":"鮮汁肉包(2個)"}]}
修改后用計算器來計算一下總體價格，公式大概是這樣的：總價=物品*-1+物品+優惠物品價格
算下來后下單成功了。繞過了服務器校驗的單個數量不可以為負數的邏輯。（商家收到的圖）
二、
在測試某款金融軟件時，看了很多功能，邏輯都很嚴謹，在處處碰壁即將要放棄的時候，尋思試一下錢包吧，雖然感覺不太可能，但是夢想得有，萬一實現了呢。於是提現時候試了一下負數~結果真的成功了。將下面參數中amount":"1"改為amount":"-1"
從圖片中可以看出，負負得正，於是提現后錢包就多了相應得金額，如果被非法分子利用的話就拿去買東西或者直接提現了~
reqData={"amount":"1","cardId":"5612912350382","withdrawFlag":"0"}&sid=4dacbde55cfe1bd8fff6a9f2cc72c9ew&source=app
四、
某社交平台刷會員，這個純是靠操作就能實現的一個邏輯漏洞了。在以前沒有工具（還不懂）的時候經常靠操作來測試邏輯漏洞，也可以說是卡BUG，大家都知道有些軟件推出了會員簽約功能，簽約付費就能以低價購買會員，這個漏洞是這樣的，我第一次測試時，使用支付寶打開簽約界面，然后使用微信在打簽約界面，在依次支付，支付后系統提示，無法重復簽約。我想難到系統有檢測，舍不得**套不到狼。於是申請個新號再次測試，還是支付寶和微信都打開了簽約界面，這次先簽約其中一個比如簽約微信，支付成功后，去微信取消簽約，然后在去支付寶點擊簽約，奇跡發生了，到賬了2個月的會員，也就是說服務器校驗了不能同時簽約，但是沒有校驗解約后再次簽約的情況。提交漏洞后，等待漏洞修復又想出個測試方法，還是購買會員選擇微信到簽約界面，但是不簽約，這時候換手機，登陸這個APP，再次打開微信簽約界面，如此重復，打開N個微信簽約界面后。簽約又成功了。因為都是微信可能屬於同類型的簽約沒有校驗。
五、
再來說一個某雲服務器刷代金卷。這個邏輯就比較簡單了，測試的時候我發現了這個網站正在搞活動，送代金卷，根據我玩游戲的經驗，程序總是喜歡在后台做一些隱藏的道具或者測試道具，只是屏蔽了前端。這時候我去領取代金卷時，用工具burp對ID進行遍歷。13000-14000，遍歷后發現居然領到了大金額無門檻的代金卷
領到了很多張這種無門檻的代金卷，我一看過期了，但是使用時候卻能選擇，並且成功使用購買的產品，於是我猜測應該是內部測試時程序給配置的吧，由於疏忽忘記加白名單所以誰都可以領取到了。
下面這個act_ids就是代金卷的組合。可以只保留一個然后進行遍歷操作。
action=getVoucher&data={"activity_id":11177,"preview":false,"act_ids":[12637,12638,12639]}
六、
最后講一個被忽略的漏洞吧，為啥被忽略呢，在下口才實在不行，辯不過審核小姐姐，某外賣軟件強行貨到付款，在測試某外賣軟件時，測試了很多點，發現還挺安全的，反正一些小的邏輯漏洞都沒有，於是在下單時看到了一個關鍵參數，這里面就不列舉了，不然就知道是哪個了，該參數的值為0，其他參數都是地址，坐標，名字，訂單號等信息，都能看懂是啥意思，唯獨這個0不知道是干嘛的，於是改成1下單試一下，下單后我還沒有支付就顯示了訂單成功，然后商家已接單，這個商家根本不支持貨到付款（為了不造成影響找朋友的門店來測試的）不一會兒，外賣小哥就來到了店里，然后告知小哥這個訂單是測試訂單。我這邊下單后可以直接點擊確認收貨，然后進行惡意差評。如果同行競爭的話利用這個漏洞簡直太可怕了。用網上虛假手機號來下單，會給競爭對手造成很大的損失。但是審核小姐姐說這樣做就違法了。我也不知道該說什么了，就這樣吧哈哈直到今天這個漏洞也沒修復。。。
京安小妹:業務邏輯漏洞的防御手段
月神：
站在攻擊者的角度看待問題，查找問題時先不去想如何防御，我是對破解的過程有特別的興趣，所以拿到程序時我先大概看一下程序的主要功能都有什么，然后迅速在腦中構思出一個破解思路和過程，然后開始着手破解，不停的嘗試，覺得差不多了就停止，等有了新思路在嘗試，也可以找一些朋友來幫忙測試一下，看一下有沒有漏掉的點，畢竟每個人的思路還是不同的，找到了所有點后整理個報告，在來想如何防御，漏洞修復后一定要嘗試其他思路是否能繼續繞過，我在某SRC提交刷會員的時候用了3種不同的思路來繞過了~