判断是否有注入漏洞

打开一个带参数的判断网址，在参数后面加个单引号，注入页面报错直接甩出一串SQL语句——这种站基本可以判死刑了。漏洞我见过太多人把判断注入漏洞想得太复杂，判断其实第一步就是注入看它会不会“说话”。数据库报错信息就像案发现场的漏洞指纹，明晃晃摆在那，判断不利用白不利用。注入

拿个真实例子来说。漏洞去年帮朋友看一个电商后台，判断商品筛选参数是注入 ?cat=3。我改成 ?漏洞cat=3'，页面立刻返回 You have 判断an error in your SQL syntax near '3'' at line 1。这不是注入漏洞是什么？连盲注都不用试，直接报错注入就能把库名跑出来。漏洞但很多人到这步就停了，觉得“报错而已，不一定能利用”。错。报错本身就是确认漏洞存在的铁证，剩下的只是时间问题。

没有报错怎么办？那就看页面行为。数字型注入最典型：?id=2 正常，?id=2 and 1=1 正常，?id=2 and 1=2 返回空或不一样的内容。三个请求一对比，逻辑就浮出来了。我习惯用 and sleep(5) 测时间盲注，页面卡住五秒才响应，那基本没跑。但注意，有些站用了CDN或者本身响应就慢，得先测个基线——请求十次取平均，再对比注入后的延迟。别一看到慢就兴奋，我吃过这亏，白高兴一场。

还有种情况是参数被过滤了。比如你输 ' 被转义成 \'，或者直接给你删掉。这时候别急着放弃，试试宽字节。GBK编码下 %df' 可能把反斜杠吃掉，让单引号逃逸出来。我上次遇到一个站，单引号被转义，但 %df%27 直接报错，说明后端用的是GBK。这种细节靠工具扫不出来，得手动试。

工具能帮上忙，但别全信。sqlmap跑一遍说“not injectable”就真没漏洞？我至少遇到过三次sqlmap漏报的情况。一次是参数在Cookie里，一次是POST的JSON体，还有一次是二次注入——输入点不在当前页面，而在后续的某个查询里。工具再智能也覆盖不了所有业务逻辑。自己抓包看请求，比什么都靠谱。

判断注入漏洞的核心就一句话：看用户输入有没有被当成代码执行。单引号、双引号、反斜杠、括号、逗号，这些字符扔进去，观察页面是正常、报错、还是行为异常。别想太多花哨的，先做最基础的字符探测。一个参数一个参数试，一个请求一个请求看。我见过有人上来就上编码绕过、分块传输，结果连最基本的 ' 都没试过。顺序反了。

最后说个反直觉的：不是所有报错都代表有注入。有些站故意返回假报错，或者用了WAF返回拦截页面。你得看报错内容是不是数据库原生的。MySQL的 You have an error in your SQL syntax 和 WAF 的 Blocked by security policy 是两码事。分清楚这个，能省很多无用功。