验证码对SQL注入攻击完全无效，因其仅验证操作者是否为人类，而自动化工具如sqlmap直接构造恶意HTTP请求绕过前端交互；真正有效的防护是参数化查询、WAF规则匹配、限流及关闭错误回显。
SQL注入自动化攻击根本拦不住验证码
验证码对SQL注入攻击完全无效。它只验证“操作者是否为人类”，而自动化SQL注入工具（比如 sqlmap）根本不走登录或表单提交流程——它们直接构造恶意HTTP请求，绕过前端交互，也压根不渲染页面、不触发验证码弹窗。
真正该拦截的是无状态高频请求
自动化SQL注入扫描器的典型行为是：在几秒内密集发送带 ' OR 1=1--、UNION SELECT 等payload的GET/POST请求，目标往往是同一接口路径（如 /api/user?id=）。这类流量没有Session、没有Cookie、User-Agent固定、IP来源集中。
- 用Web应用防火墙（WAF）规则匹配常见SQL关键字 + 异常参数格式，比如检测
SELECT.*FROM或information_schema出现在URL参数里 - Nginx层可配置限流：
limit_req_zone $binary_remote_addr zone=sqlattack:10m rate=5r/s，再配合limit_req对疑似路径（如含id=、q=的GET）启用严格限制 - 后端中间件（如Express/Koa）中，在解析查询参数前先检查
req.query和req.body是否包含高危字符串，命中即记录并返回403
验证码反而会暴露业务漏洞位置
如果只在登录页加验证码，却放任搜索接口、详情接口、导出接口等未鉴权路径接受任意SQL payload，攻击者会立刻意识到：“这里没防护，直接扫”。更糟的是，有些团队把验证码校验逻辑写在前端（比如用JS解密token），结果被逆向后，整个机制形同虚设。
- 验证码必须服务端校验，且一次有效、有时效（如120秒）、绑定session或临时token
- 不要只为“看起来安全”而加验证码；要优先做参数化查询——所有数据库操作必须用
PreparedStatement（Java）、pg.query绑定参数（Node.js/pg）、cursor.execute(sql, params)（Python/DB-API） - 关闭数据库错误回显：生产环境禁止把
psycopg2.errors.UndefinedTable或MySQLdb._exceptions.ProgrammingError这类信息透出到HTTP响应体
别让防御手段变成新的攻击面
见过最危险的做法，是用验证码图片的文件名存SQL payload，比如生成 /captcha/abc123?sql=SELECT%20*%20FROM%20users ——这等于把攻击载荷明文写进URL日志和CDN缓存里。
- 验证码服务必须与主业务隔离，不能共享数据库连接池或用户上下文
- 避免在验证码逻辑里拼接用户输入，哪怕只是用来打日志；
logger.info(f"captcha req for {user_input}")就可能引发二次注入 - 如果用了图形验证码，确保字体、噪点、扭曲逻辑不依赖外部可控参数，否则可能触发ImageMagick远程代码执行（CVE-2016-3714）
真正的防护水位不在验证码，而在你有没有把每个请求参数都当成不可信输入来处理。只要有一个接口忘了用 parameterized query，其他所有防御都会变成马奇诺防线。
