暴力破解的绕过和防范（验证码&Token）
暴力破解之不安全的验证码分析
—on client
—on server
Token可以防暴力破解吗？
暴力破解常见的防范措施
聊一聊“验证码”
CAPTCHA，“Completely Automated Public Turing test to tell Computers and Humans Apart”
全自动区分计算机和人类的统一测试，简单来说，就是区分对方到底是人在操作还是计算机在操作
我们一般用验证码来做什么？
登录暴力破解
我们可以在很多网站登录的地方看到验证码
防止机器恶意注册和刷接口
搞清楚验证码的认证流程
当我们打开登录界面，实际上是向后台发送一个请求
客户端request登录页面，后台生成验证码：
1.后台使用算法生成图片，并将图片response给客户端；
实际上是字符串
2.同时将算法生成的值全局赋值存到SESSION中；
校验验证码：
1.客户端将认证信息和验证码一同提交；
2.后台对提交的验证码与SESSION里面的进行比较；
正确就可以验证成功，失败，就会提示你验证码错误
客户端重新刷新页面，再次生成新的验证码：
验证码算法中一般包含随机函数，所以每次刷新都会改变；
验证码一旦验证过后，一定会被销毁掉，因为验证码一定是一次一用的，但同时，前端只是请求了这个验证码，没有发送验证情况下，后台一般也会对这个验证码设置一个超时时间，比如说，默认时间是1分钟，那如果说，你一分钟都不提交这个验证码，那下一次，你就要重新刷新获取验证码，后台验证码会过期，这才是一个比较安全的设计机制，前端刷新页面的时候，后端当然会生成新的验证码
我们接下来看一下，对应的绕过
验证码可以防暴力破解，但你的验证码安全吗？
不安全的验证码-on client-绕过实验演示
代码演示
我们回到pikachu平台做对应的演示
我们先来看一下，这个接口是否存在被暴力破解的可能性
我们随便输个账号、密码，但是不输验证码，他会提示我们
要输入验证码
输入一个错误的验证码，他会提示验证码错误
那就是说，一定需要验证码才可以过这一步，我们输入一个正确的验证码，我们点login
验证码通过了，他会说，用户名、密码错误，这个没有问题
这个接口加了个验证码，由于这个验证码，每次都会变，所以说，根据我们的逻辑，我们实际上是没有办法对这个验证码进行暴力破解的
我们看到在BP里面有破解的请求
这里多出来了个验证码，看起来，没有问题，我们回到页面来，查看源代码，看是不是在前端做的
我们发现所有验证码的逻辑是在js里面实现的，从安全的角度来说，在浏览器前端做js验证是不靠谱的，是很容易被绕过的
我们从后端来看一下，是不是真的没有验证，我们手动写个随机的验证码，这个验证码实际上是不存在的，因为他跟前端长度不一致，或者我们不输验证码，按照正常的提示，是请输入验证码
但是他确实提示我们用户名和密码不存在，并没有提示我们验证码没有输，这个是时候，我们输入一个错误的验证码
同样的，他也没有提示验证码错误，这个时候就能够说明，虽然验证码提交了，但后台却没有验证，所以我们刚刚在前端验证的时候，弹出来的框，实际上是通过js来验证的，这个实现，对一些不懂技术的，是可以起到一定效果的，对知道原理的人来说，实际上是没有什么鸟用的
我们用字典跑一下，验证码不管它，因为根据我们的判断，这个是没有什么用的
我们根据返回的长度进行判断
在我们实际应用场景的设计过程中，可以把前端的安全措施，做为一种辅助，但是绝对不能够依靠它做为一种限制，后端需要有人对它进行验证，那才是可靠的措施
接下来，我们看一下后端代码，所有漏洞的源码，都在vul下面，我们可以看一下，C:\phpStudy\WWW\pikachu\vul\burteforce
相关的页面功能，我们不要去管他
没有对前端的验证码进行接受和判断，前端验证码仅仅在前端做一个处理，并没有在后端做一个验证，所以说，这肯定是能够被绕过的
不安全的验证码-on client常见问题
使用前端js实现验证码（纸老虎）；
没有用
将验证码在cookie中泄露，容易被获取；
根据我们刚刚说的生成验证码的逻辑，当我们去请求验证码的时候，后端会生成验证码，同时，它应该会把验证码以图片的形式，展示在前端，而不是以字符串的方式，而有些系统，它会直接把验证码，以文本的形式，把它响应到前端的页面去，或者是把它响应到前端的cookie里面去，一旦验证码以字符串的形式，输送到前端页面的html里面或者是cookie里面，这都是可以被程序读到的，即使在这种情况下，你对后端开启了验证，但是前端的攻击者，可以写一个脚本，刷新这个页面，先把我们输出的验证码给获取到，也就是说，你的验证码，提前被泄露了，这也是我们在实际的应用系统里面，比较容易出现的问题
将验证码在前端源代码中泄露，容易被获取；
