sql注入自测核心是用攻击者视角构造输入、防御者逻辑验证响应：对/user/{id}等接口，通过/user/123'触发报错判断字符串型，/user/123-1比对结果判断数字型；json字段重点观察500错误、延迟响应或布尔差异；须警惕动态表名、排序字段及mybatis ${}等绕过参数化的高危点，并覆盖二阶注入的“写→存→读→用”全链路。
开发人员自测 API 接口是否存在 SQL 注入，核心在于“用攻击者视角构造输入，但以防御者逻辑验证响应”——不是等安全团队报漏洞，而是把 1' OR 1=1 -- 这类载荷当成单元测试用例跑一遍。
怎么判断一个 POST /user/{id} 是数字型还是字符串型注入点
先看路由和参数位置：URL 路径里的 {id} 通常由框架解析为路径变量（如 Spring 的 @PathVariable），它是否被拼进 SQL，取决于你代码里怎么用。别猜，直接查源码中类似 "SELECT * FROM user WHERE id = " + userId 或 query("SELECT ... WHERE id = " + id) 的写法。
实操建议：
- 对
/user/123发起请求，再试/user/123'—— 如果返回 500 或数据库错误，大概率是未过滤的字符串拼接；如果返回空或 404，可能已做类型转换或预编译 - 试
/user/123-1：若返回与/user/122相同数据，说明后端把路径段当表达式计算了，是典型数字型拼接漏洞 - 检查日志：哪怕没报错，只要看到类似
WHERE id = 123-1这样的原始 SQL 被打印出来，就等于主动交出了证据
JSON Body 中的字段怎么快速验注入（比如 {"user_id": 123}）
Body 参数最难自动识别，因为框架不会像 query 参数那样显式暴露键名。SQLMap 的 --data 能发，但开发自测要更轻量：用 curl 或 Postman 手动改值，重点盯三类响应变化。
常见错误现象：
- 填
{"user_id": "123' AND '1'='1"}后接口返回 500，且响应体含MySQLSyntaxErrorException或psycopg2.ProgrammingError - 填
{"user_id": "123' AND SLEEP(3)"}（MySQL）或{"user_id": "123'; WAITFOR DELAY '0:0:3'"}（MSSQL），响应延迟明显超过正常 RT - 填
{"user_id": "123 AND 1=1"}和{"user_id": "123 AND 1=2"}，返回内容长度或 HTTP 状态码不同（布尔盲注信号）
注意：Spring Boot 默认会把 JSON 字段反序列化为 Integer，所以 "123'" 可能直接 400 Bad Request —— 这反而是好事，说明类型校验挡在了 SQL 前面。
为什么用参数化查询还可能中招？关键看执行链路
参数化本身没错，但错在“你以为用了，其实没用到真正执行的位置”。最典型的坑是动态表名、列名、排序字段——JDBC 的 PreparedStatement 不支持占位符用于这些位置。
使用场景与风险点：
-
SELECT * FROM ? WHERE status = ?→ 第一个?会直接报错，必须字符串拼接，这里就是高危区 -
ORDER BY ?→ 同样不支持，若从请求取sort=user_id拼进 SQL，sort=user_id, (SELECT password FROM users LIMIT 1)就成了注入入口 - MyBatis 的
${xxx}vs#{xxx}：前者原样替换，后者才预编译。搜代码里所有${，逐个确认是否白名单控制
性能影响：用 String.format() 或 concat() 拼接 SQL 再交给 PreparedStatement，等于白做——JDBC 驱动根本收不到“参数”，只收到一条完整字符串。
开发自测时最容易忽略的二阶注入点
一阶注入好测，输什么看回显就行；二阶注入藏在“数据写入后再读出”的链路里，比如用户注册时填的昵称，后续在后台报表导出时被拼进 SQL。
可操作步骤：
- 在任意写入接口（注册、编辑资料、评论）提交 payload：
'||(SELECT substr(password,1,1) FROM users WHERE id=1)||'（适配 SQLite/PostgreSQL） - 找一个读取该数据的接口（如
GET /api/v1/profile或后台管理页），观察响应是否包含数据库错误或异常内容 - 特别注意日志记录点：很多系统把用户输入原样写进审计日志表，而报表服务又从日志表查数据生成 SQL —— 这条链路常被遗忘
复杂点在于，二阶触发往往跨请求、跨服务、甚至跨数据库；自测时必须顺着业务流走完“写→存→读→用”全路径，不能只卡在单个 endpoint。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
