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

sen · January 01, 2018 · Last by sen replied at March 22, 2018 · Last modified by admin 思寒_seveniruby · 11477 hits

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

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

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

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

你画我猜

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

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字段,只要调用画信息接口就会返回所有信息,导致回答者能直接知道答案。
  • 加密:与钱相关的接口最好是加密处理,虽然一样可能被破解,还是可以起到一定的门槛作用的。
共收到 16 条回复 时间 点赞

大部分截图都浏览不了,建议修复一下

sen #2 · January 01, 2018 作者
张全蛋 回复

原来外网图片在手机上无法查看,现已调整

楼主分析的很棒 以前内部经验不足的开发就出过类似的问题。。一个不过期的签名走天下,很容易碰撞查出其他人的敏感数据

sen #4 · January 02, 2018 作者
纯稀饭 回复

看来很多公司有这类情况出现哈。

不错的文章,把你的硬广去掉了。交流就来社区吧。

sen #6 · January 02, 2018 作者

明白了

sen 资金的 bug 怎么测?怎么防资损? 中提及了此贴 04 Jan 21:25

赞赞赞!!

https怎么抓到包的?

sen #10 · January 11, 2018 作者

抓包工具,装证书,这没有什么特殊的吧。每个工具的设置方式不同,搜一下肯定有解决办法。

还有并发性能要测试

所以现在银行app是这么做的:检测网络,禁止有代理的环境下使用,防止中间人;不管用不用ssl,所有交互全部加密传输,就算请求一样,两次请求的加密包都不一样。

sen #13 · January 12, 2018 作者
在路上 回复

并发的在我另外一个帖子上有说到。

难道都没发现,图片很犀利么……

sen #15 · January 20, 2018 作者
张全蛋 回复

关注点果然不一样😂

受教了,让我对接口测试又有了新的认识。请问你这是抓包是抓的别人家线上环境的吗?还是你们自家的产品的测试环境?

sen #17 · March 22, 2018 作者
leunggz 回复

平时没事会直接调用别人家线上环境。

刘校 web 的安全测试是要如何做呢? 中提及了此贴 15 Jun 17:29
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up