web漏洞实验

我把一个带搜索框的洞实网站当靶子，输入了' or 洞实1=1 --，回车。洞实页面没报错，洞实反而吐出了全部用户数据。洞实那一刻我后背发凉——不是洞实因为这个技巧多高明，而是洞实因为我知道，这个漏洞在真实世界里可能躺了十年没人管。洞实

那次实验是洞实在本地虚拟机里做的，目标是洞实个老旧的图书管理系统。代码写得像 spaghetti，洞实查询直接拼接字符串。洞实我本来只想测试一下，洞实结果第一发就中了。洞实管理员账号的洞实密码哈希就明晃晃地躺在结果里，像一块没上锁的蛋糕。

漏洞实验最迷人的地方在于，它逼你像攻击者一样思考。你得先问：这个输入框的数据会流向哪里？是拼进 SQL 语句，还是塞进 HTML 页面？是变成文件路径的一部分，还是被 eval 当代码执行？每个入口都是一扇门，门后可能连着数据库、文件系统，甚至整台服务器的 shell。

有个实验我印象特别深——XSS 盲打。我在一个留言板里塞了段 JavaScript，脚本会把当前页面的 cookie 发到一个我控制的服务器。提交后页面毫无反应，好像什么都没发生。但几小时后，我打开自己的服务器日志，发现一条来自管理后台的请求。管理员中招了，他的会话令牌正躺在我的日志里。那一刻我意识到：攻击不一定要即时反馈，它可以是潜伏的，像水渗进墙缝。

但漏洞实验也不全是“打进去”的快感。更多时候是枯燥的排查。你得把请求包翻来覆去地改，用 burp 的 repeater 一遍遍重放，观察响应里的细微差别。有时候一个漏洞的触发条件苛刻到近乎玄学——需要特定编码、特定浏览器、甚至特定时间的请求。我花过整整一个下午，就为了验证一个文件上传点是否真的能绕过扩展名过滤。最后发现，把.jpg改成.jsp%00.jpg就能过，但前提是服务器跑的是老版本 Tomcat。这种知识是“脏”的，书本上不写，全靠踩坑。

实验做完，我习惯性地把漏洞写成报告。但真正让我觉得有价值的，不是那几行修复建议，而是实验过程中建立起来的“直觉”。比如看到参数名是id，会下意识想：这地方能不能拼注入？看到页面回显了用户名，会琢磨：这地方转义了没？这种条件反射不是看教程能练出来的，得亲手把漏洞触发一次，看它在你面前炸开，你才记得住。

当然，实验和真实攻击之间隔着一条法律线。我在自己的虚拟机里怎么折腾都行，但一旦把同样的请求发到别人的网站上，性质就变了。我认识一个朋友，当年因为好奇对一个公开站点做了次简单的 SQL 注入测试，结果被对方安全团队盯上，差点惹上官司。他说：“我以为我只是看看，但对方不这么想。”这话我一直记着。

最后说个细节。每次实验结束，我都会清空所有日志，重置数据库，把环境恢复原样。这个习惯来自一次教训——我在实验后忘了清理上传的 webshell，结果第二天打开虚拟机，发现 CPU 占用 100%，那台机器被人拿去挖矿了。漏洞实验教会我的第一课不是怎么攻，而是怎么收拾残局。攻击是技术，善后是责任。