上周三凌晨两点，测试我盯着终端里滚动的网站日志，sqlmap正在对一个本地搭建的测试DVWA靶场发起布尔盲注。屏幕上跳出一行字：Parameter: id (GET)，网站紧接着是测试数据库版本号。那一刻我意识到，网站这工具真能把一个看似正常的测试URL拆得底朝天。

sqlmap不是网站新东西。它用Python写的测试，命令行界面，网站黑底白字。测试很多人第一次跑它，网站直接甩一个-u "http://test.com/page.php?测试id=1"，然后看着它自动判断注入类型、网站猜表名、测试爆字段。整个过程像看一台挖掘机作业——你指个位置，它自己决定从哪下铲子。

但真正让我觉得有意思的，是它对HTTP请求的“理解”方式。你给它一个带参数的URL，它先发一堆探测请求，观察响应差异。比如布尔盲注，它对比id=1 AND 1=1和id=1 AND 1=2的页面长度变化。时间盲注更粗暴，直接塞SLEEP(5)，看服务器卡不卡。这种“用响应反推逻辑”的思路，比很多扫描器硬匹配特征库要聪明。

我试过一个带WAF的站点。sqlmap默认的User-Agent是sqlmap/1.7#stable，刚发第一个请求就被拦了。加--random-agent，换掉UA，又试了--delay=2降低频率，还是不行。后来用--tamper=space2comment，把空格转成/**/，居然绕过去了。这种插件机制挺实用，tamper脚本目录下几十个文件，每个都是针对特定过滤规则的变形技巧。

不过sqlmap不是万能钥匙。有次我拿它测一个用参数化查询的接口，跑了半小时，它把所有注入类型试了一遍，最后报all tested parameters do not appear to be injectable。这反而是好事——说明代码写对了。工具的价值在于快速排除，而不是保证一定能挖出洞。

它的--os-shell功能争议挺大。一旦拿到数据库权限，可以尝试上传shell、执行系统命令。我在虚拟机里试过，成功弹回一个低权限的www-data shell。但真实环境里，数据库用户往往被限制得死死的，FILE权限没有，secure_file_priv指向空目录，这条路基本堵死。所以别把它当入侵神器，它更像一个验证漏洞存在性的探针。

输出格式也值得一说。默认的表格显示在终端里，列宽自动调整。加--batch后全程无交互，适合塞进脚本里跑。我习惯用--output-dir=/tmp/sqlmap把每次会话的日志和dump数据分开存。有次翻旧日志，发现半年前跑的一个站，当时没注意的User-Agent字段里居然藏着注入点——sqlmap当时只测了GET参数，没管Header。后来手动加--level=3才覆盖到。

速度方面，默认配置下它很克制。并发线程数、请求间隔都有保守值。想快就加--threads=10，但目标站扛不住的话，响应会变成超时或503。我一般先跑--smart模式，只做基础检测，确认有戏再上--risk=3加大payload强度。盲目拉满参数，除了把目标打挂，没什么好处。

最后说个细节。sqlmap的--flush-session经常被忽略。它会清掉之前缓存的会话数据，强制重新检测。有次我改了一个站的Cookie值，忘了加这个参数，结果sqlmap一直用旧缓存里的注入点信息，跑出来的结果全是错的。这种坑踩过一次就记住了。

工具终究是工具。它把手工注入的繁琐步骤自动化了，但判断哪里该测、测到什么程度、结果是否可信，还是得靠人。我见过有人拿sqlmap扫完一个站，报告里写“存在SQL注入”，却说不清是哪个参数、什么类型、能读到什么数据。那还不如不扫。