burpsuite配置
暴力破解（Brute Force）
有效的字典：
- 常用的账号密码（弱口令），比如常用用户名/密码TOP 500等。
- 互联网上被脱库后账号密码（社工库），比如某平台泄露的用户信息。
- 使用指定的字符使用工具按照指定的规则进行排列组合算法生成的密码。
判断是否存在暴力破解可能性：
- 是否要求用户设置了复杂的密码
- 是否每次认证都使用安全的验证码
- 是否对尝试登陆的行为进行判断和限制
- 是否在必要的情况下采用了双因素认证
暴力破解漏洞测试流程：
- 确认登陆接口的脆弱性（爆破可能性）
比如：尝试登录——抓包——观察验证元素和response信息，判断是否存在爆破可能性。
- 对字典进行优化
根据实际情况对字典进行优化，提高爆破过程效率。
（1）小技巧：可以先在该平台注册一个账户，观察账户和密码的格式要求，然后删除字典中不符合要求的字符串，再进行爆破，会提高效率。
（2）小技巧：如果爆破管理后台，一般系统管理员的用户名为admin/administrator/root的几率比较高，可以先尝试这三个用户名。
- 工具自动化操作
1.基于表单的暴力破解
使用burpsuite工具中的intruder模块进行暴力破解：intruder模块使用教程
-
先随便输入一个username和password
-
利用burpsuite进行抓包
-
将抓到的包导入intruder模块（在空白处右键，选择send to intruder）
-
选择需要暴力破解的变量和攻击方法
从图中可以看出，intruder模块已经为我们自动筛选出了四个可以爆破的变量，因为我们只需要对username和password进行爆破，所以只要选择这两个变量即可。
（1）点击右边的clear，删除选中的变量
（2）再点击右边的add，将username和password选中
（3）选择sniper攻击方式
-
选择payloads方式并攻击
（1）添加弱口令
可以去网上下载弱口令文件（因为这是练习，所以我就随便添加了几个简单的弱口令）
（2）点击右上角start attack进行攻击
发现当password='123456’的时候，respond数据包的长度和其他的不太一样，因此我们可以重点观察这种情况。 -
查看异常情况的respond数据包
发现这种情况下，返回数据包中有个login success的字段，可以判断该种情况就是正确的账号和密码组合，因此username=‘admin’，password=‘123456’
-
修改数据包
回到抓包界面，修改账号和密码，然后点击forward发送出去
观察到网页上出现了login success，表示登陆成功。
2.验证码绕过（on server）
-
先随便输入一个username和password
-
利用burpsuite进行抓包
-
此时要测试该验证码会不会在服务端被及时销毁，我们先将数据包发送到重放模块（Repeater）
保持验证码不变，通过修改几次username或者password并进行重放，发现收到的回应数据包长度一致，因此推测回应数据包都是因为同一种原因无法登录（即username或password错误，并没有因为验证码错误导致无法登录），大致可以判断尝试登陆的这几次操作，服务器端都用的同一个验证码（验证码可以重复利用），因此我们只要保证验证码不变，对username和password进行爆破就可以了。 -
后面的操作和第一个基本一致，就不再赘述了。（只要保证不变验证码，对username与password进行爆破即可）
3.验证码绕过（on client）
- 先随便输入一个username和password和正确的验证码，然后再随便输入一个username和password和错误的验证码。观察二者区别。
发现输入错误验证码时，网页弹出窗口，可以猜测是在前端生成和判断验证码，于是我们查看源码发现的确是在前端生成的验证码。
所以很有可能这个验证码并没有通过后端进行对比验证。我们对数据包进行重放，不输入验证码，发现返回数据中并没有提示“请输入验证码”，因此可以判断的确没有通过后端验证。
因此我们只需要截取数据包，然后直接进行爆破，就可以绕过前端的判断。
- 利用burpsuite进行抓包
- 发送到intruder模块进行爆破，操作方法和第一个一样。客户端验证码与服务器端验证码区别在于，如果使用服务器端验证码，我们必须保证验证码是正确的，在这个基础上进行爆破。客户端验证码就不用保证验证码的正确性了，甚至删去验证码字段进行登录也是可以的。如图所示：
4.token（令牌）防爆破
先说下结论：token并不能防止爆破。
我们可以从它的流程中推断出来：
使用token机制的身份验证方法，在服务器端不需要存储用户的登录记录。大概的流程：
1.客户端使用用户名和密码请求登录。
2.服务端收到请求，验证用户名和密码。
3.验证成功后，服务端会生成一个token，然后把这个token发送给客户端。
4.客户端收到token后把它存储起来，可以放在cookie或者Local Storage（本地存储）里。
5.客户端每次向服务端发送请求的时候都需要带上服务端发给的token。
6.服务端收到请求，然后去验证客户端请求里面带着token，如果验证成功，就向客户端返回请求的数7.据。(如果这个 Token 在服务端持久化（比如存入数据库），那它就是一个永久的身份令牌。)
第三步就存在漏洞了。
每次提交要验证token值（每次更新），表面上可以防止暴力破解，但后端每次产生的token以明文形式传到前端，漏洞就这样产生了，黑客可以在每次暴力破解之前，获取一下token值，然后填到字典里面，就可以进行暴力破解
- 查看网页源代码（按F12），发现里面有一个字段存储着token值
- 用burpsuite抓取数据包
我们只需要暴力破解username与password，然后再获得对应的token值，一并爆破即可。
但是每次在暴力破解之前打开html找新的token再贴到burpsuite的相应位置就很麻烦，我们要考虑暴破时怎样才能带上正确的token值。我们可以利用intruder模块中配置payload为Recursive grep来对token进行递归提取。配置方法如下：
（1）首先先确定爆破变量为password 和 token
（2）然后对token变量选择负载类型为Recursive grep
（3）进入options进行配置，找到grep-extract模块，点击add，从网页源代码中选中token的位置，会自动生成正则表达式用于提取。
因为是一种递归操作，第二次爆破要依赖于第一次爆破后得到的token值，因此不能使用多线程，所以再配置一下线程。
（4）最后在为password配置一下字典，然后进行爆破即可。
5.总结
-
不安全的验证码- on client 常见问题
（1）使用前端js实现验证码（纸老虎）
（2）将验证码在cookie中泄露，容易被获取
（3）将验证码在前端源代码中泄露，容易被获取 -
不安全的验证码- on server 常见问题
（1）验证码在后台不过期，导致可以长时间被使用
（2）验证码校验不严格，逻辑出现错误
（3）验证码设计的太过简单和有规律，容易被猜解 -
防范措施
（1）设计安全的验证码
1.在后端对验证码进行对比判断 2.判定验证码是否为空，是否正确 3.判定后销毁验证码 4.设置定时销毁验证码（2）对认证错误的提交进行计数并给出限制，比如连续5次密码错误，锁定2小时
（3）必要的情况下，使用双因素认证