最直接的判断依据是参数后加单引号观察是否返回含数据库引擎关键词的错误；若无报错则用and 1=1/and 1=2比对响应差异探测布尔盲注；再无差异时用sleep函数测时间延迟，同时覆盖get、post、cookie、header等所有用户可控输入点。
先看单引号是否触发数据库错误
最直接的判断依据是：在任意参数后加一个 '，观察响应。如果返回类似 You have an error in your SQL syntax、mysql_fetch_array() 或 ORA-00936 这类明确带数据库引擎关键词的错误，基本可以确认存在未过滤的拼接点。
注意不是所有报错都算数——400 Bad Request、500 Internal Server Error 但无SQL关键词，大概率是上层框架拦截或输入校验失败，不等于SQL注入可利用。
- GET参数如
?id=1'、?name=test'最容易试 - POST body 中的
username、email字段也要同样加' - 别漏掉
Cookie和User-Agent头，有些业务逻辑真会拿它们拼SQL
用 and 1=1 / and 1=2 看响应差异
单引号没报错，不代表安全。很多应用开了错误屏蔽，这时得靠布尔逻辑探测。
构造两个请求：?id=1 and 1=1 和 ?id=1 and 1=2，对比返回内容是否一致（不只是状态码，要看页面主体、JSON字段值、HTTP响应长度）。如果一个返回正常数据、另一个返回空列表/跳转/空白页，说明后端SQL执行结果被直接映射到了输出，存在布尔盲注可能。
- 数字型参数直接试
1 and 1=1；字符型需闭合，比如?name=admin' and 1=1-- - 注意 MySQL 的
--后必须带空格，PostgreSQL 用--或/* */，SQL Server 支持--和; - 响应差异可能很细微：比如某处多一个
admin字符、少一行 div、JSON里某个字段从true变成false
试试 sleep() 判断时间盲注
当页面既不报错也不显布尔差异时，时间延迟是最后防线。核心思路是：让数据库执行耗时操作，看响应时间是否显著增长。
典型 payload：?id=1 and if(1=1,sleep(5),0)（MySQL）、?id=1 AND pg_sleep(5)（PostgreSQL）、?id=1 WAITFOR DELAY '0:0:5'（SQL Server）。用 curl 或 Burp 的 Timer 功能测响应时间，对比基线（比如正常请求平均 120ms），若某次超 4.8s，基本坐实。
- 别一上来就
sleep(10)，先从sleep(3)开始，避免触发WAF超时规则或服务端限流 - 部分WAF会拦截含
sleep的关键字，可尝试编码：%73%6c%65%65%70（sleep 的 hex）或大小写混写：SLEEP/sLeEp - 时间差要排除网络抖动，建议连续发 3 次，取中位数
别只盯着URL，检查所有用户可控输入点
SQL注入点远不止 ?id=。现代应用里，真正高危的往往是那些“看起来不重要”的位置。
除了常规 GET/POST 参数，必须覆盖：Cookie 中的 sessionid、user_token；HTTP Header 中的 X-Forwarded-For、Referer（有些日志功能真会把它插进 INSERT）；甚至 JSON body 里的 {"filter": "xxx"} —— 只要后端用 string.format 或 + 拼接 SQL，就危险。
- 用 Burp Suite 的 Proxy History 过一遍所有请求，标记出所有非固定值的字段
- 对 multipart/form-data 类型请求，每个
Content-Disposition: form-data; name="xxx"都要单独测试 - XML 请求里
<query>xxx</query>这种节点值，和 JSON 一样处理
真实场景里，最易被忽略的是二次注入：你第一次提交的数据看似被“安全存储”了，但后续某个报表导出接口会把它原样拼进 SELECT。这种链路式漏洞，光扫单点根本发现不了。
