2-4验证码绕过之服务端相关问题

最新推荐文章于 2025-02-05 14:58:25 发布

原创最新推荐文章于 2025-02-05 14:58:25 发布 · 732 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#web安全

web安全从入门到放弃专栏收录该内容

49 篇文章

订阅专栏

本文探讨了服务端验证码存在的常见安全问题，包括验证码不过期、校验不严格及设计过于简单等，这些可能导致验证码失去其防护作用。通过实例展示了如何利用这些漏洞进行账号密码破解。同时，提到了验证码设计应兼顾安全与用户体验，以及随着人工智能技术的发展，验证码技术面临的挑战。解决方案包括设置验证码过期时间和严格的验证机制。

我们这篇文章来讲一下，服务端常见的问题

我们之前说了验证码是一定要在服务端做验证的，那如果在服务端操作的时候，考虑的不够严格，那也是会出一些对应的问题

不安全的验证码-on server常见问题

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

这其实就失去了一个验证码的意义，这是很多系统，都会出现的一个问题

 验证码校验不严格，逻辑出现问题；

验证了前面的账号密码不能为空，但是最后去校验的时候，它并没有对这个验证码进行验证，它只是验证了账号密码，这个是比较低级的逻辑问题

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

失去了验证码防暴力破解的意义，目前图片识别技术越来越强大了，很多比较简单的图形验证码，因为我们验证码反馈到前端是图片，并且它会加些干扰项，目的主要是为了防止机器识别的一些技术，如果我们的图片验证码过于简单，那在目前的识别技术下面，是直接被秒杀掉的

我们可以看一下，下面图片的验证码

在这里插入图片描述

目前简单的验证码已经有很成熟的识别技术，基本也等于形同虚设

你想想12306的验证码为啥要做成这样~~~

所以除了设计安全的流程外，验证码是否够复杂（而又不影响用户体验）也是在验证码设计中很重要的！

现在还是有些公司，可以进行自动识别，然后提供一些抢票刷票的工具

验证码的作用，本来是为了区分人和机器的，让它变得更加复杂，机器没法识别，人可以识别

但是我们设计的太简单，被识别出来，其实就失去了做验证码的意义，所以说，做一个安全而又不影响用户体验的验证码或者说验证机制，其实还是比较重要的

现在互联网上，有很多区分人和机器的验证方式，比如说，在注册的时候，让我们算一道题，让我们找出某个指定的汉字等等，那随着这种识别技术，人工智能的发展，这种验证码的技术，也会面临越来越大的挑战

本次实验暂不涉及验证码识别技术

我们切回到pikachu上面，我们还是按照之前的测试逻辑，我们来验证一下验证码的有效性，我们先输入错误的验证码

在这里插入图片描述

它提示验证码错误，这回，我们不输入验证码

在这里插入图片描述

它提示验证码不能为空，这回，我们输入正确的验证码

在这里插入图片描述

它提示账号和密码不存在，说明验证码验证过了，整个流程看起来，没有问题，我们通过BP看一下刚发的那个请求

在这里插入图片描述

我们把这个请求发送到repeater去

在这里插入图片描述

我们通过后端来提交看看，首先我们不提交验证码，看看后台有没有对他进行验证

在这里插入图片描述

我们看到这里，它返回验证码不能为空，后台还是做了校验的，然后我们输入错误的验证码，点提交

在这里插入图片描述

这边它提示验证码错误，说明这个后端是做了验证的，从表面看确实是没有问题，我们接下来验证一下这个验证码，有没有存在不过期的问题

首先我们去刷新这个页面，得到一个有效的验证码，根据我们之前讲的验证码逻辑，当我们去刷新这个页面的时候，实际上是向后台发送了一个请求，当后台收到这个请求之后，它会生成一个验证码给我们，同时后台会在session里面，把这个验证码给存下来，存下来的目的是对你提交的进行验证，我们回到bp来，把验证码改成正确的验证码，按照逻辑，我们点提交，后台返回的是用户名密码错误，因为验证码是对的

在这里插入图片描述