浅谈渗透江湖之细水柔情

以下文章来源于酒仙桥六号部队 ，作者队员编号020

这是 酒仙桥六号部队 的第 19 篇文章。

全文共计4030个字，预计阅读时长12分钟。

1、前言

在渗透测试的江湖里，不只有getshell后在刀光剑影的内网中拿下域控的快意恩仇，更有侧重于业务逻辑的细水柔情。业务安全需要去细腻的考虑方方面面，更偏向于逻辑漏洞的一个思路挖掘。

在接到一个待测试目标站点后，不只要对常规漏洞的点去进行渗透测试，还要对各个功能模块所可能存在的逻辑漏洞进行挖掘。文件上传等多种方式getshell固然可以对站点一剑封喉，但一些严重敏感信息泄露、逻辑设计缺陷跟流程缺陷，虽然细腻不易察觉，却同样招招致命。

2、通用业务逻辑漏洞模块

通用业务逻辑漏洞模块，是各行业共性的业务逻辑安全风险点，在每次的测试过程中也是最常见到的模块，也是测试的重点对象，所以网上介绍此类逻辑漏洞的文章很多，在这里再做下简单的思路点总结：

1.注册模块

•恶意用户批量注册。

•用户登录账号、id、昵称身份覆盖。

2.登录认证模块

•密码爆破。

•空密码登录。

•登录越权：修改登录请求返回包中的用户id等。

3.找回密码(修改密码)模块

•前端js校验绕过。

•邮箱重置密码链接弱token遍历。

4.验证码模块(图形、滑块、手机、邮箱)

•验证码前端js绕过。

•验证码空参数或删除验证码绕过。

•图形验证码长宽DDOS。

•验证码单一用户无限制发送。

•验证码重复使用。

•验证码低位数爆破。

•验证码回传泄露。

•验证码越权接收。

•验证码重复发送同一值。

5.支付交易(充值、提现、抽奖、优惠券、会员)等多个模块

•金额、数量负值/小数。

•总金额=商品金额+优惠券金额（只校验订单总金额，而不单独校验优惠券金额跟商品金额，可增大优惠券金额）。

•订单参数混淆干扰（在同一个订单内提交两个或多个金额参数，如price=1&price=-1）。

•校验商品总数量不能为负数，而不校验单个数量，可以设置两个商品一个数量为-1，一个数量为2。

•越权使用他人优惠券。

•首充优惠、升级会员等，多台设备同一账号同时进入支付宝微信第三方支付页面，此时签名订单已生成，支付时不会变成其他金额，可依次以优惠价格支付订单。

•小数点精度：0.019=0.02（比如充值0.019元，第三方支付截取到分也就是0.01元，但是系统四舍五入为0.02）。

•int型溢出（超过最大值整数溢出）遍历优惠券id，有可能遍历出测试隐藏的无条件大额优惠券。

•首充、提现、抽奖、领取优惠券等并发：不一定非要用同一个数据包去进行多次并发操作，可用bp等工具拦截客户端数据包，快速多次点击相应客户端按钮，然后停止拦截，并发请求。

3、专项业务逻辑漏洞模块

由于业务逻辑漏洞更侧重的是思路，再加上师傅们超脱银河系的脑洞，各行各业的业务逻辑漏洞被挖掘的越来越多。接下来以我自身案例以及网上分享的逻辑漏洞思路点，给大家汇总一下不同行业所特有的逻辑漏洞风险点：

1.直播

•快速进出房间炸房。

•无限发送点赞协议。

•修改礼物数量，0，小数，负数，特定值（一般情况下为1073741824）。

•修改礼物ID，遍历尝试是否有隐藏ID。

•并发送礼物，抽奖。

•无限创建首次优惠订单，有些首次优惠订单是一个特殊的pid，这种的直接替换pid进行支付。有些是相同的ID，这种的提前创建订单，记录多个订单号在依次修改订单支付。

•刷屏：发言刷屏，分享，点赞等有提示的地方刷屏房间内可以申请的地方进行申请取消操作，看看是否能炸房。

•越权踢人，增加管理员，关闭房间等操作。

•发送的表情是否可以修改长宽（真实案例）。

•加密直播尝试删除页面锁定弹窗对应div标签。

2.外卖

•商品数量，0，负数，小数，特定值，正负数（A为-1，B为2，总值为1）。

•送餐员评价修改，星级，打赏金额（小数，负数）。

•订单商品评价，星级，评论字数，上传图片是否可以自定义格式。

•订单超出送餐地址。

•强行货到付款，取消订单，退款。

•越权操作别人订单，登录。

•优惠购买会员（重复使用优惠购买）。

3.社交论坛

•强行举报（读取本地消息上传那种）。

•强行加好友（一般尝试重发通过好友这条协议）。

•自由修改号码（靓号类）。

•群管理无限禁言越权禁言，踢人，拉黑。

•会员修改金额，数量，无限优惠购买。

•非会员使用会员功能。

4.购物

•购买数量：为0，小数，负数，正负值（A为-1，B为2，总值为1）。

•代金券：并发领取，遍历领取。

•同一个代金券重复使用。

•未满足条件使用代金券。

5.读书/漫画

•打赏金额为负数，小数，特定值（溢出）。

•越权删除评论，登录。

•修改充值金额。

•付费漫画免费看。

•评论图片数量过多会导致客户端加载卡死。

6.音乐

•唱歌类软件修改上传分数等参数。

•付费下载尝试替换下载ID。

•修改付费下载金额。

•F12查看下是否有歌曲地址。

7.网约车

•无限叫车，重复发送协议造成市场混乱。

•修改评价分数。

•修改限时优惠叫车关键参数。

•越权操作其他订单。

8.交易平台

•钱包并发提现，负数提现。

•使用钱包支付时多个订单并发支付（是否支付金额能大于余额）。

•转账负数，并发转账。

•上架商品突破限制，例如数量，字数。

•替换订单，创建订单号如果订单状态可修改，先进到支付界面，然后将订单修改成更大的金额，然后支付提前进入的支付界面。

•数量修改。

9.快递

•根据距离计算金额时选择近距离，在最终生成订单时进行收货地址修改。

•订单重量修改。

•无验证码限制无限发送上门取件订单。

•快递员评价分数刷分。

•订单遍历。

10.教育

•免费领取课程遍历id/替换收费课程id。

•试看课程抓包查看详情是否返回所有课程链接（会员视频课程同理，会员到期仍可观看或会员权限下可看到专享课程视频链接）。

•自助模拟考试多次重复答题刷分。

•顺序缺陷绕过支付获取课程链接。

•教师端篡改课时提前结取薪酬。

4、案例分享

现在越来越多的站都采用前后端分离，尤其是微信公众号、小程序这种，很多都是采用纯接口json格式来传递参数信息，但这种纯接口传递参数对于一些像商城、论坛这种数据多，用户交互密切，也很容易传递多余不必要的敏感参数，发生信息泄露。比如查看某个活动排名，在页面只显示用户脱敏的姓名以及手机号等，但抓包查看接口时，却发现此接口返回数据是脱敏前的敏感数据，有些夸张的甚至会返回用户的密码等。基于这种思路，给大家分享两个小小案例。

1.身为一名正义的白帽子，我时常活（qian）跃（fu）在多个行业的业务群里，积极交（shou）流（ji）着上线的最新活动跟业务。而第一个案例，就来源于某个时间某个群内偶然的一条短信。 真实短信来源于某快递公司。

短链接服务是该公司在短信中最新推出的业务，而看到四位数的短链接，相信大家可能跟我一样，最先想到的便是去遍历穷举短链接地址，看是否可以遍历出多个用户的收货信息。

但当我输入链接查看的时候，发现需要手机号二次认证，想法是美好的，现实却总是残酷的。

后续查看webpack的router路由时发现一处留言反馈页面。

访问此链接时发现存在接口敏感信息泄露，每个问题反馈都泄露了相应用户的收货信息，包括收货手机号、收货码、收货短链接等。

但可能因为业务刚开通，留言反馈条数并不是很多，此时泄露用户数据有限，后续测试发现在留言反馈处存在一处图片上传点，找不到逻辑漏洞，要是能挖到一处上传也是很香的。

尝试任意文件上传后发现服务器对上传文件强制重命名为.jpg格式，查看路径发现被上传至存储服务器，也无法解析脚本文件，任意文件上传失败。

再次经历现实的毒打果然让我清醒了许多，仔细查看发现在上传处有一个smsId参数。

当对此参数进行修改时，发现在服务端会直接根据此smsId获取用户的源手机号（即收货手机号）、取货码、短链接并写入同一个问题反馈详情中。

当通过上传点修改遍历此smsId参数，再结合之前的接口敏感信息泄露，即可获取所有用户收货手机号及取货码等信息，极大危害用户的财产安全。

2.第二个案例来源于微信公众号，在测试微信公众号时，相信大家对openid并不陌生，openid是用户在当前公众号下的唯一标识（‘身份证’），就是说通过这个openid，就能区分在这个公众号下具体是哪个用户，若是公众号服务端只根据openid来进行用户的身份校验，则类似于会话固定，因为用户授权给微信公众号，openid是固定不变的，一旦泄露，就意味着用户的所有信息及操作可被盗用。在测试某公众号商城时，又是不经意间发现每个商品的用户评价处，返回的用户头像地址中，存在以微信的openid命名的图片名称。

在后续的测试中发现，服务端根据fxwxopenid与fxuserid来识别用户，但fxwxopenid与fxuserid必须一一对应时才可进行用户相应操作。如下接口查看用户个人信息时，服务端会从session中获取当前用户的fxwxopenid与fxuserid值并赋值给要查询的参数，并对用户这两个参数的一致性进行校验，当校验成功后才会执行查询，若不一致则会提示用户参数错误：

当不一致时提示用户参数错误：

由于商品评价处泄露的用户的openid，现在只需要知道用户的userid值即可完全代替用户进行任意操作，虽然可以通过爆破用户的userid去跟openid一一对应，但是userid值巨大，爆破难度很高。

在fuzz大法尝试获取用户名接口也未能奏效后，场面一度陷入僵局，我甚至想到了放弃来掩饰菜的尴尬。

正当我准备退出登录时，看见了联系客服按钮，想到在客户获取会话时，一般会获取当前用户的id或用户名信息，点击后果然看到了一处可以根据userid来查询用户昵称的接口，这可能就是传说中的皂滑弄人吧。

因为在商品评价处，用户昵称也会进行展示，所以只需要进行遍历用户的id来查询用户昵称并保存下来，通过用户昵称将userid值与openid值关联起来，就可以获得用户的身份令牌为了验证漏洞存在，写了个小脚本遍历了一小部分用户名跟id值。

最后只筛选了三个用户的openid跟用户userid以及昵称作为确认漏洞存在，而当把用户名称全部遍历出来，再与商品评价处的用户userid以及openid一一对应，便可获取大量用户的身份令牌。

5、总结

本文更多的是针对于业务逻辑测试点的一些思维分享，不能局限束缚在这些测试点中。熟悉相应系统业务流程，虽然会花费一定时间，但磨刀不误砍柴工，业务逻辑方面的漏洞最重要的是在熟悉业务流程的基础上，发散思维，能够比开发多想一层，那漏洞便会离你更近一分。

一名优秀的渗透测试工程师，既要武能漫游内网拿域控，又可以文能熟悉业务找逻辑。文武兼备，刚柔并济，祝大家早日笑傲江湖。