把单引号塞进输入框，何判页面直接甩给你一个500错误——这不是断否巧合，这是注入数据库在喊救命。去年我帮一个做电商的漏洞朋友看站点，商品详情页URL里有个 id=1024，何判我改成 id=1024'，断否回车，注入屏幕上蹦出一行MySQL语法错误，漏洞连表名都带出来了。何判漏洞就在那儿，断否明晃晃的注入，像没关的漏洞门。

判断SQL注入，何判最直接的断否办法就是让输入打破SQL语句原有的结构。数据库对语法错误非常敏感，注入你塞一个单引号进去，它要么报错，要么行为异常。这是第一层信号。但别只盯着报错，有些站点把错误吞了，页面照常显示，只是内容变了——比如原本该显示商品的地方变成空白，或者列表少了几条。这种“沉默的异常”更值得警惕。

报错、布尔、时间，三条路

报错注入最好认。输入 ' 或 "，看返回里有没有 SQL syntax、mysql_fetch、ORA- 这类字样。有，基本可以确定参数没过滤就进了查询。我见过一个后台登录框，用户名填 admin'--，密码随便，直接进去了。这就是典型的闭合引号加注释，把后面的密码校验整段干掉。

如果错误被屏蔽了，换布尔盲注的思路。构造两个请求，一个真一个假，看页面差异。比如 id=1 AND 1=1 和 id=1 AND 1=2。前者正常返回，后者空内容或报错，说明注入点存在。这招对数字型参数特别灵。字符串型就麻烦点，得先猜闭合方式，是单引号、双引号还是括号。我一般先试 ' AND '1'='1，再试 ' AND '1'='2，对比响应长度。差几个字节都算线索。

时间盲注是最后的手段。页面既不报错也不变内容，那就让数据库睡一会儿。id=1 AND SLEEP(5)，如果请求卡了五秒才回来，漏洞跑不掉。MySQL用 SLEEP()，SQL Server用 WAITFOR DELAY '0:0:5'，PostgreSQL用 PG_SLEEP(5)。这方法慢，但准。我测过一个内网系统，布尔和时间都试了，最后靠 SLEEP 确认的。当时盯着浏览器转圈，五秒一到，心里就有数了。

工具能帮你，但别全信

sqlmap这类工具确实省事，sqlmap -u "http://target.com/page?id=1" 跑一遍，它自动试各种payload。但工具不是万能的。我遇到过参数做了Base64编码的，sqlmap默认不认，得加 --tamper 脚本或者手动解码再注入。还有的站点上了WAF，一发包就封IP，这时候得手工调payload，绕关键字过滤，比如用 /*!50000SELECT*/ 这种内联注释。

手工判断的核心就一句话：让输入参与SQL逻辑，观察数据库反应。反应可以是报错、内容变化、延迟，甚至是HTTP状态码的细微差别。别只试一个参数，URL里的、表单里的、Cookie里的、HTTP头里的 User-Agent 和 Referer，都可能是入口。我见过一个站，URL参数过滤得死死的，结果 X-Forwarded-For 头没处理，直接注进去了。

最后提醒一句，测试前确认你有授权。没授权就对着别人站点塞单引号，那不叫技术，叫找事。自己搭个DVWA或者sqli-labs练手，靶场里随便折腾。真实环境里，一个 ' 可能就是事故的开始。