postman可真实触发sql注入，需测试报错型（' or 1=1--）、时间盲注（and sleep(5)--）和联合查询（union select...）三类payload，并覆盖url、form-data、header及json嵌套等所有输入入口。
直接用Postman发恶意payload，别信“它只是测试工具”
Postman不是玩具，它是能真实触发后端SQL执行链路的HTTP客户端。只要你的API接收用户输入并拼接进SQL，admin' OR '1'='1这种输入就可能让查询逻辑崩坏。别假设“测试环境没连真库就安全”——很多测试环境数据库权限和生产一样，甚至更松；也别觉得“前端有校验就没事”，Postman绕过前端校验只需改Body或Query参数。
构造注入测试用例必须覆盖这三类payload
只测' OR '1'='1远远不够。真实攻击者会根据报错、响应时间、布尔结果做判断，所以你得模拟这三类行为：
-
' OR 1=1--：用于触发报错型或注释掉后续条件，重点观察是否返回异常数据（如所有用户）、是否返回数据库错误堆栈 -
' AND SLEEP(5)--：MySQL下验证时间盲注，检查响应延迟是否明显超过正常值（注意服务端是否启用了wait_timeout或连接池超时干扰） -
' UNION SELECT username,password FROM users--：联合查询注入，看响应体是否混入了其他表字段内容（需确保原查询有结果集且列数匹配）
在Pre-request Script里批量生成变体，避免手动填10个请求
手动改10次Body效率低还容易漏。用Postman的pre-request script动态注入不同payload，比如：
// 在集合的pre-request script中
const payloads = [
"admin' OR '1'='1",
"admin' AND 1=2-- ",
"admin' UNION SELECT 1,2,3-- ",
"admin' AND (SELECT COUNT(*) FROM information_schema.tables) > 0-- "
];
pm.environment.set("sql_payload", payloads[pm.iteration % payloads.length]);
然后在请求Body里写{{sql_payload}}。这样跑Collection Runner时，每次迭代自动换payload，还能配合Tests脚本断言响应是否含敏感字段或状态码异常。
关键陷阱：别忽略Content-Type和参数位置
SQL注入不只发生在JSON Body里。很多开发者只防了POST /login的Body，却忘了这些地方：
- URL Query参数：
GET /api/user?id=1' OR '1'='1—— 检查路由层是否做过滤 - Form-data字段：
Content-Type: multipart/form-data里的username字段同样危险 - Header注入：
X-User-ID: admin' OR '1'='1—— 如果后端从Header取值拼SQL，照样中招 - JSON数组嵌套：
{"filters": [{"field": "name", "value": "a' OR '1'='1"}]}—— 深层字段常被ORM或框架忽略校验
真正难防的不是单点，而是开发时默认信任“这个参数不会进SQL”。防御验证必须覆盖所有用户可控输入入口，哪怕它看起来“不该进数据库”。
