魔高一丈 道高一尽 帐号泄漏攻守之战 多传的Account 为友商提供了天然信息 早发现早处理 保护用户隐私 构建强有力安全环境

今天遇到了两个非常典型的互联网运营平台安全风险问题,很具有代表性,虽然没有直接带来损失,或多或少也会给用户带来不好的安全体验。通过针对性的紧急修复,算是在这场攻守之战中,速战速决,可谓魔高一丈,道高一尽!

Case 1:接口中暴露了用户帐号信息,恶意用户扫描爬取帐号

有的时候,程序员写的接口会返回丰富的数据,有用的,没有用的,都带上。今天这个Case就是这种很常见的现象,带上了帐号信息,而实际上又没有使用到。导致有网友通过接口爬取信息,还将工具晒到了网上。

处理解决:

  1. 通过抓包分析工具wireshark分析被爬取的接口,大概有3个不同的URL,查代码对应到内部一个处理逻辑。
  2. 将返回结果过滤掉帐号信息再返回

事后点评:一段代码一段逻辑都有自己的生命周期,在早期的时候,更注重有没有,能不能满足基本的业务需求。随着业务的发展,考虑的问题越来越细致,有的不是问题的问题也就都出来了。也不能因此就提心吊胆的写代码,大概更新一下准则,有个可执行的标准即可。能防范于未然,那是更好不过。

Case 2:短信验证位数问题

有的时候想体验更亲民,短信验证码设置成4位数字,验证不卡次数,有效期一分钟。在这种验证逻辑下,暴力破解很容易就穷举完验证码,安全风险算是比较大。大多数平台选择6位数字验证码,也有别的平台字母加数字,选用7位的,8位的平台也有,不多!平安银行就是不走寻常路。短信验证码是一个很常见的功能,感觉设置成6位,卡一下验证次数会比较好。

今天最大的收获在于使用wireshark分析了http请求,又收获一个强大的工具。虽然用得不专业,但是对于这种简单的抓包分析,在工具上起到了非常重要的作用!

此条目发表在未分类分类目录。将固定链接加入收藏夹。

发表评论

邮箱地址不会被公开。 必填项已用*标注