可以刷紅包，可以直接將他人錢轉到自己賬號上算不？下文正選在公眾號【測試有話說】。
開發以為開發好了，測試以為測好了，然後錢還是被「合理」盜走了。最近有各種拼手氣紅包小程式比較火，諸如包你答、包你拼、包你說等等。很多小程式都是匆匆上線，介面層面設計存在有很大的安全隱患問題，往往容易被人所利用刷紅包，刷提現等資金問題。使用者一旦發現資金被盜，那這個小程式基本是要廢了。
下面根據實際案例，給大家講講我是怎麽找到一個拼手氣紅包類小程式的漏洞的。當然，目的是為了學習，不是幹壞事。如果你是測試，那你可以在你自家產品上測試是否類似漏洞，如果你是開發，可以檢視下程式碼避免出現有類似漏洞的介面設計。
下面是一個你畫我猜的小程式，發起方可以畫一幅畫，然後塞紅包，分享給好友猜，猜中的人就可以獲得拼手氣紅包。
↑↑好友透過分享進入↑↑
1、搶你紅包沒商量
第一步，抓包，透過抓包可以檢視進入圖畫頁所請求的介面返回數據：
https://
api
.*.cn/index.php/api/drawguess/wechat/Querygroupdrawinfo?t=1514290355&v=afabde532d9a8a4969663fc52870ad54&userid=U20171123062035992245&drawgroup_id=2418599&page=1
{
"c": "0",
"m": "",
"d": {
"is_redpack": "0",
"ques_id": "997",
"draw_url": "https://..",
"img_url": "https://..",
"ques_user_id": "U201709171243335621796",
"draw_group_id": 2418599,
"prompt": "2\u4e2a\u5b57\uff0c\u4e50\u5668",
"ques_user_avatar": "https://..",
"ques_user_nickname": "\u854eKkkkkk",
"num_up": 0,
"num_down": 0,
"right_cot": 35,
"all_cot": 36,
"num_page": "1",
"num_reward": "0",
"is_sub_anwer": 0,
"anwer": "鋼琴",
"is_up": 0,
"is_down": 0,
"group_info": [{
"user_id": "U2017122611464418462",
"anwer": "\u731c\u5bf9\u4e86",
"avatar": "https://..",
"t": "20\u5206\u949f\u524d",
"nickname": "xuan \u00b7 dog",
"redpack_get": "0",
"redpack_money": "0",
"correct": "1"
}],
"redpack_money": "0",
"redpack_num": "0",
"redpack_num_send": "0",
"redpack_type": "0",
"rand_recommend": "3798417",
"act": "",
"pk_info": "",
"pk_id": ""
}
}
註：返回數據中的"group_info"值以及圖片地址是簡化處理過的。
從返回數據中結合頁面資訊，很多欄位都可以大概猜測是什麽意思，如：answer(答案)
，由於這個關鍵值的暴露，我們就可以輕而易舉知道畫裏面的答案，然後就可以做到無論畫了什麽亂七八糟的東西，我都可以回答正確，順利拿到紅包，如啥都沒畫我就猜中了：
這個時候，再深入研究下就會發現，介面請求參數中有個關鍵的欄位 drawgroupid（畫id），而且值是純數碼，自己嘗試連續創作幾幅畫之後，發現這個欄位的值是按+1規律增長的，那豈不是可以任意回答任何一篇畫了？接著寫了個指令碼迴圈就會得出下面的情況：
熱心的我把這個bug反饋給了開發者，開發者修復為：如果沒有回答對，介面返回資訊中的 answer 為空，所以你現在去試的話，會發現 answer 欄位介面資訊為空。
2、換個身份獲取答案
很多人以為上面的bug已經修復了，其實這個bug是沒有發現修幹凈的，怎麽說呢？大家再深入想下，這幅圖回答者不知道答案，總得有人是要有許可權知道答案，在頁面顯示的吧？猜測是兩類可能可能有權要知道，一類是已經回答正確的回答者，一類是畫的建立者，顯然從畫的建立者許可權入手找bug是比較合理的，畢竟一幅畫一定有建立者，但不一定有正確回答者。
我們重新回到介面返回資訊中尋找關鍵欄位，會發現有個 quesuserid ，可以斷定這個就是建立者的使用者id，抱著試一試的心理，我將請求介面中的userid的值更換為quesuser_id的值，結果發現，真的返回答案了。又可以繼續刷紅包了，表示很無奈呀。
https:// api .*.cn/index.php/api/drawguess/wechat/Querygroupdrawinfo?t=1514290355&v=afabde532d9a8a4969663fc52870ad54&userid=U201709171243335621796&drawgroup_id=2418599&page=1
此時，再細細想一下，發現一個可怕的問題，這麽說，這個小程式是完全沒有身份態一說呀，一個user_id走天下，所以接下來我又做了進一步的嘗試來證明我的想法，就是接下來要說的另外一個bug。
3、轉你錢沒商量
這個小程式跟錢相關的地方還有個贊賞功能，就是你欣賞一幅畫，可以對畫的建立者進行打賞，優先使用存在小程式上的余額（免密）。這個時候我嘗試了一下查詢余額介面，居然沒有做任何限制可以查詢，嘗試了贊賞介面發現只需要轉賬人id、接收者id、贊賞金額，三個關鍵參數就可以直接轉賬了，重點的是user_id也是有規律有序的，我嘗試遍歷了一下其他人賬戶余額：
當然，我遍歷只是查詢余額而已，沒有真正把其他賬號的錢轉到個人賬號上，畢竟這對這個小程式的生態破壞太厲害了，不是bug這麽簡單了，我是透過把自己的贊賞其他使用者的形式來驗證自己的想法的：
事實證明，真的可以直接轉！！！非常熱心的我再次向開發者反饋這個問題之後，開發者默默的修復了這個問題，加上了身份態校驗，也就是請求參數中的 t、v 這兩個參數，其實這兩個參數一開始就有的，我也不知道為什麽一開始沒有生效，難道遺漏了？
總結
後話
提現、充值與前相關的介面設計也有一些常見的安全漏洞，下期關鍵字「並行」，關註【測試有話說】，下次再來說。
