暴力破解（Pikachu）
暴力破解(Pikachu靶场)
Burpsuite4种攻击类型
- Sinper（狙击手)： 可以理解为一个一个爆破，也就是字典只能设置一个，然后用字典替换选择的参数，爆破完一个参数后再爆破另一个参数。
- Battering ram（攻城槌） 字典只能设置一个，同时将所有参数都替换为字典内容遍历一遍。
- Pitchfork（干草叉） 多参数同时爆破，但使用的是不同字典。
- Cluster bomb（集束炸弹） 多参数做笛卡尔乘积模式爆破。多个密码本对应多个位置，交叉组合，每一个密码本里的密码都对应于另一密码本所有密码。常用于爆破账号密码。
概述
“暴力破解”是一攻击具手段，在web攻击中，一般会使用这种手段对应用系统的认证信息进行获取。 其过程就是使用大量的认证信息在认证接口进行尝试登录，直到得到正确的结果。 为了提高效率，暴力破解一般会使用带有字典的工具来进行自动化操作。
理论上来说，大多数系统都是可以被暴力破解的，只要攻击者有足够强大的计算能力和时间，所以断定一个系统是否存在暴力破解漏洞，其条件也不是绝对的。 我们说一个web应用系统存在暴力破解漏洞，一般是指该web应用系统没有采用或者采用了比较弱的认证安全策略，导致其被暴力破解的“可能性”变的比较高。 这里的认证安全策略, 包括：
1.是否要求用户设置复杂的密码；
2.是否每次认证都使用安全的验证码（想想你买火车票时输的验证码～）或者手机otp；
3.是否对尝试登录的行为进行判断和限制（如：连续5次错误登录，进行账号锁定或IP地址锁定等）；
4.是否采用了双因素认证；
第一关 基于表单的暴力破解
Burpsuite抓包
在intruder模块选择选Cluster bomb攻击方式进行爆破
第二关 验证码绕过(on server)
思路：
判断验证码在输入错误时是否显示：是
判断验证码是否有非空错误：是
判断验证码刷新后是否还能重复利用：
抓包之后输入正确的验证码 ----> 发送 ----> 提示密码错误
此时验证码更新 ---- 继续发送 ---- 没有提示验证码错误，说明验证码存在不过期，可以重复利用。
使用intruder暴力破解
第三关 验证码绕过(on client)
同第二关一样：
判断验证码在输入错误时是否显示：是
判断验证码是否有非空错误：是
but.......
当我准备抓包时，在代理模式下发现依旧有弹窗出现，怀疑为前端有验证，将验证码输入正确再抓包
将验证码改为空或者改错都直接绕过了验证码。
查看源代码确定是前端验证，直接禁用js或者输入正确的验证码之后再选择bp暴力破解
第四关 token防爆破?
把proxy模块抓到的两次登录的报文send to comparer对比一下，确实两次的token不一样
尝试删除token，response中什么返回结果都没有
尝试不改动token，直接重放，response中提示 csrf token error，无法直接爆破。
发现response中网页源代码有一个type为hidden，name为token的input标签，value和request报文的token不一样，应该是下一个报文的token。
那试一下把request中的token值改为response中的token值，再次send，返回了提示用户名或密码不存在，并且返回了下一次的token值。
根据以上结果，下一次request需要携带的token就是上一次response中html代码中的隐藏字段值，也就是说request中的token是可以从上一个response中提取的
那么还是可以暴力破解，只不过配置稍微复杂一点：
首先position除了username和password再增加token，此外要注意Attack type选Pitchfork（payload一一对应，数量为最少的payload的数量）。这里为啥要选Pitchfork而不能选Cluster bomb，尝试一下就知道了`(>﹏<)′（剧透：因为Cluster bomb是三组payload排列组合，一个token用好几次显然不行）
由于前面使用的用户名和密码payload列表都是适用于Cluster bomb的，而Pitchfork对payload的要求可能更高一些（需要提前整理好对应关系），第一和第二个payload按照前几关那样设置，第三个payload type设置为Recursive grep
还有一个需要注意的地方是线程要设置为1，因为每次都要用上次response中返回的token，多线程就会乱套了。
开始爆破。
Token是什么？
作为计算机术语时，是“令牌”的意思。Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。
◾ 前端登陆的时候向服务器发送请求，服务器验证成功，会生成一个token
◾ 前端会存储这个token，放在session或cookie中，用于之后的业务请求身份验证
◾ 拿着这个token，可以在当前登录的账号下进行请求业务，发送请求时，token会放在请求头里，服务器收到这个业务请求，验证token，成功就允许这个请求获取数据
◾ token可以设置失效期
Token 有什么作用？
`防止表单重复提交；
Anti CSRF 攻击（跨站点请求伪造）。`
两者在原理上都是通过 session token 来实现的。当客户端请求页面时，服务器会生成一个随机数 Token，并且将 Token 放置到 session 当中，然后将 Token 发给客户端（一般通过构造 hidden 表单）。下次客户端提交请求时，Token 会随着表单一起提交到服务器端。
然后，如果应用于“Anti CSRF攻击”，则服务器端会对 Token 值进行验证，判断是否和session中的Token值相等，若相等，则可以证明请求有效，不是伪造的。不过，如果应用于“防止表单重复提交”，服务器端第一次验证相同过后，会将 session 中的 Token 值更新下，若用户重复提交，第二次的验证判断将失败，因为用户提交的表单中的 Token 没变，但服务器端 session 中 Token 已经改变了。
上面的 session 应用相对安全，但也较繁琐，同时当多页面多请求时，必须采用多 Token 同时生成的方法，这样占用更多资源，执行效率会降低。因此，也可用 cookie 存储验证信息的方法来代替 session Token。比如，应对“重复提交”时，当第一次提交后便把已经提交的信息写到 cookie 中，当第二次提交时，由于 cookie 已经有提交记录，因此第二次提交会失败。不过，cookie 存储有个致命弱点，如果 cookie 被劫持（XSS 攻击很容易得到用户 cookie），那么又一次 game over，黑客将直接实现 CSRF 攻击。所以，安全和高效相对的，具体问题具体分析吧！
此外，要避免“加 token 但不进行校验”的情况，在 session 中增加了 token，但服务端没有对 token 进行验证，这样根本起不到防范的作用。还需注意的是，对数据库有改动的增、删、改操作，需要加 token 验证，对于查询操作，一定不要加 token，防止攻击者通过查询操作获取 token 进行 CSRF攻击。但并不是这样攻击者就无法获得 token，只是增大攻击成本而已。
