验证码复用的漏洞,怎么解决

Blade 未结 2 326
six_six_2005
six_six_2005 剑圣 2025-02-25 16:27

一、该问题的重现步骤是什么?


系统登录界面的图像验证码功能未能启到正常的验证校验,导致攻击者可以绕过图像验证码的限制,进行用户口令的暴力破解。

漏洞数据包:

image.png

浏览器访问系统,发现登录页面有验证码功能,限制了暴力破解。

image.png


删除验证码参数,数据包如上,可绕过前端验证码的限制,实现暴力破解。

image.png

image.png

漏洞修复建议优化图像验证码校验功能,避免攻击者绕过该功能进行用户口令暴力猜解。

漏洞复测结论经复测,该漏洞未修复。

通过提供的漏洞利用数据包,加载字典进行暴力破解,并未提示验证码错误。

image.png



二、你期待的结果是什么?实际看到的又是什么?


三、你正在使用的是什么产品,什么版本?在什么操作系统上?


四、请提供详细的错误堆栈信息,这很重要。


五、若有更多详细信息,请在下面提供。

2条回答
  • 2025-02-25 16:47

    5次错误账号就封了无法暴力破解,验证码验证一次就过期了无法跳过系统。升级到最新版吧,或者看最新版的实现。

    或者你让提交漏洞的人联系我们,我们出个系统让他爆破一下看看具体情况。

    0 讨论(0)
  • 2025-02-25 17:27

    1.我项目是3.3.1的 java 1.8的,升级到哪个版本?3.4 就行了吗?有没有升级步骤?不想大动,项目已经稳定运行。
    2. 提交漏洞的人联系。   我们拉个群吧。

    作者追问:2025-02-25 17:31

    漏洞方面需要邮件联系,沟通记录需要存档。给我们发邮件安排暴破测试工作: bladejava@qq.com

    回答: 2025-02-25 17:42

    3.3.1是不是已经解决了,还是说必须要升到3.4?   不想升到4.4,  因为没有用java 17,不想大动。

    作者追问:2025-02-25 17:47

    3.x肯定不推荐你升级4呀,改动太大了。这个都是小问题中的小问题。用户只要密码失败五次就直接封号了,我都不知道他们是怎么爆破的。关于绕过验证码模式,我在想他们是不是直接用了oauth2的password模式,这个password模式是不需要验证码的。

    如果不要验证码算漏洞,那oauth2为何还保留password模式?这是国际标准协议呀,我不是很明白报这个漏洞的人的做法。

    所以让他们给我们发个邮件对接,具体了解下漏洞本身的问题,看看是不是需要修复。

    如果他们真的觉得password模式也是漏洞,那你们可以直接把PasswordTokenGranter关掉,来请求验证就不给通过,只保留验证码模式。

    回答: 2025-02-26 08:51

    网信:系统确实有5次账号错误锁定策略,所以是个低危漏洞,问题是验证码可以重复使用或者在请求中删除验证码参数服务端就不进行验证码检验了,安全的情况下需要验证码使用一次服务端就销毁重新生成

    作者追问:2025-02-26 09:06

    这个验证码删除的逻辑3年前的bladex3.1版本就有,验证一次就用redis工具类删掉对应的code,一行代码的事。

    IMG_4653.jpeg

    回答: 2025-02-26 09:41

    这是哪个类和文件名,在哪个下面?我找一下相关代码

    作者追问:2025-02-26 09:52

    你们用的是哪个版本,看下CaptchaGranter的代码。如果没有删除rediskey的逻辑,按照我上面的截图加一下del那一行代码就行了。

    作者追问:2025-02-26 09:54

    核心代码是这个:bladeRedis.del(CacheNames.CAPTCHA_KEY + key);

    回答: 2025-02-26 10:08

    找到这里了,已经有相关代码,为何网信还说有问题?还要怎么改?

    b9b82818763e5b5bfbe0eda209751001.png

    作者追问:2025-02-26 10:11

    你在这个类的获取用户的代码之前,再加一个del的方法。也就是获取到redis的code后就立马删掉,不管是不是要去验证都删了。

    作者追问:2025-02-26 10:13

    如果这样改了他们还说有问题,就只能让他们派个代表和我们沟通下漏洞细节了,看看有哪里是没考虑到的或者他们弄错了。

    作者追问:2025-02-26 10:15

    确实想不明白错误5次就封号,他们到底是怎么爆破成功的。

    回答: 2025-02-27 09:28

    帖子里他们提供的抓包记录,看不出来吗

    作者追问:2025-02-27 09:29

    抓包不代表5次内就能成功,他们怎么实现5次就登录进系统的?

    回答: 2025-02-27 10:10

    网信提供了一个手机号,怎么沟通一下?

    作者追问:2025-02-27 10:12

    不支持手机,只能邮件,因为我们需要将沟通记录存档

    作者追问:2025-02-27 10:19

    按照我们上面的说法,验证码从redis获取到之后,立马从redis删掉验证码缓存,你把这个逻辑加上给他们验证。这样的逻辑他们也依旧说是漏洞么?

    能不能让他们发个邮件给个完整的重现方法,看看如何是在5次能成功登录进系统的。在5次错误会封号的场景下都能进系统,那问题就大了,我们需要知道重现的步骤然后立马修复问题。

    如果他们进不去,就说明自己都没验证过就给你们发漏洞了。

    CleanShot20250227101736@2x.png

    回答: 2025-02-27 10:29


    已经跟测试人员电话沟通过了,记录如下:

    1.正常验证码逻辑是,登录输错验证码,会提示验证码错误,5次也没有问题。这时,测试人员会抓包,把参数中的验证码参数删除,模拟请求,这时,服务端应该提示“请输入验证码”或“验证码不能为空”,现在是提示“用户名密码错误”相当于是没有先进行验证码的校验;

    2.验证码刷新问题:目前是用户点一下验证码,前端主动调后端验证码刷新接口进行了更新;测试人员会抓包攻击,把同一个验证码重复使用(没有主动调后端刷新接口),发现还可以使用;应该提示“验证码已经失效”这样的。

    你说的那个我们还没有加。


    作者追问:2025-02-27 10:33

    麻烦加下试试看呢

    CleanShot20250227103243@2x.png

    回答: 2025-02-27 15:27

    按指导加上del后,测试人员回复:
    还有点小问题,&grant_type=captcha&scope=all&type=account 请求头参数删除就不校验验证码了,其它没问题了,前面几张图是对比,请求头参数判断下就行了,不应提示“用户名密码不对”,应为:“请输入验证码”

    图:1:36da8d4c60b46fba0c05017d15844af.png

    图2:c8d837b4770d0b2e2af541c044dc452.png

    图3:

    6615750a1010b7cda1808173f78dec3.png

    -------------------------------------
    图4(未通过):
    9de2b3f82ab638527ba1030a32d8205.png

    0 讨论(0)
代码语言
提交回复