把刚刚试的随便一个包send to repeater,改成当前网页显示的验证码，send，发现response中提示的是用户名或密码不存在，说明验证码是对的,还是这个验证码，把密码改一下，send，发现response中提示的还是用户名或密码不存在，说明验证码还是对的,这就说明之前的猜想是正确的，只要网页没刷新，验证码在burp suite中可以多次使用,之后的爆破过程和1是一致的。
##思考
为什么会有这样的情况出现，查看源码：
验证码绕过（On Client）
用户名和密码输入错误值，当验证码是正确值时，返回结果如下，提示用户名或密码不存在
用户名和密码输入错误值，当验证码是错误值时，有弹框提示验证码错误，之前对用户名或密码的提示也没有清除
那根据上面两张图，特别是验证码错误时有弹框这点，非常怀疑用户名和密码是在后端验证的，但验证码是在前端验证的。
右键 查看网页源代码，发现果然前端有检验验证码的js脚本
到目前为止一切就清楚啦，既然是前端检测，那直接用burpsuite发请求报文绕过前端就可以了
把burpsuite的proxy模块抓到的这个报文send to intruder,之后的过程就和1中的过程一致了。
token防爆破？
这关没有验证码了，用户名或者密码输错会提示用户名或密码不存在
既然和token有关，我们用不一样的值login两次看看burpsuite抓到的报文有啥区别？
把proxy模块抓到的两次登录的报文send to comparer对比一下，确实两次的token不一样、
我们做了下次两种尝试
1、不管token，直接login查看bp抓包的内容，发现回显中提示csrf token error； pass
2、删除token，直接login查看bp抓包的内容，回显中什么响应结果都没有； pass
3、虽然前面两条路死了，但是尝试的时候发现response中网页源代码有一个type为hidden，name为token的input标签，value和request报文的token不一样，应该是下一个报文的token。那试一下把request中的token值改为response中的token值，再次send，返回了提示用户名或密码不存在，并且返回了下一次的token值
按照上述的思路，我们选用Pitchfork，username和password和1中的配置是一样的，token配置复杂一些。使用Refetch response，然后找到response中的token，双击value后面的值，上面define start and end的地方就会自动生成正则表达式啦。
注意爆破的线程要调整为1，因为每次都要用上次response中返回的token，多线程就会乱套了。
