https://xedczq.cn/tags/%E9%AA%8C%E8%AF%81%E7%A0%81/Recent content in 验证码 on XEDCZQ的博客Hugo -- gohugo.iozh-cnSat, 20 Jun 2026 00:00:00 +0800https://xedczq.cn/post/web_logincaptchaspec/Sat, 20 Jun 2026 00:00:00 +0800https://xedczq.cn/post/web_logincaptchaspec/<h1 id="web-登录验证码规范从老后台排查到-redis-一次性校验"><a href="#web-%e7%99%bb%e5%bd%95%e9%aa%8c%e8%af%81%e7%a0%81%e8%a7%84%e8%8c%83%e4%bb%8e%e8%80%81%e5%90%8e%e5%8f%b0%e6%8e%92%e6%9f%a5%e5%88%b0-redis-%e4%b8%80%e6%ac%a1%e6%80%a7%e6%a0%a1%e9%aa%8c" class="header-anchor"></a>Web 登录验证码规范：从老后台排查到 Redis 一次性校验 </h1><p>这篇笔记记录我最近围绕 Web 管理端登录验证码做的一次完整排查和改造。事情的起点很简单：我想确认老服务器上的后台验证码到底是不是“真的在校验”，以及新版 <code>web_3</code> 应该把验证码流程收敛成什么样，才算一套真正完整的登录安全链路。</p> <p>这次我主要做了三件事：</p> <ul> <li>排查老服务器 <code>yzdwx.yizhoudao.net/admin/</code> 的验证码真实逻辑</li> <li>确认老 Web 是否真的启用了 Redis</li> <li>在本地 <code>web_3</code> 里把管理端验证码改成“后端生成 + Redis 存储 + 后端一次性校验”</li> </ul> <p>最后的结论也很明确：<strong>老后台页面上虽然有验证码，但登录流程里没有真正校验它；新版 <code>web_3</code> 已经改成标准的 Redis 验证码闭环。</strong></p> <h2 id="我为什么要单独整理这篇笔记"><a href="#%e6%88%91%e4%b8%ba%e4%bb%80%e4%b9%88%e8%a6%81%e5%8d%95%e7%8b%ac%e6%95%b4%e7%90%86%e8%bf%99%e7%af%87%e7%ac%94%e8%ae%b0" class="header-anchor"></a>我为什么要单独整理这篇笔记 </h2><p>验证码这种东西很容易出现一种假安全状态：页面上明明有输入框，也有验证码图片，前端看起来一切都在，但真正决定安全性的不是页面上有没有控件，而是后端登录逻辑到底有没有做验证，以及验证结果有没有被一次性消费。</p> <p>这次排查让我更确定一件事：<strong>登录验证码必须按“生成、存储、提交、校验、销毁”这五步闭环来设计，缺任何一步都不算真正落地。</strong></p> <h2 id="老服务器后台验证码的真实逻辑"><a href="#%e8%80%81%e6%9c%8d%e5%8a%a1%e5%99%a8%e5%90%8e%e5%8f%b0%e9%aa%8c%e8%af%81%e7%a0%81%e7%9a%84%e7%9c%9f%e5%ae%9e%e9%80%bb%e8%be%91" class="header-anchor"></a>老服务器后台验证码的真实逻辑 </h2><p>这次我先通过 SSH 登录老服务器，只做了只读排查，没有改线上代码，也没有重启服务。</p> <p>我定位到的站点信息是：</p> <ul> <li>域名 <code>yzdwx.yizhoudao.net</code> 对应站点目录：<code>/www/wwwroot/yzdwx5.weitaibei.com/public_html</code></li> <li>应用入口：<code>/www/wwwroot/yzdwx5.weitaibei.com/public_html/index.php</code></li> <li>实际业务代码目录：<code>/www/wwwroot/yzdwx5.weitaibei.com/system/application</code></li> </ul> <p>接着我去看后台登录页模板，确认页面上确实有验证码输入框和验证码图片。页面会请求：</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">/captcha </span></span></code></pre></div><p>点击刷新时会请求：</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">/captcha?random=... </span></span></code></pre></div><p>这个路由最终来自 ThinkPHP 的验证码包。继续往下追，我确认到：</p> <ul> <li>验证码图片确实是后端生成的</li> <li>验证码答案会写入 <code>Session</code></li> <li>不是写在前端，也不是直接写入 Redis</li> </ul> <p>更关键的是，我继续追到后台登录控制器之后发现，老后台登录方法虽然接收了 <code>$verify</code> 参数，但实际逻辑里只做了这些事：</p> <ul> <li>用户名判空</li> <li>密码判空</li> <li>调用 <code>rbaclogin(...)</code></li> </ul> <p>我没有看到任何真正的验证码校验逻辑，比如：</p> <ul> <li><code>captcha_check($verify)</code></li> <li><code>validate(...captcha...)</code></li> <li>手动对比验证码答案</li> </ul> <p>所以老服务器后台验证码的真实情况其实是：</p> <ul> <li>页面上有验证码</li> <li>后端也会生成验证码图片</li> <li>验证码答案保存在 <code>session</code></li> <li>但登录业务流程里没有真正校验它</li> </ul> <p>这意味着老版本后台的验证码大概率属于一种“界面还在，但校验已经失效或被漏掉”的状态。</p> <h2 id="我是怎么确认这件事的"><a href="#%e6%88%91%e6%98%af%e6%80%8e%e4%b9%88%e7%a1%ae%e8%ae%a4%e8%bf%99%e4%bb%b6%e4%ba%8b%e7%9a%84" class="header-anchor"></a>我是怎么确认这件事的 </h2><p>这次排查不是靠猜，也不是只看前端页面，而是按一条比较稳的链路逐步确认的。</p> <p>我先确认 SSH 和站点目录：</p> <ul> <li>先通过本机 SSH 别名连到服务器</li> <li>查 Nginx 配置，确认 <code>yzdwx.yizhoudao.net</code> 实际指向哪个目录</li> <li>查 PHP-FPM 和 Nginx 运行状态</li> </ul> <p>然后我再往应用层追：</p> <ul> <li>找后台登录模板</li> <li>找 <code>/captcha</code> 路由来源</li> <li>找验证码生成逻辑</li> <li>找验证码校验逻辑</li> </ul> <p>最后我再去看后台登录控制器：</p> <ul> <li>看 <code>login()</code> 方法是否真正调用了验证码校验</li> <li>结果是没有</li> </ul> <p>这个顺序的好处是不会被页面表现误导。只要登录控制器里没有执行验证码校验，那页面上验证码画得再完整，也只是“视觉存在”，不是“安全生效”。</p> <h2 id="老-web-到底有没有用-redis"><a href="#%e8%80%81-web-%e5%88%b0%e5%ba%95%e6%9c%89%e6%b2%a1%e6%9c%89%e7%94%a8-redis" class="header-anchor"></a>老 Web 到底有没有用 Redis </h2><p>这部分我也专门确认了一遍，因为很多项目都会出现一种情况：代码里带着 Redis 封装类，但线上根本没启用。</p> <p>这次我的结论是：</p> <ul> <li>代码仓里确实有 Redis 工具类</li> <li>但线上这套老 Web 没查到业务代码实际调用它</li> <li>服务器本身也没发现 Redis 服务在运行</li> </ul> <p>我当时主要查了几类证据：</p> <ul> <li>ThinkPHP 的 session 配置</li> <li>PHP 的 <code>session.save_handler</code></li> <li><code>/tmp</code> 下是否存在大量 <code>sess_*</code> 文件</li> <li>服务器上是否有 <code>redis-server</code></li> <li>是否有 <code>redis-cli</code></li> <li>是否监听了 <code>6379</code></li> </ul> <p>最终确认到的事实是：</p> <ul> <li>Session 默认驱动不是 Redis</li> <li>PHP 当前会话处理器是 <code>files</code></li> <li><code>/tmp</code> 下确实存在大量 <code>sess_*</code> 文件</li> <li>服务器上没发现 Redis 进程</li> <li>没发现 <code>6379</code> 监听</li> <li>也没发现 Redis 二进制</li> </ul> <p>所以更准确的说法不是“老项目完全没有 Redis”，而是：</p> <blockquote> <p>老项目带过 Redis 封装代码，但当前运行中的老站没有实际启用 Redis，后台验证码也不在 Redis 里。</p> </blockquote> <h2 id="老版本验证码的问题到底出在哪"><a href="#%e8%80%81%e7%89%88%e6%9c%ac%e9%aa%8c%e8%af%81%e7%a0%81%e7%9a%84%e9%97%ae%e9%a2%98%e5%88%b0%e5%ba%95%e5%87%ba%e5%9c%a8%e5%93%aa" class="header-anchor"></a>老版本验证码的问题到底出在哪 </h2><p>如果用一句话概括老后台的问题，我会说：</p> <blockquote> <p>它的问题不是“验证码生成失败”，而是“验证码没有进入真正的登录校验链路”。</p> </blockquote> <p>也就是说，旧系统表面上像是有验证码防护，但真正的登录安全流程里并没有用到它。这个问题比“没有验证码”更隐蔽，因为产品、测试甚至开发自己都可能先被页面骗过去。</p> <p>从规范角度看，老版本至少有两个明显缺口：</p> <ul> <li>验证码答案存进了 Session，但登录接口没有校验</li> <li>验证码不是一次性消费，即使以后补校验，也容易留下复用问题</li> </ul> <h2 id="我在本地-web_3-改成了什么逻辑"><a href="#%e6%88%91%e5%9c%a8%e6%9c%ac%e5%9c%b0-web_3-%e6%94%b9%e6%88%90%e4%ba%86%e4%bb%80%e4%b9%88%e9%80%bb%e8%be%91" class="header-anchor"></a>我在本地 web_3 改成了什么逻辑 </h2><p>确认完老系统问题之后，我在本地 <code>web_3</code> 管理端把验证码流程改成了完整的后端闭环。</p> <p>现在的流程是：</p> <ol> <li>前端请求 <code>GET /api/admin/login/captcha</code></li> <li>后端生成： <code>captchaId</code> <code>4</code> 位验证码 <code>Base64 PNG</code> 图片</li> <li>后端把验证码答案写入 Redis</li> <li>前端只展示图片，同时保留 <code>captchaId</code></li> <li>用户登录时，前端提交： <code>username</code> <code>userpwd</code> <code>captchaId</code> <code>captchaCode</code></li> <li>后端先去 Redis 校验验证码</li> <li>校验时使用 <code>getAndDelete</code></li> <li>读取成功后立即删除</li> </ol> <p>这个设计意味着一个验证码只有一次尝试机会。</p> <p>无论最终登录成功还是失败，这个验证码都会失效，不会继续留在系统里被重复提交。</p> <h2 id="新版验证码链路的核心规范"><a href="#%e6%96%b0%e7%89%88%e9%aa%8c%e8%af%81%e7%a0%81%e9%93%be%e8%b7%af%e7%9a%84%e6%a0%b8%e5%bf%83%e8%a7%84%e8%8c%83" class="header-anchor"></a>新版验证码链路的核心规范 </h2><p>结合这次改造，我把 Web 登录验证码应该遵守的规范总结成下面这几条。</p> <h3 id="规范-1验证码必须由后端生成"><a href="#%e8%a7%84%e8%8c%83-1%e9%aa%8c%e8%af%81%e7%a0%81%e5%bf%85%e9%a1%bb%e7%94%b1%e5%90%8e%e7%ab%af%e7%94%9f%e6%88%90" class="header-anchor"></a>规范 1：验证码必须由后端生成 </h3><p>验证码图片、验证码答案和 <code>captchaId</code> 都必须由后端统一生成。前端只负责展示，不参与答案生成，也不保存正确答案。</p> <p>这样可以避免前端暴露正确结果，保证校验基准只存在于服务端。</p> <h3 id="规范-2验证码答案必须保存在短期存储中"><a href="#%e8%a7%84%e8%8c%83-2%e9%aa%8c%e8%af%81%e7%a0%81%e7%ad%94%e6%a1%88%e5%bf%85%e9%a1%bb%e4%bf%9d%e5%ad%98%e5%9c%a8%e7%9f%ad%e6%9c%9f%e5%ad%98%e5%82%a8%e4%b8%ad" class="header-anchor"></a>规范 2：验证码答案必须保存在短期存储中 </h3><p>这次我选的是 Redis。它很适合这种短时、一次性、低价值但安全敏感的数据。</p> <p>相比 <code>session/file</code>，Redis 更适合后续扩展：</p> <ul> <li>可以设置 TTL</li> <li>可以做原子删除</li> <li>可以支持多机共享</li> <li>可以承接登录风控类临时状态</li> </ul> <h3 id="规范-3登录接口必须在鉴权前先校验验证码"><a href="#%e8%a7%84%e8%8c%83-3%e7%99%bb%e5%bd%95%e6%8e%a5%e5%8f%a3%e5%bf%85%e9%a1%bb%e5%9c%a8%e9%89%b4%e6%9d%83%e5%89%8d%e5%85%88%e6%a0%a1%e9%aa%8c%e9%aa%8c%e8%af%81%e7%a0%81" class="header-anchor"></a>规范 3：登录接口必须在鉴权前先校验验证码 </h3><p>验证码校验不能放在一个“看起来有，但不影响主流程”的边缘位置。它必须在用户名密码真正进入登录鉴权前完成。</p> <p>也就是说，顺序应该是：</p> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="cl">先校验验证码 </span></span><span class="line"><span class="cl">再校验账号密码 </span></span><span class="line"><span class="cl">最后建立登录态 </span></span></code></pre></div><p>如果验证码失败，后面的账号密码逻辑就不应该继续执行。</p> <h3 id="规范-4验证码必须一次性消费"><a href="#%e8%a7%84%e8%8c%83-4%e9%aa%8c%e8%af%81%e7%a0%81%e5%bf%85%e9%a1%bb%e4%b8%80%e6%ac%a1%e6%80%a7%e6%b6%88%e8%b4%b9" class="header-anchor"></a>规范 4：验证码必须一次性消费 </h3><p>这次我专门用了 <code>getAndDelete</code> 这种读取即删除的方式，目的是确保验证码永远只能用一次。</p> <p>这个约束非常重要，因为如果验证码校验通过后不立刻销毁，就可能出现：</p> <ul> <li>同一验证码被重复利用</li> <li>自动化脚本反复撞同一个验证码</li> <li>失败重试时复用旧验证码</li> </ul> <p>一次性消费是验证码机制真正生效的关键之一。</p> <h3 id="规范-5成功和失败都要失效"><a href="#%e8%a7%84%e8%8c%83-5%e6%88%90%e5%8a%9f%e5%92%8c%e5%a4%b1%e8%b4%a5%e9%83%bd%e8%a6%81%e5%a4%b1%e6%95%88" class="header-anchor"></a>规范 5：成功和失败都要失效 </h3><p>很多人只会在“登录成功”时删验证码，但这其实还不够。</p> <p>更稳的做法是：</p> <ul> <li>校验成功后立即删除</li> <li>校验失败也要删除</li> </ul> <p>因为验证码本来就是一次挑战，不应该允许用户拿着同一个 <code>captchaId</code> 连续试很多次。</p> <h2 id="这次改成-redis-后我认为最实际的好处"><a href="#%e8%bf%99%e6%ac%a1%e6%94%b9%e6%88%90-redis-%e5%90%8e%e6%88%91%e8%ae%a4%e4%b8%ba%e6%9c%80%e5%ae%9e%e9%99%85%e7%9a%84%e5%a5%bd%e5%a4%84" class="header-anchor"></a>这次改成 Redis 后，我认为最实际的好处 </h2><p>这次改造给我的直接感受，不是“技术更高级了”，而是整个登录安全链路终于闭合了。</p> <p>主要好处有这些：</p> <h3 id="逻辑闭环完整"><a href="#%e9%80%bb%e8%be%91%e9%97%ad%e7%8e%af%e5%ae%8c%e6%95%b4" class="header-anchor"></a>逻辑闭环完整 </h3><p>老版本是“有验证码页面，但登录不校验”。</p> <p>现在变成了：</p> <ul> <li>后端生成</li> <li>后端存储</li> <li>前端展示</li> <li>后端校验</li> <li>一次性消费</li> </ul> <p>这才是一条完整的安全链路。</p> <h3 id="不再依赖本地-session-文件"><a href="#%e4%b8%8d%e5%86%8d%e4%be%9d%e8%b5%96%e6%9c%ac%e5%9c%b0-session-%e6%96%87%e4%bb%b6" class="header-anchor"></a>不再依赖本地 session 文件 </h3><p>老站的验证码答案实际落在 <code>session/file</code> 和 <code>/tmp sess_*</code> 上。</p> <p>这套方案虽然在单机环境里能跑，但它天然更偏运行时实现，不够适合后续扩展。Redis 对这类短期临时数据更合适，也更容易观察和控制。</p> <h3 id="一次性验证码更自然"><a href="#%e4%b8%80%e6%ac%a1%e6%80%a7%e9%aa%8c%e8%af%81%e7%a0%81%e6%9b%b4%e8%87%aa%e7%84%b6" class="header-anchor"></a>一次性验证码更自然 </h3><p>Redis 很适合实现这种需求：</p> <ul> <li>TTL 过期</li> <li><code>getAndDelete</code></li> <li>成功失败都删除</li> </ul> <p>这些语义在验证码场景里非常自然，不需要绕很多额外逻辑。</p> <h3 id="多机部署更友好"><a href="#%e5%a4%9a%e6%9c%ba%e9%83%a8%e7%bd%b2%e6%9b%b4%e5%8f%8b%e5%a5%bd" class="header-anchor"></a>多机部署更友好 </h3><p>如果以后不是单机，而是多台 Web 共同处理请求，那么 <code>session/file</code> 很容易出现跨机器不一致问题。</p> <p>Redis 作为共享存储，可以让所有 Web 节点读到同一份验证码状态，这对后续扩容非常关键。</p> <h3 id="后续风控能力更容易接上"><a href="#%e5%90%8e%e7%bb%ad%e9%a3%8e%e6%8e%a7%e8%83%bd%e5%8a%9b%e6%9b%b4%e5%ae%b9%e6%98%93%e6%8e%a5%e4%b8%8a" class="header-anchor"></a>后续风控能力更容易接上 </h3><p>验证码逻辑进入 Redis 之后，很多安全相关能力也更容易继续往上加，比如：</p> <ul> <li>短信验证码</li> <li>登录失败次数限制</li> <li>风控计数</li> <li>临时 token</li> <li>AI/RAG 相关短期缓存</li> </ul> <p>从工程上看，这相当于把“登录临时态”统一收进了一个更适合治理的位置。</p> <h2 id="这次我顺手做的配套工作"><a href="#%e8%bf%99%e6%ac%a1%e6%88%91%e9%a1%ba%e6%89%8b%e5%81%9a%e7%9a%84%e9%85%8d%e5%a5%97%e5%b7%a5%e4%bd%9c" class="header-anchor"></a>这次我顺手做的配套工作 </h2><p>为了让新版 <code>web_3</code> 本地链路真正跑通，这次我还顺手处理了几项配套问题：</p> <ul> <li>本地临时启动了一个 Redis，监听 <code>127.0.0.1:6379</code></li> <li>修了 <code>backend-java</code> 启动时的 YAML 配置问题</li> <li>清理了后端端口占用</li> <li>把管理端前端改成支持局域网访问，监听 <code>0.0.0.0:9511</code></li> <li>调整了登录页移动端和窄屏适配</li> </ul> <p>这些改动虽然不是验证码主逻辑，但它们决定了整个方案能不能从“代码写好了”真正走到“本地完整跑通”。</p> <h2 id="我最后得出的规范结论"><a href="#%e6%88%91%e6%9c%80%e5%90%8e%e5%be%97%e5%87%ba%e7%9a%84%e8%a7%84%e8%8c%83%e7%bb%93%e8%ae%ba" class="header-anchor"></a>我最后得出的规范结论 </h2><p>这次排查和改造之后，我对 Web 登录验证码的规范要求基本固定成下面这套：</p> <ol> <li>验证码必须由后端生成</li> <li>验证码答案必须只保存在后端</li> <li>前端只展示图片和提交 <code>captchaId</code></li> <li>登录接口必须先校验验证码，再校验账号密码</li> <li>验证码必须一次性消费</li> <li>成功失败都必须失效</li> <li>短期验证码优先放 Redis，而不是依赖本地 session 文件</li> </ol> <p>如果少了其中任何一条，我都不会认为这套验证码是真正“规范落地”的。</p> <h2 id="小结"><a href="#%e5%b0%8f%e7%bb%93" class="header-anchor"></a>小结 </h2><p>一句话总结这次工作：</p> <blockquote> <p>老服务器后台验证码是 ThinkPHP 后端生成、保存到 Session，但后台登录代码里没有真正校验它；老服务器当前也没有实际运行 Redis。新版 <code>web_3</code> 则已经改成标准的 Redis 验证码流程：后端生成、Redis 保存、前端展示、后端校验、一次性消费、成功失败都删除。</p> </blockquote> <p>对我来说，这次最重要的收获不是“把验证码改成 Redis”这么简单，而是把验证码这件事从“页面上看起来有”推进到了“后端链路真正闭环”。只有做到这一点，验证码才不是装饰，而是登录安全的一部分。</p>