如何查找sql注入漏洞
一个登录框，何查输入 ' or 找s注入1=1 --，页面直接跳进了后台。漏洞这不是何查电影桥段，是找s注入我三年前帮朋友看一个老商城系统时遇到的真实情况。SQL注入没死，漏洞只是何查藏得更深了。想找到它，找s注入得先学会像开发者一样思考，漏洞再像攻击者一样动手。何查
找注入点，找s注入第一步永远是漏洞摸清数据入口。URL里的何查 ?id=1、表单里的找s注入搜索框、Cookie里的漏洞 user_token、甚至HTTP头里的 X-Forwarded-For，只要后端拿它拼过SQL语句，就是潜在目标。我习惯先扔个单引号进去，看报错不回显。比如 product.php?id=5'，如果页面蹦出 You have an error in your SQL syntax，基本就中奖了。没报错也别急，试试 id=5' AND '1'='1 和 id=5' AND '1'='2，对比返回内容长度或状态码，布尔盲注的线索往往藏在这些细微差异里。
手工测太慢，工具该上就上。sqlmap 是绕不开的，但别上来就 -u 一把梭。先 --batch --level=3 --risk=2 跑一遍，观察它判断的注入类型。有次我遇到一个过滤了空格的站，sqlmap默认payload全挂，换成 --tamper=space2comment 才跑通。工具不是万能的，它只是替你发请求，逻辑还得自己盯。Burp Suite 的 Repeater 更适合细调，把请求丢进去，手动改参数，看响应时间变化——时间盲注里 WAITFOR DELAY '0:0:5' 这种，页面卡不卡那五秒，比任何报错都诚实。
别只盯着GET和POST。JSON接口现在遍地都是，{ "username":"admin' --"} 这种照样能打。还有那些藏在 order by 后面的参数，比如 sort=price desc，开发觉得这不是用户输入，其实照样能注。我见过一个站，搜索框过滤得严严实实，但排序参数直接拼进 ORDER BY，用 sort=(case when 1=1 then price else name end) 就能盲注出数据。这种边角料位置，扫描器经常漏掉。
报错注入是效率最高的路子。MySQL里 extractvalue(1,concat(0x7e,database())) 直接把库名怼在报错信息里。MSSQL用 convert(int,@@version)。前提是站点没关错误回显。现在很多框架默认生产环境不报错，那就转盲注。布尔盲注写脚本跑，二分法猜字符，一个库名跑十分钟正常。时间盲注更慢，但没得选的时候只能靠 if(ascii(substr(database(),1,1))>100,sleep(3),0) 这种硬等。
防御方也不是吃素的。WAF会拦 union select，那就拆成 union/**/select，或者用 /*!50000union*/ 这种MySQL内联注释。大小写混写、URL编码、十六进制替换，都是绕过手段。但别沉迷绕WAF，先确认漏洞存在，再考虑怎么绕。有次我花两小时绕一个云WAF，最后发现后端根本没用预编译，直接 id=1+union+select+1,2,3 就出了数据——WAF只拦了 union select 中间带空格的写法。
最后说个反直觉的：别只测数字型。字符型注入里，admin' -- 这种经典payload现在经常被过滤，试试 admin'# 或者 admin'/*。还有，别忘了看源代码。GitHub上泄露的 .sql 文件、前端JS里硬编码的查询逻辑，比黑盒猜快得多。我上次审计一个系统，直接在前端JS里找到 "/api/getUser?id="+id，顺藤摸瓜，五分钟就确认了注入。
找注入漏洞，本质是找开发者偷懒的地方。预编译没上、过滤不严、权限过大，三者占一个，就有戏。工具能帮你省力，但眼睛和脑子不能省。