实战|任意用户漏洞挖掘分享

mingzhi61

于 2024-09-02 13:02:42 发布

阅读量354

点赞数 20

文章标签：网络网络安全面试

本文链接：https://blog.csdn.net/liguangyao213/article/details/141817090

版权

吉祥知识星球http://mp.weixin.qq.com/s?__biz=MzkwNjY1Mzc0Nw==&mid=2247485367&idx=1&sn=837891059c360ad60db7e9ac980a3321&chksm=c0e47eebf793f7fdb8fcd7eed8ce29160cf79ba303b59858ba3a6660c6dac536774afb2a6330&scene=21#wechat_redirect

《网安面试指南》http://mp.weixin.qq.com/s?__biz=MzkwNjY1Mzc0Nw==&mid=2247484339&idx=1&sn=356300f169de74e7a778b04bfbbbd0ab&chksm=c0e47aeff793f3f9a5f7abcfa57695e8944e52bca2de2c7a3eb1aecb3c1e6b9cb6abe509d51f&scene=21#wechat_redirect

《Java代码审计》http://mp.weixin.qq.com/s?__biz=MzkwNjY1Mzc0Nw==&mid=2247484219&idx=1&sn=73564e316a4c9794019f15dd6b3ba9f6&chksm=c0e47a67f793f371e9f6a4fbc06e7929cb1480b7320fae34c32563307df3a28aca49d1a4addd&scene=21#wechat_redirect

《Web安全》http://mp.weixin.qq.com/s?__biz=MzkwNjY1Mzc0Nw==&mid=2247484238&idx=1&sn=ca66551c31e37b8d726f151265fc9211&chksm=c0e47a12f793f3049fefde6e9ebe9ec4e2c7626b8594511bd314783719c216bd9929962a71e6&scene=21#wechat_redirect

《应急响应》http://mp.weixin.qq.com/s?__biz=MzkwNjY1Mzc0Nw==&mid=2247484262&idx=1&sn=8500d284ffa923638199071032877536&chksm=c0e47a3af793f32c1c20dcb55c28942b59cbae12ce7169c63d6229d66238fb39a8094a2c13a1&scene=21#wechat_redirect

《护网资料库》http://mp.weixin.qq.com/s?__biz=MzkwNjY1Mzc0Nw==&mid=2247484307&idx=1&sn=9e8e24e703e877301d43fcef94e36d0e&chksm=c0e47acff793f3d9a868af859fae561999930ebbe01fcea8a1a5eb99fe84d54655c4e661be53&scene=21#wechat_redirect

登录框checklist

遇到登录框必检查的checklist:

用户枚举：未统一返回内容
弱口令：通过信息收集暴力破解
空口令：将密码置空发送数据包
登录认证绕过：通过fuzz找特殊接口
暴力破解风险：网站无验证码，或不设置页面重定向跳转且密码为明文或弱加密
验证码复用：验证码不失效
测试数据：特殊手机号（13333333333...）及验证码（000000-999999）
验证码绕过：修改登录的返回包等
短信验证码可暴力破解
短信验证码可预测
短信炸弹
恶意锁定问题
账号密码明文传输
SQL注入：万能密码等
SSO认证缺陷：越权登录他人账号
任意用户漏洞
……

总之就是存在登录框的地方，什么漏洞都是可能存在的，这也是在面试当中经常会被问到的。今天的案例是与任意用户相关的，着重点就放在任意用户登录上。

案例1：用户枚举演变任意用户

初探

这是一个工作时的APP目标，打开APP后，但大致功能如下（图文无关）

最开始是最原始的用户枚举，选择账号登录，输入任意账号密码，如果账号存在会返回密码错误，账号不存在则返回其他内容

后面想测试登录处有无短信炸弹、暴力破解等漏洞，这里的手机号参数是经过DES加密的，通过反编译安装包，成功拿到秘钥

尝试了在手机参数中加入空格，+点等特殊符号，都是不能通过后端对手机号格式的验证

第一个周就这样浅浅的水一下，交了一个用户枚举

再探

又是朴实无华的一个周，依旧来到了登录框处进行对抗经过一番尝试，在登录的手机号处添加了一个空格加密再进行DES加密后得到最终发送的参数，发送数据包，登录成功！！！

但是我心中还是有疑问的，为啥上周这个方法都还不行，这周用同样的方法就登录成功了，也和其他同事讨论了一下出现该问题的原因，因为之前他们用同样的方法是无法登录的

缘由

为什么在第一周测试的时候该方法无法任意用户登录的，第二周就能登录原因？通过和开发沟通，大致得知了原因，不过师傅们也可以先脑补下是因为什么原因，修复用户枚举后的部分代码如下：（已脱敏简化）

@RequestMapping(value = "/login.ajax")
@ResponseBody
@InterfaceLogAnno("/user/login.ajax")
public JsonIndivUserLoginResp login(HttpServletRequest request, HttpServletResponse response) {
 ……
 //密码登录
 if (!StringUtils.isEmpty(mobilePhone) && StringUtil.isMobileNo(mobilePhone) && !StringUtils.isEmpty(password)) {
  
  //密码登陆逻辑判断 这部分代码没什么问题
  ……
 ｝
 
 //验证码登录
 if (!StringUtils.isEmpty(mobilePhone) && StringUtil.isMobileNo(mobilePhone) &&
    !StringUtils.isEmpty(verifyCode) && verifyCode.length() == CODE_LENGTH) {
  //验证码登录逻辑判断 这部分代码没什么问题
  ……
 ｝
 
 /**
  * 登录就给最新的token
  */
 newToken = createToken(mobilePhone, deviceID, queryResult, token);
}

应该有代码基础的师傅，看见这部分代码，就能看出问题所在了，不管是密码登录还是验证码登录都需要if语句里面的条件都为真才会走到对应的逻辑进行判断，但当我们请求的手机号参数不符合规范时，StringUtil.isMobileNo(mobilePhone)返回的是false，即不会走密码登录和验证码登录的逻辑就直接来到了获取token的地方

最后的修复是在代码开始的部分判断了手机号格式，不符合就进行返回

@RequestMapping(value = "/login.ajax")
@ResponseBody
@InterfaceLogAnno("/user/login.ajax")
public JsonIndivUserLoginResp login(HttpServletRequest request, HttpServletResponse response) {
 //校验注册信息-用户名和密码格式校验
 if (StringUtils.isEmpty(mobilePhone) || !StringUtil.isMobileNo(mobilePhone)) {
  logger.info("------------------手机号无效----------------------");
  return new JsonIndivUserRegisterResp(Constant.JSON_HTTP_USER_PWD_STATUS_FAILED, "用户名或密码错误！");
 }
 ……
}

这种方式还是不够优雅，不过就开发“能跑就行”的原则来说，这样就够了