目录
什么是暴力破解
“暴力破解”是一攻击具手段，在web攻击中，一般会使用这种手段对应用系统的认证信息进行获取。 其过程就是使用大量的认证信息在认证接口进行尝试登录，直到得到正确的结果。 为了提高效率，暴力破解一般会使用带有字典的工具来进行自动化操作。
理论上来说，大多数系统都是可以被暴力破解的，只要攻击者有足够强大的计算能力和时间，（但是一般来讲我们的电脑的性能一次测试的时间也都是有限的）所以断定一个系统是否存在暴力破解漏洞，其条件也不是绝对的。 我们说一个web应用系统存在暴力破解漏洞，一般是指该web应用系统没有采用或者采用了比较弱的认证安全策略，导致其被暴力破解的“可能性”变的比较高。 这里的认证安全策略, 包括：
1.是否要求用户设置复杂的密码；
2.是否每次认证都使用安全的验证码（想想你买火车票时输的验证码～）或者手机otp；
3.是否对尝试登录的行为进行判断和限制（如：连续5次错误登录，进行账号锁定或IP地址锁定等）；
4.是否采用了双因素认证；
...等等。
千万不要小看暴力破解漏洞,往往这种简单粗暴的攻击方式带来的效果是超出预期的!
但是虽然说存在暴力破解漏洞的网站可能会遭受到暴力破解攻击，但是暴力破解攻击的成功的可能性也不是100%，暴力破解成功的前提的你猜到了他的密码或者说网站的正确密码就在你用来破解的密码字典中，如果说他的密码很简单但是你并没有猜到那也是不会成功的（所以说有一个好用的密码字典在暴力破解的时候是可以事半功倍的）。所以有些网站即使存在暴力破解漏洞，但其管理员可能也会忽略它的危害
但是作为一名安全专业从业人员（虽然现在还不是），我们在系统设计的时候，不能为了省事或者各方面的原因而抱有侥幸心理。有的时候万一就是一万。
注：下面就是pikachu靶场的实验过程了，关于pikachu的安装以及burpsuit的安装以及使用方法我这里就不一一赘述了，csdn上有很多类似的文章写的很好很详细，按着图文一步一步做就可以了
暴力破解漏洞测试流程
- 确认登陆接口的是否存在被暴力破解的可能
- 一般形况下就是尝试登陆使用抓包工具，抓取数据包观察相关数据包信息和response信息，然后以此做出判断
- 对字典进行优化
- 可以先对目标网站进行注册以此来验证网站的密码策略，然后适当的选择或者修改字典。提高爆破过程的效率
- 如果爆破的是后台，一般会有一些默认的管理员账号比如 root、admin、administrator等可以尝试用这类账号进行登录，然后看返回页面一般会提示用户名或密码做错或者密码错误，若是密码错误就说明用户名正确，即可只对密码进行爆破。
- 自动话工具破解
- 配置自动话工具进行操作（建议使用Burp Suit工具）
pikachu-----基于表单的暴力破解
尝试登录，并抓取数据包
首先把抓取的数据包发送到Repeater模块，然后点击左上角发送，查看response包，平平无奇的返回用户名和密码错误
发送的Inturder模块，进行暴力破解
发送到Intruder模块后Target不用管默认就可以，Position下的 Attack type选择攻击模式(因为我们用户名和密码都不知道要选择两个爆破的值)所以选择Cluster bomb模式，然后先清除默认选中的值点击clear，再选中我们输入的值的位置点击add
加载两个字典，并且把回应包中回显出的字符串加载到option的Grep-Match模块，可以更好的辨别出有没有爆破成功
点击长度进行排序，可以明显看出这行的数据跟别的不同，使用这行的用户名和密码进行登录
d
暴力破解的绕过和防范（验证码&Token）
验证码（completely automated public turing test to tell computers and humans apart ,CAPTCHA）是我们用来防止暴力破解和防止机器恶意注册的常规方法.
验证码的认证流程
- 客户端request登陆页面b台生成验证码
- 后台使用算法生成图片，并讲图片response到客户端
- 同时讲算法生成的值全局赋值到SESSION（跟踪会话的一种方式类似于cookie但由不相同，Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份）中
- 校验验证码
- 客户端将认证信息和验证码一同提交
- 后台对提交的验证码与SESSION里面的进行比较
- 客户端重新刷新页面，再次生成新的验证码
- 验证码算法中一般包含随机函数，所以每次刷新都会改变
pakachu--验证码绕过（on-client）
不安全的验证码- on client
- 使用前端js实现验证码（几乎形同虚设）
- 将验证码再cookie中泄露，容易被获取
- 将验证码再前端源代码中泄露，也容易被获取
尝试错误验证码
首先再登录界面先试一下故意使用错误的验证码
查看并分析页面源代码
这边显示验证码输入错误，说明验证码最起码在当前页面内是生效的，然后右击页面查看该页面的源代码
可以看到一些验证码的规则以及调用，但是我们可以清晰的看出，该验证码只是简单的停留在前端js层面上，并没有和后端产生交互。所以我们可以推测该验证码是不安全的验证码，可以尝试对该登录页面进行爆破。
开始爆破
所有的步骤是和表单的暴力破解是一样的，唯一区别就是在抓取数据包的时候一定要保证当前页面的验证码是输入正确的
分析后端的源代码
为了验证我们的猜想，我们打开pikachu靶场文件内的源代码进行查看。一般就是这个目录pikachu\vul\burteforce，
通过对后端的源代码进行查看我们可以看到只是对用户名和密码进行了验证，并没有验证码的信息。
pakachu--验证码绕过（on-server）
不安全的验证码-on server
- 验证码在后台不过期，导致可以长期被使用
- 验证码校验不严格，逻辑出现问题
- 验证码设计的太过简单和有规律，容易被猜解
- 目前简单的验证码已经有很成熟的识别技术，基本也等于形同虚设
- 所以在保证安全的同时又不会影响用户体验也很重要
尝试错误验证码
在登录页面尝试，错误的验证码以及空的验证码，可以观察到页面的回显从流程上来看是没有问题的。空的时候显示验证码不能为空，错误的时候显示验证码错误，只有当验证码正确的时候才会显示username or password is not exists～
抓包分析数据包
首先是正确的验证码
然后修改用户名或者密码再次尝试
说明验证码是可以多次生效的，可以尝试爆破，只需把用户名和密码设置为变量，验证码保持这个正确的就可以
开始爆破
爆破过程与前文完全一样这里就不赘述了
分析后端源代码
确实是在验证完成后没有销毁验证码，SESSION的默认失效时间是30分钟，这是非常不安全的
showvcode.php
防范措施
- 设置安全的验证码（安全的流程复杂而可用的流程）
- 对错误的提交计数并给出限制（在一定时间内提交多少次就给出限制）
- 必要情况下使用双因素认证（机制非常复杂基于时间，事件和私钥。可以简单理解为一种非常安全的验证方式）
pikachu-token防爆破
抓包查看并分析数据包
可以看到这边是比平时多出来一个token值
我们进入原登录页面按F12进入开发者模式
然后我们发现这个token值是可以在前端页面直接看到的，并且每点击一次页面就会刷新一下token值。我们先简单了解一下token：Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。也就是说当前页面的token值是会被服务端进行的验证的以此来保证当前页面的唯一性，但是就拿当前这个案例来看有一个问题，那就是首先这个token值是直接以明文的形式在数据包中的，可以很轻易的被找到。那么就被破解或者绕过的概率的很大了。
这里我在网上也看了一些文章，大概就是两种方法
第一种方法
首先第一种，还是和原来一样，只不过这次我们换一种攻击方式
然后还是在这个界面网线划找到
设置字典，其中账号和密码的字典都跟原来的一样，token的值需要不一样的模式
最后点击开始攻击就可以了
最后总结一下，这种爆破模式在一开始在我看来是存在一些问题的，由于攻击模式的原因，账号和密码的字典是一一对应的，就是账号字典里的第一个对应密码字典的第一个，然后以此类推是这样下来的，所以一开始我以为这种模式太死板了，就没办法组合，慢慢查一些资料才明白原来这就是攻击模式的特性，正式因为这样我们才能把token绕过，如果觉得太死板就只能自己手动把字典排列组合一下，然后再加载进去。
第二种方法（利用burpsuit的宏）
这种方式我也不是特别了解，只是仅仅按照实验的流程做了下来，这边贴个链接吧，写的挺详细的我按照他的步骤也复现了。其实我更能接受第二种方法只是不太了解原理
1901
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
