sql注入测试网址

把`' or 注址1=1 --`塞进搜索框，页面居然弹出了所有用户数据。入测这不是试网电影情节，是注址我上周在某个政府公开查询系统上干的事——当然，是入测在授权范围内。很多人以为SQL注入是试网十几年前的老古董，但OWASP 2021年报告里，注址它依然稳坐“注入类漏洞”头把交椅。入测原因很简单：开发者太信任输入框了。试网

测试网址这事，注址说穿了就是入测跟数据库玩“猜谜游戏”。你提交一个特殊字符串，试网看它会不会被当成SQL代码执行。注址最经典的入测实验场是登录框。正常输入`admin`和密码，试网后台跑的是`SELECT * FROM users WHERE name='admin' AND pass='xxx'`。可如果你在用户名栏填`admin'--`，密码随便打，SQL就变成了`SELECT * FROM users WHERE name='admin'--' AND pass='xxx'`。两个横线把后面的密码验证全注释掉了，系统直接放行。我第一次在本地搭环境试成功时，后背发凉——就这么简单？就这么简单。

找测试网址有个笨办法：用搜索引擎搜`php?id=`之类的参数链接。但别急着上手，先分清授权边界。自己搭个靶场，或者用公开的漏洞测试平台（比如DVWA、WebGoat），比对着真实网站瞎试安全得多。我见过有人拿学校选课系统练手，结果被网信办约谈，那叫一个惨。测试的本质是验证，不是破坏。就算你是白帽子，也得先拿到书面授权。

具体怎么测？先扔单引号`'`。如果页面报错，或者返回和正常请求不一样的空白页，说明参数可能拼接进了SQL。再试试`' and 1=1`和`' and 1=2`。前者返回正常数据，后者啥也没有——这就实锤了。你构造的条件被数据库执行了。这时候别得意，赶紧记录注入点，用`union select`探测字段数，一步步把表结构摸出来。整个过程像开锁，先试钥匙齿形，再试弹子深度。

有个细节容易被忽略：有些网址会用JSON传数据，或者把参数藏在Cookie里。我遇到过某个后台接口，GET参数过滤得铁桶一样，但Cookie里的`session_id`直接拼进SQL。换了个注入位置，整个库就裸奔了。所以别只盯着地址栏，用Burp Suite抓包，把所有请求点都过一遍。POST表单、请求头、甚至文件上传的文件名，都可能成为突破口。

防护手段其实不玄乎。参数化查询是标配，但很多遗留系统改不动代码。那就上WAF，可WAF也有绕过技巧——用`/*!50000union*/`这种内联注释，或者把关键字拆成`un/**/ion`，老式正则过滤就懵了。当然，这些话我只对授权测试的人说。你要是拿不到许可，趁早收手。技术本身没善恶，但用错地方就是另一回事了。

测试完记得清理痕迹。删掉测试用的临时表，关掉错误日志输出，最好把数据库连接字符串改一下。我习惯写个自动化脚本，测完自动恢复原状。这不是胆小，是职业素养。去年某大厂漏洞报告平台收到个SQL注入提交，提交者顺手把用户表导出了一份——结果漏洞赏金没拿到，反而被起诉了。边界感这东西，比技术本身重要得多。

最后说个反常识的事：很多注入漏洞不是技术菜，是业务逻辑懒。比如导出功能，开发者图省事，直接把前端传来的排序字段拼进`ORDER BY`。这种地方过滤最容易漏。你测的时候多留意那些“不太像数据库交互”的功能点——导出、打印、图表筛选，往往藏着惊喜。找漏洞跟找钥匙一样，别光盯着正门，窗户和排气扇才是突破口。