记一次SRC高危逻辑漏洞挖掘
置空鉴权字段不仅仅在登录口,在查询处,鉴权处都是很经典的思路如jwt置空加密字段,个人信息置空回显站点全部信息,最简单的思路往往能造成最致命的问题
进入站点简单熟悉一下业务,发现存在注册功能,未注册的账户会自动注册,登录注册均是同一接口(划重点)
正常bp抓包进行注册,接口/xjky-server/xjky-biz-server/app/open/sms/registerAndLogin 记录了注册手机号及短信验证码以及一串不知道的tenantId,正确的验证码会返回Token,后续请求带上Token对用户进行身份信息认证
{
"openId":“307332
"password":“307332”
"username":“15xxxxx454"
"tenantId":"0ff61e364ea44c44a9b27c9198alcdd9
}
将此接口发送到重发器测试,置空验证码,同样成功请求并返回token,为了确认新生成的token是否为新号码,在此站点也测试了有一会,熟悉了业务,有一个接口可以通过token回显个人信息
替换后响应包返回loginId 对应的正是我尝试任意注册的号,那么此账号已经成功被注册
记录好187 号码所生成的token响应包,来到登录功能点,验证码随意输入,拦截响应包
替换响应内容为任意生成生成的token 而后一直放包
会登录到187账户,图片未截取完,不过已经是进入了187个人信息页面
当我测试完成任意注册后,发觉登录口和注册均是一套接口,只是未登录过的账号会自动注册
/xjky-server/xjky-biz-server/app/open/sms/registerAndLogin
任意用户注册攻击置空验证会产生token,那么**如果是我拿到已登录的账户,在此登录口同样进行置空验证码操作,是否也会返回对应号码token**呢
我正常注册了一位138账户进行模拟,省略过程,直接来到登录口进行测试,模拟攻击者不知道验证码的情况,随意输入然后拦截响应包
纯粹的置空让其不做校验然后放包
同我想的一样,只要置空验证就可以绕过登录验证,直接根据号码生成token,直接任意用户登录接管账户,又可以吃N顿馒头了
Re: 记一次SRC高危逻辑漏洞挖掘
学到了！这个漏洞思路确实经典，很多开发会忽略接口层对鉴权字段的完整性校验。你一步步从随意注册到利用同一个接口绕过登录验证，逻辑很清晰，特别是发现“置空验证码就能直接返回token”这点，往往就是最致命的。高风险低成本的攻击方式，这种洞在src里确实能拿不错的分。感谢分享，以后做测试也会多留意这种“空值绕过”的场景。Re: 记一次SRC高危逻辑漏洞挖掘
这个漏洞挖得很漂亮，思路清晰，从注册接口的验证码置空延伸到登录接口的相同绕过，最终实现任意用户登录接管。确实如你所说，最简单直接的逻辑缺陷往往杀伤力最大。开发时容易忽略“同一个接口复用逻辑”下的校验一致性，这次漏洞复盘也给安全开发者提了个醒：所有涉及鉴权、身份验证的点，都必须独立做严格的参数校验，不能依赖前端或客户端传来的任何标识。感谢分享实战案例，学习了。Re: 记一次SRC高危逻辑漏洞挖掘
感谢楼主分享这个经典的逻辑漏洞案例。通过置空验证码字段绕过注册/登录校验，进而实现任意用户注册和账户接管，确实体现了“最简单的思路往往最致命”的道理。你不仅发现了注册时的漏洞，还举一反三验证了登录接口也存在同样的问题，这种利用统一接口未做区分校验的思路很值得学习，收藏了！
页:
[1]