验证码对SQLMap完全无效，因其不走表单流程而直接构造HTTP请求绕过前端交互；真正防御需从参数化查询做起，再叠加WAF、限流与错误屏蔽。
验证码对SQLMap完全无效，加了反而暴露接口脆弱性；真正有效的防御必须从代码层参数化查询开始，再叠加WAF规则、请求限流和错误屏蔽。
为什么SQLMap能绕过验证码
SQLMap不走表单提交流程，也不渲染页面——它直接构造HTTP请求，比如向 /api/user?id=1%27%20OR%201%3D1-- 发起GET请求。整个过程不依赖Cookie、不触发JS、不加载图片资源，验证码服务压根收不到调用。更危险的是，有些团队把验证码校验逻辑写在前端（如用JS解密token），结果被逆向后，整个机制形同虚设。
参数化查询必须覆盖所有数据库操作点
短链服务、搜索接口、导出接口、详情页这些未鉴权路径，恰恰是SQLMap最爱扫的地方。只要有一个地方漏掉参数化，整套防御就失效。
- Node.js + pg：必须用
client.query("SELECT * FROM links WHERE short_code = $1", [code])，禁用client.query("SELECT * FROM links WHERE short_code = '" + code + "'") - Python + pymysql：用
cursor.execute("SELECT long_url FROM links WHERE short_code = %s", (code,))，不要用f"WHERE short_code = '{code}'" - Java + JDBC：必须用
PreparedStatement，stmt.setString(1, code)是安全的，"WHERE short_code = '" + code + "'"是高危的
Nginx层拦截高频恶意请求
SQLMap扫描时典型特征是：几秒内密集发送带 ' OR 1=1--、UNION SELECT、information_schema 的请求，User-Agent固定、无Cookie、IP集中。靠应用层日志分析已太晚，必须在入口处卡住。
- 在Nginx配置中定义限流区域：
limit_req_zone $binary_remote_addr zone=sqlscan:10m rate=3r/s - 对疑似路径启用严格限制：
location ~* ^/api/.*\.(id|q|search)=下加limit_req zone=sqlscan burst=5 nodelay - 配合WAF规则检测URL中是否含
SELECT.*FROM或@@version等高危字符串，命中即返回403
关闭错误回显并隔离验证码服务
生产环境一旦返回 psycopg2.errors.UndefinedTable 或 MySQLdb._exceptions.ProgrammingError 这类信息，等于告诉SQLMap“这里能报错，继续试”。而更隐蔽的风险是验证码服务本身——如果它和主业务共享数据库连接池，或在日志里拼接用户输入（如 logger.info(f"captcha req for {user_input}")），就可能引发二次注入。
- 数据库驱动配置中关闭详细错误：pymysql加
autocommit=True, connect_timeout=3，避免超时触发堆叠异常 - 验证码服务必须独立部署，不复用主库连接池，不读取业务session上下文
- 绝对禁止用用户输入生成文件名或URL路径，例如
/captcha/abc123?sql=SELECT%20*这种写法会把payload明文写进CDN日志
最常被忽略的一点：参数化查询不是“用了就完事”，而是必须覆盖每一个动态拼接SQL的分支——包括异常处理里的日志语句、缓存键生成逻辑、甚至后台定时任务的查询。SQLMap只找最薄弱的那个点，它不会因为你99%的地方都安全就手下留情。
