前言

在学习了大量web逻辑漏洞的知识后，想进行实战。练练手。作为小菜鸡的我，这是我第二次进行实战挖洞，可能会存在许多问题。望各位大师傅多多指点。

闲话少说，直接开整

实战

1.信息收集

首先，在src中找了一个网站应用，获得其域名地址为  “****.****.com”。

接下来就是一些常规操作（信息收集）啦。。。

1. 域名反查IP

我使用的是“超级ping”网站，不仅可以查看域名对应的IP地址，还可以查看其网址是否使用CDN技术，至于CDN技术是什么，我就不多说啦。

可以查到该网站的ip，并且可以发现从全国各地发起的ping命令，对应域名的DNS解析地址均相同，故可判断该网站没有使用CDN技术，这样就好办了，不用为找网站真实服务器IP而发愁了。

2. 子域名查看

对该网站的二级域名 "***.com" 进行下一级域名的爆破，为了避免自己的IP被封，直接使用在线的子域名爆破网站。

我使用的是这个网站“http://z.zcjun.com/”

发现爆破出了不少的子域名，留着后面用。

3. 查看该域名是否存在旁站

旁站就是在同一台服务器上搭建的多个网站，使用同一个IP地址。在目标网站无法攻击成功时，若他的旁站可以成功攻击并获取相应的系统权限，这势必会影响到目标网站的安全性，应为已经获取到同一台服务器的权限了。

我使用的在线平台是”https://chapangzhan.com/“

发现该IP下，只有一个域名。故不存在旁站。

唉，少了一条攻击思路。。。

4. 网站CMS指纹查询

有些网站是直接使用网上的建站源代码直接搭建的网站，通过识别其指纹，可以发现其是使用哪一套源代码搭建的网站。然后再使用搜索引擎搜索对应源代码存在的漏洞，这样就可以直接进行利用

我使用的平台是“http://whatweb.bugscaner.com/batch.html”

虽然没有识别出网站的CMS，但是识别出了网战的WAF和Web Server等重要信息。

5. 敏感目录收集

由于我这次着重练习的Web逻辑漏洞，敏感目录收集就暂时不进行了。

更重要的原因是网站使用WAF防火墙，当我进行敏感目录扫描的时候，会从同一个IP发出大量的数据包，IP会被封掉的，那就没得玩儿了。

信息收集就告一段落了。。。

2.正式实战开始

首先，打开官方网页，发现了”登录注册“功能，那就从这里开始吧，看看其是否存在逻辑漏洞。

在这个功能点处，需要输入“手机号”和“对应发送的短信验证码”进行新用户注册。

这里不得不吐槽的是，连一个图片验证码都没有，这也太不安全了吧。

第一个点：可以枚举出注册了该网站的用户的手机号码

虽然我知道这可能都不算一个漏洞，水一下，哈哈哈。。。

该注册功能会在点击获取验证码之后，会将输入的手机号传送到服务器后端进行验证是否已经注册，并将结果返回到前端。

1.手机号已经被注册了，后端返回的数据包

2.手机号没有被注册，后端返回的数据包

由于该注册功能，并没有使用图片验证码机制进行防御，故可以将客户端用于检验手机号码是否注册的数据包发送到BURP的intruder模块进行枚举。

这样就可以爆出注册了应用的用户手机号。

修复手法：在注册处，添加图片或者其他类型的验证码，以减缓攻击者的枚举速度。

第二个点：任意手机号注册

在该网站的注册处，本应该使用“用户的手机号和其手机上的验证码”来进行注册，但可以通过修改服务器后端的验证码校验状态码，来绕过验证码的验证，进行任意用户的注册。

这个漏洞是怎么发现的尼。。

我在检测注册功能时，使用burp一个包一个包的查看，分析每个数据包中参数的作用以及整个注册的实现流程。就发现后端返回的数据包，总是包含状态码，故猜测用户注册使用的验证码时，使用前端验证。

1.输入任意的手机号码

2.点击获取验证码，并使用burp抓包

发送的数据包：

返回的数据包：

显示该用户没有注册。

中间就是一些没有什么用，这里就不截图浪费时间了，直接到最关键的一步。

3.修改服务器后端的返回状态码，实现任意用户注册。

随便输入验证码，使用Burp抓取数据包

发送的数据包：

使用burp中的intercept-->Response to this request截获该请求的相应数据包。如下：

然后就是更改状态码为正确状态码，（我是怎么知道正确的状态码尼？我在使用自己手机号注册时，得到了正确的响应状态码）

修改后，如下：

放行后发现注册步骤直接进入下一个步骤，

然后就是正常的注册，(填入一些实名信息，以及企业名)，就注册成功了，成功页面如下：

大功告成啦。。。开心.jpg

还有这里在注册时，还会要求出入企业的名称，若企业名称已存在，其会报出“企业名已存在”，通过这个点也可以枚举出，注册了这个网站的企业名称信息，这里就不再重复第一个操作了。

修复方案：一些比较重要的验证操作一定要放在后端服务器进行处理，不要过度的相信前端JS代码。