有时候，乙方不能感受甲方的痛；

有的漏洞，乙方不会碰到甲方的场景；

不是因为技术不够强，只是由于缺少对业务足够深入的理解。

在漏洞回归的时候，也会发现新的隐患；

一条短短的验证码，可能酿成一场事故；

业务安全之另类隐患，希望和大家分享鲜有人说的点点滴滴。

1、系统登录处暴力破解

1.1 回归验证

某业务系统在修复安全问题，并进行部分功能调整后进行安全提测，内容如下：

接收到提测邮件后，安全测试人员首先对已知漏洞在测试环境进行验证。使用burp对登录接口进行枚举验证：

当发现可枚举问题还未修复完善时，立即停止了爆破并打回相关漏洞。

1.2 短信炸弹 

一切都是常规操作，不过不久之后，有不少用户反馈收到上述业务系统发出的短信验证码。不幸的是正好命中一位公司高管，据其描述最近总收到测试环境的验证码且有多条，一声令下要求追溯发信源头，并将收到短信验证码一事定级为安全事故。由此，信息安全组便成了肇事者，身背故障分。

1.3 事故分析

登录接口设计存在缺陷：

输入用户名和密码，若验证成功则对该用户发送短信验证码

测试环境使用生产数据：

为了方便测试，开发将其他数据库的真实手机号等信息同步至相关测试数据库，导致大量真实用户收到测试环境短信验证码

 提测缺失重大变更信息：

开发未同步用户的密码，系统新增的同步用户统一被设置初始弱密码，且登录接口有重大变更，未在提测信息汇总进行描述

1.4 经验教训

从安全的角度出发，在此次事件有点冤。但事已至此，吃一堑需要长一智，在痛苦的经历中学习提高，关于对业务可能造成高风险危害的操作尽量少做或不做：

漏洞扫描、漏洞利用等高危操作，尽量做到事先告知业务方

安全测试前先评估影响范围，尽量确保对业务和用户无影响

安全测试时尽可能主动了解业务形态及功能变更等多种情况

2、密码找回处暗藏危机

2.1 缺陷挖掘

某系统在密码找回处，可以通过工号或手机号进行找回。

当输入存在的工号或已注册手机号时，response返回手机号：

当输入存在的工号或已注册手机号时，系统自动发送四位数字短信验证码：

看到这里，很多人都会想到任意用户密码重置漏洞的场景：

通过第一步可以枚举出已经注册的用户，

从第二步获知纯数字的四位验证码很容易爆破，

此时还需要看看该接口是否可以枚举：

虽然用户名和密码加密，但该接口还是可以进行枚举。使用一些小技巧不难加密用户名和密码，所以该系统此处功能存在严重漏洞，且已经有利用成功的案例：

2.2 漏洞修复

面对有图有真相的任意用户密码重置漏洞，开发立即响应进入漏洞修复阶段，对用户名密码验证频率和次数进行了限制，降低了漏洞带来的风险。

2.3 暗藏危机

在回归验证时，原漏洞在和产品的沟通下，算是基本修复。

然而事情往往没这么简单，静下心来分析发现了更加隐蔽的安全隐患：

可发短信至任意用户(包括领导)，同上一个场景一样，又是只有甲方才能深刻体会到的风险。

2.4 深刻体悟

业务方面的安全隐患，可能不仅仅是由于业务逻辑造成，其他不规范的操作也起到一定的助攻成分。

业务相关的漏洞修复，推动改起来甚至比web漏洞更加难，因为产品要考虑友好度和便捷性。不过也可以找到其他次之的修复方案，在安全和业务之间找到平衡点，让安全真正的为业务保驾护航。

原文发布于微信公众号 – 我的安全视界观（CANI_Security）