接口测试接口测试除了功能，还有安全

sen · 2018年01月01日 · 最后由逗爸比回复于 2020年11月12日 · 3367 次阅读

开发以为开发好了，测试以为测好了，然后钱还是被 “合理” 盗走了。

最近有各种拼手气红包小程序比较火，诸如包你答、包你拼、包你说等等。很多小程序都是匆匆上线，接口层面设计存在有很大的安全隐患问题，往往容易被人所利用刷红包，刷提现等资金问题。用户一旦发现资金被盗，那这个小程序基本是要废了。

下面根据实际案例，给大家讲讲我是怎么找到一个拼手气红包类小程序的漏洞的。当然，目的是为了学习，不是干坏事。如果你是测试，那你可以在你自家产品上测试是否类似漏洞，如果你是开发，可以查看下代码避免出现有类似漏洞的接口设计。

下面是一个你画我猜的小程序，发起方可以画一幅画，然后塞红包，分享给好友猜，猜中的人就可以获得拼手气红包。

你画我猜

↑↑好友通过分享进入↑↑

1、抢你红包没商量

第一步，抓包，通过抓包可以查看进入图画页所请求的接口返回数据：
https://api..cn/index.php/api/draw_guess/wechat/Query_group_draw_info?t=1514290355&v=afabde532d9a8a4969663fc52870ad54&user_id=U20171123062035992245&draw_group_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(答案)
，由于这个关键值的暴露，我们就可以轻而易举知道画里面的答案，然后就可以做到无论画了什么乱七八糟的东西，我都可以回答正确，顺利拿到红包，如啥都没画我就猜中了：

这个时候，再深入研究下就会发现，接口请求参数中有个关键的字段 draw_group_id（画 id），而且值是纯数字，自己尝试连续创作几幅画之后，发现这个字段的值是按 +1 规律增长的，那岂不是可以任意回答任何一篇画了？接着写了个脚本循环就会得出下面的情况：

热心的我把这个 bug 反馈给了开发者，开发者修复为：如果没有回答对，接口返回信息中的 answer 为空，所以你现在去试的话，会发现 answer 字段接口信息为空。

2、换个身份获取答案

很多人以为上面的 bug 已经修复了，其实这个 bug 是没有发现修干净的，怎么说呢？大家再深入想下，这幅图回答者不知道答案，总得有人是要有权限知道答案，在页面显示的吧？猜测是两类可能可能有权要知道，一类是已经回答正确的回答者，一类是画的创建者，显然从画的创建者权限入手找 bug 是比较合理的，毕竟一幅画一定有创建者，但不一定有正确回答者。

我们重新回到接口返回信息中寻找关键字段，会发现有个 ques_user_id ，可以断定这个就是创建者的用户 id，抱着试一试的心理，我将请求接口中的 user_id 的值更换为 ques_user_id 的值，结果发现，真的返回答案了。又可以继续刷红包了，表示很无奈呀。

https://api..cn/index.php/api/draw_guess/wechat/Query_group_draw_info?t=1514290355&v=afabde532d9a8a4969663fc52870ad54&user_id=U201709171243335621796&draw_group_id=2418599&page=1***

此时，再细细想一下，发现一个可怕的问题，这么说，这个小程序是完全没有身份态一说呀，一个 user_id 走天下，所以接下来我又做了进一步的尝试来证明我的想法，就是接下来要说的另外一个 bug。

3、转你钱没商量

这个小程序跟钱相关的地方还有个赞赏功能，就是你欣赏一幅画，可以对画的创建者进行打赏，优先使用存在小程序上的余额（免密）。这个时候我尝试了一下查询余额接口，居然没有做任何限制可以查询，尝试了赞赏接口发现只需要转账人 id、接收者 id、赞赏金额，三个关键参数就可以直接转账了，重点的是 user_id 也是有规律有序的，我尝试遍历了一下其他人账户余额：

查余额

当然，我遍历只是查询余额而已，没有真正把其他账号的钱转到个人账号上，毕竟这对这个小程序的生态破坏太厉害了，不是 bug 这么简单了，我是通过把自己的赞赏其他用户的形式来验证自己的想法的：

事实证明，真的可以直接转！！！非常热心的我再次向开发者反馈这个问题之后，开发者默默的修复了这个问题，加上了身份态校验，也就是请求参数中的 t、v 这两个参数，其实这两个参数一开始就有的，我也不知道为什么一开始没有生效，难道遗漏了？

总结

身份态缺失：没有身份态，直接使用 user_id 来进行判断身份的实在是少见。其实小程序中，微信提供的 token 的很好用的一个东西，不知道为什么很多开发者不愿意使用。
不该知道别知道：其实就是接口数据不要返回不该返回的信息，一开始设计时接口设计没有关心权限问题。例如上面大 answer 字段，只要调用画信息接口就会返回所有信息，导致回答者能直接知道答案。
加密：与钱相关的接口最好是加密处理，虽然一样可能被破解，还是可以起到一定的门槛作用的。

47 个赞

共收到 17 条回复时间点赞