暴力破解哪些事儿（2）

1.暴力破解的绕过和防范（带有验证码）

验证码有什么用？

     防止登录接口被暴力破解

     防止用户恶意注册

带有验证码的登录接口认证流程是什么样的？

1.1 客户端请求登录页面，后台生成验证码 

    当打开登录界面的时候，实际上是向后台发送了一个请求。后台收到请求之后，调用一个生成验证码的函数，负责生成验证码（生成的验证码传回到前端的时候，一定是个图片）

        (1) 后台使用算法生成图片，并将图片response给客户端

        （2）同时将算法生成的值全局赋值存到session中

1.2验证码校验

   后台算法生成的验证码以Session的形式存到缓存中。用户登录认证时，登录账号、密码、验证码，提交的时候会将验证码的文本信息提交到后台。后台会对前端提交过来的验证码和session中保存的验证码进行比较。

        （1）  客户端将认证信息以及验证码一起提交

        （2）  后台对提交的验证码与session里面的进行比较

1.3 客户端重新刷新页面，再次生成新的验证码

（验证码算法中一般包含随机函数，所以每次刷新都会改变）一旦认证成功后，验证码就会被销毁掉（因为验证码一定是一次一用的。）

后台会对验证码的时间进行设定：

     例如：如果用户请求了验证码，但是未登陆，那么一定时间后，后台会将此验证码进行销毁，也就是需要重新刷新，获取新的验证码。

2. 客户端绕过实验（不安全的验证码）

1. 按照暴力破解那些事儿（1中所讲），第一步判断登录接口是否能够被暴力破解，即：任意输入，查看回显信息，并通过抓包，分析包信息，认证因素等等。

      随便输入用户名+密码，但是不输入验证码：                                               输入错误的验证码

输入正确的验证码并利用burpsuit抓包

认证因素包含验证码，那么是不是有验证码就一定是安全的？

查看页面源代码

查看JS代码在何处被调用？

分析上面可知：

所有验证码的生成和验证都是通过Javascript在前端来实现的。

从安全的角度来看，通过JS在前端做这些安全的认证是没有意义的，很容易被绕过。然后我们通过看数据包，去看是否后端没有进行安全认证，仅仅在前端做了验证。

在repeater模块修改数据包信息（修改验证码），观察回包信息

上面的两个图，分别没有输入验证码和输入错误的验证码，但是在后台并没有返回验证码错误，或者请输入验证码的相关信息，而是返回用户名和密码不存在。即说明：并没有在后台进行验证码的安全认证，实际上仅仅是通过前端的JS来实现的。

2，进行爆破，爆破流程参照暴力破解哪些事儿（1）（注：破解流程都是一样的，选择第四种爆破模式（集束炸弹）进行爆破（最常用））

攻击结果：可见用户名admin 密码为123456

分析：在前端用JS做的验证码是没有什么意义的，很容易能被绕过。在实际中，前端的这种手段只能作为辅助手段，重点还是靠后端安全验证。

******************分析后端源码

查看后端源码：发现后端只有密码和用户名，并没有对验证码做限制。即只判断username和password如下如所示：

综上所述：得出以下结论

1：在前端；利用JS实现验证码不靠谱

2：将验证码暴露在cookie中，很容易被敌手获取

3：将验证码在前端源代码中暴露，很容易被获取。

***********************************************************************************************************

上次实验表明：验证码一定是要在服务端（后台）进行验证的，但是在后台进行操作的时候，如果代码不够严格，同样也有可能被绕过。原因如下：

     1：验证码在后台不过期，导致可以长期被使用

     2：验证码校验不严格，逻辑出现问题

    3： 验证码设计的太过简单和有规律，容易被猜解

3.服务器端绕过实验

3.1先确认下验证码的有效性（验证码错误+空验证码+正确验证码）

**在后台不输入验证码试一下，看一下响应信息，response显示验证码不能为空====》说明后台有做过校验,具体如下：

**在后台输入错误验证码，看一下响应信息，验证码输入错误，说明后台有做过校验

通过上述测试，是不是就一定不存在问题呢？如果存在问题该如何去考虑？

入手点就往上面存在问题里面找：即：验证码在后台是否有过期的问题

***************************操作步骤

刷新页面获取一个新的验证码：（验证码获取的具体流程见上）

在burp中将验证码修改成为正确的验证码，查看response

在验证码不改变的情况下，修改账号和密码再重新发一次，看看这个验证码是否还有效？

如果有效，那么证明验证码可以被重复利用。结果如下：

结论：验证码可以被重复利用。也就是说虽然你有验证码，但是可以一直使用。

实施爆破流程：（利用第四种模式，添加两个字典）开始进行爆破，通过观察响应包的长度。

不需要上述这些匹配，因为我们通过返回包的长度去判断就行了。

*查看服务器端源代码

当你刷新这个页面，img就会访问showvcode.php这个文件，生成新的验证码

当你点击这个验证码时，也会访问showvcode.php这个文件，生成新的验证码

生成验证码的代码

解决办法：

1用过一次就应该立即销毁掉 2：设置session有效时间（默认时间是24分钟）

************防止暴力破解的措施