基于表单的暴力破解

随便输入用户名密码，burp suite抓包

发现request中的username及password

发送至intruder设置payload，使用cluster bomb模式，采用对应的字典（user、password）进行爆破，一般我们可以通过返回字段的长度不同查看是哪对payload成功登录，但并没有发现明显差异，可以在intruder的grep-match中添加关键词（如success，welcome等等），Intruder 会在结果中标记哪些响应包含它们。

有验证码（服务器端发送的验证码）

由于某些服务器端的疏忽如未设置验证码失效时间，也就意味着只要我们验证码的输入是正确的，那么这个验证码就不会刷新，那我们就可以在此基础上做账号密码的暴力破解

--随便输入账号密码（正确的验证码）后抓包--将抓到的request发送至intruder进行暴力破解即可，由于是将历史包发送给服务器，所以并不会刷新验证码

怎样确定验证码是on sever的呢？

输入正确的验证码后，通过bp将request重放，修改正确的验证码，response提示验证码错误，说明服务器在对验证码进行校验；亦或者直接把验证码的字段删除了，如果是on client的，那肯定不会有影响，而此时删除后显示验证码不能为空，很确定是on sever

有验证码（验证码是由客户端生成的）

--同样随意输入后进行抓包（验证码也随意）

同时burp suite也没有抓到包，有理由怀疑验证码是在客户端进行校验的

那我们继续输入，但输入正确的验证码，此时bp能抓到该post包了，为了验证我们的猜想，我们重放一下，发现虽然返回的response中验证码一直在变化，但request中验证码我们仍然没有变，大胆一点，将request中正确的vcode也删除了，还是没有影响，那就已经敲定是在客户端的验证码校验了，因为服务器没有对验证码进行校验

还有一点，我把cookie也删除了，发现同样也不影响，说明服务器没有将登录过程与会话机制绑定，这也是一个问题

有token的登录

什么是token？

每个token是由服务器生成，并存储在对应session中的。当你访问登录页面时，服务器会通过cookie分配一个session ID，并生成一个token与之绑定。当你提交登录请求时，服务器会校验提交的token是否与当前session中存储的token一致。校验通过后，该token 立即失效，服务器会生成新的token用于下一次请求。

为什么不设置三个payload--用户名、密码、token？

一个session一次只能有一个有效token。如果同时尝试多个用户名，需要为每个用户名维护一个独立的session，但intruder 默认使用同一个session（即cookie不变）。如果强行用同一个session尝试不同用户名，token的提取和更新会混乱，因为每次请求后token变化，而该token只与当前用户名（其实是当前session）相关，无法正确对应到其他用户名。

所以，一般情况下我们需要通过别的方式获取一个已有的用户名（社会工程学等等），只设置两个payload--密码和token，我们还需要在grep-extract（intruder的settings中）中增添一条规则动态获取token，先refetch response更新一下响应包，得到一个新的token

在token处payload的选择上要使用recursive grep（递归匹配），再将刚刚得到的新token复制到第一个请求的初始payload

攻击模式上要选择pitchfork，并且在资源池中新建一个最大请求数为1的resource pool

实际上我们不选择设置三个payload的原因就是我们要用pitchfork这种攻击模式（因为可以使用递归匹配这种payload type动态获取token，而pitchfork中多个payload是一一对应的，就算我们的user字典和password字典中都有正确的用户名和密码，只要不处于同一位置也就是没有对应，那么我们也是不能成功登录的）

为什么要设置单线程？

1.第一次请求：使用初始获取的 token1（例如从登录页面抓取），尝试一组用户名/密码

2.服务器验证，返回结果，并在响应中（或通过新的set-cookie）提供新的token2

3.intruder 从响应中提取token2，作为下一次请求的token

4.第二次请求：使用token2尝试下一组用户名/密码

如此循环，保证每次请求使用的token都是最新的，且与当前会话状态一致

[培训]Windows内核深度攻防：从Hook技术到Rootkit实战！