pikachu-暴力破解漏洞解析
本篇blog导航
~暴力破解&暴力破解漏洞概述
SRE实战 互联网时代守护先锋，助力企业售后服务体系运筹帷幄！一键直达领取阿里云限量特价优惠。~基于表单的暴力破解实验
~暴力破解的绕过和防范（验证码&Token）
~验证码的基础知识
~验证码绕过（on client）
~验证码绕过（on server）
~防范措施
~措施总结
~token防爆破？
一、暴力破解&暴力破解漏洞概述
1、什么是暴力破解？
"暴力破解"是一攻击具手段，在web攻击中，一般会使用这种手段对应用系统的认证信息进行获取。其过程就是使用大量的认证信息在认证接口进行尝试登录，直到得到正确的结果。为了提高效率，暴力破解一般会使用带有字典的工具来进行自动化操作。
2、字典如何更有效，便于提高暴力破解的效率？
常用的账号密码（弱口令），比如常用用户名/密码TOP500等；
互联网上被脱裤后账号密码（社工库），比如csdn曾泄露的约600w用户信息；
使用指定的字符使用工具按照指定的规则进行排列组合算法生成的密码。
3、什么是暴力破解漏洞？
如果一个网站没有对登陆接口实施防暴力破解的措施，或者实施了不合理的措施，则我们称该网站存在暴力破解漏洞。
4、什么措施可以防暴力破解？
是否要求用户设置了复杂的密码；
是否每次认证都使用安全的验证码；
是否对尝试登陆的行为进行判断和限制；
是否在必要的情况下采用了双因素认证
……
5、暴力破解漏洞测试流程？
（1）确认登陆接口的脆弱性
确认目标是否存在暴力破解的漏洞。（即被暴力破解的可能性）
例如：尝试登陆-抓包-观察验证元素和response信息，判断是否存在被暴力破解的可能。
（2）对字典进行优化
根据实际的情况对字典进行优化，提高爆破的效率。
（3）工具自动化操作
配置自动化工具（例如：线程、超时时间、重试次数等等），进行自动化操作。
6、如何优化字典？
（1）根据注册提示信息进行优化
对目标站点进行注册，搞清楚账号密码的一些限制，例如：目标站点要求密码必须是6位以上，字母数字组合，则可以按照此规则优化字典，例如去掉不符合要求的密码。
（2）如果爆破的是管理后台，往往这种系统的管理员是admin/administrator/root的几率比较高，可以使用这三个账号+随便一个密码，尝试登陆，查看返回的结果，确定用户名。
例如：
输入xxx/xxxxwx返回"用户名或密码错误"；
输入admin/xxxf返回"密码错误"，则可以基本断定用户名是admin。
此时我们可以直接对密码进行爆破，提高效率。
二、基于表单的暴力破解实验
本次实验我会详细说明burp suite暴力破解模块的使用步骤。以后再进行相同模块使用的时候，就不这么详细了。
1、打开我们的pikachu平台，来到暴力破解下的基于表单的暴力破解模块。
2、提示我们账号密码不存在，我们来到burp suite：Proxy->HTTP history。
3、尝试使用burp suite的暴力破解模块进行破解。
4、打开Intruder，给变量加上特殊符号；
5、选择Attack type为Cluster bomb
6、准备两个.txt文件，命名为username.txt和password.txt。
因为是测试，所以我是自己编写的简单密码本，这样可以提高演示的速度。
7、做如下操作
（1）为第一个变量选择username.txt这个密码本。
（2）为第二个变量选择password.txt这个密码本。
8、我们回想一个问题：在破解完成后，如何判断出哪一对用户名和密码是正确的呢？
我们这样来判断：
9、对线程并发数等参数进行设置（也可选择使用默认的选项），执行破解程序。
10、分析结果。
11、用破解得到的username和password在网站上尝试登陆。
三、暴力破解的绕过和防范（验证码&Token）
3.1 验证码的基础知识：
验证码是用来做什么的？
来验证对方是一台机器还是一个人！
√登录暴力破解
√防止机器恶意注册
验证码的认证流程是?
①客户端request登陆页面，后台生成验证码：
1.1后台使用算法生成图片，并且将图片response（响应）给客户端。
1.2同时将算法生成的值全局赋值保存到SESSION中。
②校验验证码：
2.1客户端将认证信息和验证码一同提交。
2.2后台对提交的验证码与SESSION里边的进行比较。
③客户端重新刷新页面，再次生成新的验证码：
验证码算法中一般包含随机函数，所以每次刷新都会改变。
只要有了验证码就可以防止被暴力破解嘛？
当然不是啦，你想什么呢？！你的验证码就一定安全吗？
3.2 验证码绕过（on client）
一、OK，兄弟们，接下来就来演示不安全的验证码-on client-绕过实验
1、来到pikachu实验平台暴力破解下的验证码绕过（on client）模块，随便输入一个账号和密码+正确/错误的验证码。看看提示我们什么（返回什么提示信息）？
2、转到burp suite，我们可以看到我们提交的表单信息。
3、接下来我们来看源码，在网页空白处右击->查看网页源代码
4、我们知道它在前端进行了验证码的生成和验证，那么他到底有没有在后端同样进行验证呢？我们将burp suite抓到的POST请求数据包发送到Repester（数据包重放）模块。
除此，我们来到实验平台的后端源码看一看（确认一下！！）
5、到此，我们基本可以肯定，在我们技术人眼里，这种在前端JS里边的验证码就是狐假虎威，假把式，我们仍然可以使用burp suite里边的暴力破解模块进行破解。对于暴力破解的选项设置和前边的"基于表单的暴力破解实验"是一样的。我就不多废话了。
通过上边的演示实验，我们知道写在前端JS代码里边的验证码就是纸老虎，那么还有其他类型的验证码纸老虎嘛？
当然还有啦~~
（1）将验证码在cookie中泄露，容易被截取；
（2）将验证码在前端源代码中泄露，容易被获取。
到此，那么我们写在后端的验证码验证就一点安全吗？好多人要崩溃了，你快别说了，刚刚说验证码生成验证流程写在后端安全，现在又说不安全~~
别急别急，验证码的生成验证流程写在后端可不是纸老虎了，只不过后端的验证码生成验证流程如果没有严谨的逻辑，那么也会被不法分子钻了空子。
后端验证码的常见的问题有什么？
（1）验证码在后台不过期，可以在一段时间內甚至长期被使用；
（2）验证码校验不合格，逻辑出现问题；
（3）验证码设计的太过简单或者说有规律，容易被猜解。
3.3 验证码绕过（on server）
好的，接下来，我们继续演示不安全的验证码-on server-绕过实验
1、来到pikachu漏洞实验平台，打开暴力破解下的验证码绕过（on server）模块。
2、我们输入错误的用户名、密码、验证码，来到burp suite看看截取到的数据。
3、观察到截取到的数据，我们发送到Repeater模块，修改验证码的值进行数据重放。
4、我们再来看后台的源码
5、那么有人问了，你不是绕过演示嘛。怎么到现在也没有任何问题啊，别着急~~
6、我们刷新一下页面，记录出现的验证码。
7、来到burp suite下Repeater模块。执行如图片内的操作。
8、看起来也没有什么问题哈！但是，如果你修改用户名或者密码后，而验证码的值我们不改变，又有什么结果呢？
9、ok，你知道怎么一回事了嘛？！我们将数据包发送到burp suite暴力破解模块，进行破解，username和password仍然是变量，而验证码我们设置成一个刷新页面后正确的常量就好了！
上边的问题到底是怎么回事呢？
我们来看代码
如何解决SESSION的问题呢？
四、防范措施
4.1 措施总结：
（1）设计安全的验证码（安全的流程+复杂而又可用的图形）；
（2）对认证错误的提交进行计数并给出限制，例如：连续5次输错，锁定一定时间；
（3）必要的情况下，使用双因素认证；
4.2 token防爆破？
答案是否定的！！！！！！！
我们来看：
我们说虽然每一次token值都会变化，但是由于token响应到了前台，我们在每一次尝试前可以先获得token的值，在提交。其实token对于暴力破解，是起不到防止的作用的。
我们说一般token一般在防止CSRF上会有比较好的功效。
