sqlmap注入网站

sqlmap跑完第一轮测试，注入屏幕上跳出“Parameter: id (GET)”的网站时候，我心里就有数了——这站八成有戏。注入那是网站个普通的新闻页面，URL后面挂着?注入id=1024，页面显示的网站是某条新闻的标题和正文。我随手把1024改成1024'，注入回车，网站页面直接甩回来一个MySQL语法错误。注入这种反应，网站老手都懂，注入不是网站过滤没做好，就是注入压根没过滤。

sqlmap用起来其实没那么玄乎。网站把URL往命令里一塞，注入加个--batch让它自己跑，剩下的就是看它怎么一步步把数据库拆开。第一次跑的时候我习惯加-v 3，看看它到底在发什么包。它先试了布尔盲注，页面返回正常和异常的长度差了几十字节，这就算确认了注入点存在。接着它开始猜列数，用ORDER BY一直试到报错，大概第五列的时候页面崩了，说明这表有四列。

然后就是UNION注入的环节。sqlmap会自动构造UNION SELECT，把1,2,3,4逐个替换成database()、user()、version()这些函数。我盯着终端，看到它吐出来当前数据库叫“news_db”，用户是“root@localhost”，MySQL版本5.7.26。看到root的时候我愣了一下，这配置也太糙了——网站用root连数据库，等于把整栋楼的钥匙插在门锁上。

接下来它开始枚举表。--tables参数一加，sqlmap从information_schema里把表名全捞出来。news_db下面有七张表：articles、users、comments、admin_logs、sessions、config、upload_records。我看到users表的时候手指在键盘上停了一下。果然，--dump -T users -C username,password一跑，三条记录直接拍在屏幕上。密码是MD5，32位，拿去cmd5一查，两个已经解出来了，一个是“admin123”，另一个是“qwerty2020”。

这时候其实已经可以收工了。但我想看看admin_logs里有什么，毕竟表名摆在那儿。--dump -T admin_logs --where="id>100" LIMIT 20，出来的记录让我有点意外——登录IP全是127.0.0.1，时间集中在凌晨三点到五点。这说明管理员要么在本地操作，要么用了代理，而且习惯半夜干活。这种细节，扫描器不会告诉你，得自己去看。

sqlmap有个--os-shell参数，在MySQL root且secure_file_priv为空的情况下能直接拿系统命令执行权限。我试了一下，它往网站根目录写了个tmpbqk.php，然后访问，返回一个类似终端的界面。whoami出来是www-data，不是root，说明Web服务和数据库不在同一台机器上，或者PHP跑在低权限用户下。这反而让我松了口气——要是真拿到root，这站的问题就大到没法收场了。

整个过程里sqlmap最耗时的不是注入本身，是它默认的测试范围太广。--level 5 --risk 3会把时间盲注、堆叠查询全试一遍，一个参数能跑十几分钟。我一般先用--smart快速过一轮，确认注入类型后再针对性调参。比如确认是UNION注入，就直接--technique=U，跳过其他四种方式，速度能快十倍不止。

有个细节值得说：sqlmap在跑的时候会往请求里塞各种payload，有些WAF会直接封IP。我遇到过一家用安全狗的站，跑到第三轮就被ban了，返回403。后来加了--delay=2 --random-agent才勉强跑完，但速度慢得让人想砸键盘。所以真要对线上站动手，--proxy和--tor得提前配好，不然就是给自己找麻烦。

最后说个真实案例。去年帮朋友看一个企业站，sqlmap跑出来注入点在搜索框的keyword参数上。数据库是SQL Server，sa权限。--os-shell直接弹了个cmd，net user一看，服务器上还挂着远程桌面。朋友当时脸都白了——这站外包给第三方做的，交付后半年没打过补丁。我让他赶紧关站，把数据库密码全换掉，再把那个外包公司拉黑。sqlmap只是把门推开，门后面有什么，得看运维平时有没有上心。