暴力破解：
"暴力破解"是一攻击手段，在web攻击中，一般会使用这种手段对应用系统的认证信息进行获取。其过程就是使用大量的认证信息在认证接口进行尝试登录，直到得到正确的结果。为了提高效率，暴力破解一般会使用带有字典的工具来进行自动化操作。这里用的是burp suit抓包，在kali上有自带的密码字典，也可自行解压使用。
如何防止暴力破解？
0x01：要求用户设置复杂的密码
0x02：使用安全的验证码
0x03：对尝试登录或者改密服务进行判断和次数限制
0x04：采用多重机制验证 比如token
如何优化字典？
0x01：对目标站点尝试自行注册，观察账户密码设置的限制
基于表单的暴力破解模块：
设置代理，随便输入一个用户名密码用burp suite抓包发送到Intruder模块
（操作基本与DVWA上的 Brute Force一致，我这里略去步骤，不懂步骤的可以翻看我以前的blog）
这里注意proxy下还有个模块
HTTP history 可以抓到我们的GEY和POST请求：
在Proxy的HTTP History下可以看到这个POST请求：
可以观察到登录验证只有username和password两个参数，没有token和验证码等参数，是一种
最基本简单的暴力破解。
抓包：可以右键选择Send to Intruder或者Ctrl+I发送到Intruder模块
关于Burp Intruder主要有四个模块组成:
1：Target 用于配置目标服务器进行攻击的详细信息（也就是目标地址和端口）。
2：Positions 设置Payloads的插入点以及攻击类型（攻击模式）。
3：Payloads 设置payload，配置字典
4：Opetions 此选项卡包含了request headers，request engine，attack results ，grep
match，grep_extrack，grep
payloads和redirections。你可以发动攻击之前，在主要Intruder的UI上编辑这些选项，大部分设置也可以在攻击时对已在运行的窗口进行修改。
先进入Payload Positions（有效载荷位置）模块：
0x01：先点击右边clear清除所有变量
0x02：将username和password后面的参数值选中，点击右边的Add$使它们变为我们需要破解的参数
0x03：在Attack type中选择攻击模式，我选择的cluster bomb。
攻击类型设置有四种：
sniper：对变量进行依次破解，多个标记依次进行（比如先破解账号，密码不变，等遍历完账号后账号不变再去遍历一遍密码，同时只能对一个payload进行操作）。
选择这个模式时，payloads set处只有一个参数，默认的payload type是simple list
一般会把payload type 改成Runtime file并select一个字典。
battering ram：对变量同时进行破解，多个标记同时进行（根据字典对于多个变量进行同时替换值）。
pitchfork：每一个变量标记对应一个字典，取每个字典的对应项。
cluster bomb：每个变量对应一个字典，并且进行交集破解，尝试各种适合用户名和密码的组合
为每一个变量添加对应的字典：
在payload set处选择对应的参数（你上面Add的第一个对于payload set处的值就是1）
load浏览本机文件并添加字典
如果突然想到一些密码组合可以直接在这里Add加进密码字典中去。
在payload Encoding里可以设置字典中关于特殊的字符是否需要URL编码。
进入options选项卡，更改线程并发数为50，这样可以提高效率
参数为2000那里是并发的间隔时间（每次并发请求的间隔），有些网站会对这种多并发去做限制。
之后在左上角Intruder处选择start attack
找到length长度与其他不一样的一行，这个就是对应的账号密码。
也可以在Grep Match中设置一个Flag来标记错误的账号密码组合，以便于字典过大再进行爆破
的时候难以找到正确的账号密码组合。添加好后再attack就会在上图中多一列Flag状态栏，可以
点击这个Flag的列名，可以进行排序，而没有Flag标记的就会被排到第1行。
解释一下为什么会出现这个结果 ，因为登录成功和失败返回的提示长度是不一样的，
那么造成的回应包长度也是不一样的，比如这个网页就是
登陆失败：
登陆成功：
So ：length短的那个包是被验证登录成功了 。
验证码绕过 on server：
验证码的流程：
客户端request登录页面，后台生成验证码，验证码图片响应到前端页面，同时将算法生成的
值全局复制保存到SESSION中。校验时，客户端将认证信息和验证码一块提交，也就是确认
此时执行操作的是一个人而不是机器脚本，客户端刷新页面再次生成新的验证码。
一般漏洞产生原因：
验证码在后台可长期使用（经常）
验证码校验不严格
而on server模块这里问题就在于验证码长期有效了（指的是只点击login抓包的情况下，这样
我们可以无限制次数的进行暴力破解）。
同样还是输入错误的用户名密码以及正确的验证码，先把包发送到Repeater中观察：
我这里应该是显示问题，这里应该是会出现验证码不能为空的提示了。证明在后台做了验证验证码的操作
而后将验证码改为正确的验证码（忘记的话可以重新刷新前端页面），并Go两次错误的账号密码
之后发现不会爆出验证码过期或者错误的提示，说明验证码没有时间限制而是长期有效。
之后和之前的操作就都一样了。
SESSION默认的时限是24分钟，可以去php.ini中设置，而本模块的源代码没有设置验证完验证码
就销毁掉SESSION的操作，那么导致了验证码长期有效
验证码绕过 on client
前端的验证码可以作为一种辅助，但不能仅靠这个。还需要后台验证才可以。而且验证码不可以以文本的
形式输出到前端，否则可以先提前准备脚本来获取验证码字符串，这样设置验证码就毫无意义了。
这里就是逻辑问题，验证逻辑是在客户端实现的，后台对于验证码没有校验过程，不管我们在改包时
验证码是什么都无所谓，后台不会对验证码进行验证。每次login都会提交验证码并刷新一个新的验证码
首先用错误的用户名密码进行尝试：
看一下POST请求内容：可以看到多了一个验证码
观察源码可以发现验证码实在javascript中写的，验证码的生成和验证都是在前端做的，
把数据包发送到Repeater模块（数据包重放模块）：
在这里可以对前端抓到的包进行修改然后点Go会自动发送修改的包给后台
下面确认后台是否进行了验证码的验证：换一个错误的验证码。
返回提示为上图所示，明显后台没有进行验证码的验证。
防范措施：
1.使用安全的验证码（图形验证码）
2.多次认证错误就进行尝试次数限制
token防爆破：
观察源码：有一个隐藏的token
当每次打开页面，后台生成一个token放在SESSION里面并放在前端的表单里
验证时会加上token这个值进行验证，每次刷新页面时它的值是不一样的。
那么问题来了，token能防暴力破解吗？
不可以。
因为在生成token的同时也已经发送到了前端的form表单里了，攻击者可以提前获取token的值。
但是token用在CSRF中会比较多。