测试前必须确认三件事：数据库账户仅具SELECT权限、测试库为脱敏副本并明确命名、所有请求走专用测试接口路径。
测试前必须确认的三件事
直接对生产环境或含真实用户数据的库做注入测试，等于主动制造风险。真正安全的测试，前提是环境隔离、权限受限、操作可逆。别跳过这一步——很多“测试中误删表”的事故，就卡在没确认这三点。
-
数据库账户必须只拥有SELECT权限，禁用DROP、INSERT、UPDATE、EXECUTE等写操作权限； - 测试库必须是
从生产库脱敏导出的副本，且明确标记为test_db_202608这类可识别名称，避免误连； - 所有测试请求必须走
专用测试接口路径（如/api/v1/test/login），不能复用线上路由，防止缓存或监控混淆。
用只读载荷验证注入点是否存在
目标不是执行破坏，而是判断输入是否被拼进SQL并被执行。用不会改数据、但能暴露逻辑漏洞的载荷，比' OR '1'='1更稳妥。
- 数字型参数（如
?id=1）试：?id=1 AND SLEEP(0.5)—— 延迟响应说明后端未参数化，且数据库支持SLEEP； - 字符型参数（如
?name=admin）试：?name=admin' AND '1'='1和?name=admin' AND '1'='2—— 观察返回结果是否出现“有/无数据”的布尔差异； - 统一加
--+注释符收尾（如?q=test'--+），避免因引号闭合不匹配导致语法错误掩盖真实行为； - 禁用
UNION SELECT类载荷——它需要知道列数和类型，易触发报错或写入日志，且与“不破坏数据”目标冲突。
检查响应内容而非错误信息
数据库错误页面（如MySQL error: You have an error in your SQL syntax）是强信号，但现代应用通常屏蔽它。更可靠的判断依据是响应体的逻辑变化。
- 对比正常请求和载荷请求的
HTTP状态码、响应体长度、JSON字段结构是否一致； - 若接口返回列表，用
' OR '1'='1后返回100条记录，而正常只返回1条，说明WHERE条件被绕过——这是注入存在的直接证据； - 注意时间盲注：连续发送
SLEEP(1)和SLEEP(0)，用curl -w "%{time_total}"测响应时长，差值>0.8秒即需警惕； - 别依赖
error_log或slow_query_log——它们可能关闭，或日志级别不够，响应行为才是最真实的反馈源。
自动化测试必须绕开的两个坑
工具如sqlmap默认启用--dump或--os-shell，哪怕加了--safe-url也难保万全。手动控制才真正可控。
- 运行
sqlmap -u "http://test/api?uid=1" --batch --level=1 --risk=1 --technique=B—— 限定只用布尔型盲注（B），禁用U（联合查询）、T（时间盲注）、E（报错注入）； - 永远加
--fresh-queries，避免缓存干扰判断； - 禁止使用
--drop-table、--sql-query、--os-pwn等任何带副作用的选项； - 如果CI流程里跑自动化扫描，确保
SQLMAP_OUTPUT_DIR指向空目录，并在脚本末尾加rm -rf $SQLMAP_OUTPUT_DIR清理痕迹。
真正的安全测试不靠暴力探测，而靠对输入边界和响应语义的精细观察。最容易被忽略的，是把“没报错”当成“没漏洞”——很多注入根本不出错，只悄悄改变业务逻辑的执行路径。
