今天遇到了两个非常典型的互联网运营平台安全风险问题，很具有代表性，虽然没有直接带来损失，或多或少也会给用户带来不好的安全体验。通过针对性的紧急修复，算是在这场攻守之战中，速战速决，可谓魔高一丈，道高一尽！
Case 1：接口中暴露了用户帐号信息，恶意用户扫描爬取帐号
有的时候，程序员写的接口会返回丰富的数据，有用的，没有用的，都带上。今天这个Case就是这种很常见的现象，带上了帐号信息，而实际上又没有使用到。导致有网友通过接口爬取信息，还将工具晒到了网上。
处理解决：
- 通过抓包分析工具wireshark分析被爬取的接口，大概有3个不同的URL，查代码对应到内部一个处理逻辑。
- 将返回结果过滤掉帐号信息再返回
事后点评：一段代码一段逻辑都有自己的生命周期，在早期的时候，更注重有没有，能不能满足基本的业务需求。随着业务的发展，考虑的问题越来越细致，有的不是问题的问题也就都出来了。也不能因此就提心吊胆的写代码，大概更新一下准则，有个可执行的标准即可。能防范于未然，那是更好不过。
Case 2:短信验证位数问题
有的时候想体验更亲民，短信验证码设置成4位数字，验证不卡次数，有效期一分钟。在这种验证逻辑下，暴力破解很容易就穷举完验证码，安全风险算是比较大。大多数平台选择6位数字验证码，也有别的平台字母加数字，选用7位的，8位的平台也有，不多！平安银行就是不走寻常路。短信验证码是一个很常见的功能，感觉设置成6位，卡一下验证次数会比较好。
今天最大的收获在于使用wireshark分析了http请求，又收获一个强大的工具。虽然用得不专业，但是对于这种简单的抓包分析，在工具上起到了非常重要的作用！