批量注册&用户名枚举

从下图我们可以发现，输入的手机号已经被注册过了，说明该网站是不允许单手机号注册多个用户的。

这里抓包可以发现，其实是异步发送了一个包进行验证，通过对/checkPhone.htm请求，来验证我们输入的手机号是否存在，这样我们可以利用这里得接口进行用户名枚举。

但其实这里只要把这个包的电话号码随便修改一下，然后发送验证码，只要验证码为之前发送的，其他信息可以随便修改达到任意用户注册，当然还有一层就是他发送的是四位验证码，所以在某些场景下，写一个脚本，发送真实的手机号，然后爆破验证也可以实现抢注。关于验证码的问题在后面的测试也有缺陷。

短信登录弱验证码

关于弱验证码的问题，在上面其实已经说过，就是这里，在我们输入已经注册过的手机号进行测试，发送验证码，发现是四位的验证码，那么我们可以生成一个0000-9999的数字字典进行爆破。

然后抓包尝试爆破，当然这里没有校验输入次数，如果进行了校验其实这里的漏洞是可以避免的，所以该处的修复意见通常就是使用字母+数字结合的验证码并进行输入次数限制。

可以看到已经得到验证码了，再返回界面发现已经成功登录了。

短信轰炸

对于短信轰炸其实说有危害也有，说没有也没有，但是通常在做授权工作渗透测试时，不只是去拿权限，更多的是对系统整体安全的评估，哪怕是一个验证码失效也是需要记录下来的。该处其实利用很简单，对于验证码发送的时间限制仅仅只是前端，所以通过抓包重放即可无限制发送验证码且手机号码随意，这样如果被利用可导致无限制消耗短信资源。

这里没啥可说的了，看图就好。

任意订单金额修改

这个漏洞就比较像样子了，对于一个商城系统来讲其实危害还是挺大的，就像是之前的肯德基门事件一样，但是很有意思的是，如果我们跟之前讲到的注册处验证码爆破实现匿名注册，那么是不是就可以薅羊毛了？嘿嘿，这种想法还是不能有的。

上图是一个正常的下订单的界面，此时我们进行抓包看一下他传递了什么参数。

我们可以看到传递了一个orderlist参数，此时如果你想到了url解码，那你就超过了50%的人了。

可以看到传递了键值对，很显然的是sum和p_price键代表了金额相关。联想一下上图是不是知道了他们分别应该代表商品总金额和实付款呢？那么我们把这两个值修改为1然后重新url编码发送过去，看一下结果。

是不是有趣的一幕出现了呢？

任意用户名修改

从箭头所指处可以看到，用户名以及密码都是不可修改的，因为这两个值决定了登录时的唯一性，可以通过这两个信息进行登录，但是继续往下看。

我们看一下前端代码发现其实用户名及电话号码甚至id都是在input表单里的，而id只是用了一个hidden参数，那么我们进行完全修改一下。

可以看到用户名已经修改了，并且可以使用新的用户名登录。这里需要注意的一点就是，id只能修改为未注册的ID，这里猜想id是主键且唯一，所以不能重复。
猜想sql语句应该是:
select * from user where user=admin and pass="123456";
只做了简单的用户名及密码的匹配，其实这个商城系统后来是拿下了shell权限，但是我也没有特地去看他这个功能点的SQL代码，所以就是猜想了。

后记

本次分享就到这里吧，没有什么亮点其实，算是真实环境下一次平常的挖洞过程了，当然可能还有其他的逻辑漏洞，但是当时一心拿权限挖的也不仔细所以就先列举上面这么多希望对大家有所帮助。

最后祝大家前程似锦，心想事成。

原文地址：https://forum.butian.net/share/159

原文始发于微信公众号（bgbing安全）：【逻辑漏洞】-商城平台实战分享