第12章 攻入目标网站后台！（2/2）

但是，当他尝试注入不同信息时，返回的结果居然一样。

这说明，这个网站的代码里虽然存在注入点，但已做了参数类型检查，把字符串类型的注入漏洞堵住了。

他又尝试在链接里加“%27”之类的URL编码绕过，照样失败。

只能再换手段。

他把目标转向站内搜索框。

刚才他已发现，对方用的是GET方式提交，关键词直接出现在网址里。

他在搜索词里加了一段代码，试图把数据库里的数据强行显示在网页上，但页面返回了一片空白。

他又换了好几个常见的表名去试，比如“用户”、“会员”、“管理员”之类的，全都不行。

这说明，这个搜索功能可能屏蔽了这类操作，或者是数据库里根本没有常用表名。

但他毫不气馁。

他再次更换目标。

这次是留言板。

在留言内容里夹带了一段网页脚本代码，提交。

页面弹出一个提示框。

很明显，站长在这方面已经做了预防。

林子恒却没放弃。

因为他注意到，留言板的网址里有一个“页码”参数。

page=1。

他把“page=1”改成“page=1”“ad”“1=1”，页面正常显示。

改成“page=1”“ad”“1=2”，页面报错了。

这说明，这个页码参数存在一个数字型的注入漏洞。

他来了精神，开始用排序语句逐列试探这个查询返回了多少列数据。

试到按第6列排序的时候页面报错，说明查询结果一共是5列。

然后他开始构造数据提取语句。

先试着从数据库的系统表里面提取信息。

——如果网站用的是某种大型数据库的话，这个系统表里记录着所有用户表的名字。

页面正常返回了数字，没有报错。

说明后台确实用的是那种大型数据库。

但系统表里的具体内容没有在页面上显示出来，可能是网页模板只取了第一行数据来展示。

他换了一种写法，去探测系统表里是否存在用户创建的表，页面返回正常。

说明确实存在用户表。

然后他开始一个一个地猜表名。

试到“会员”的时候，页面出现了异常——说明这个表是存在的。

接着猜字段名，试到“用户名”和“密码”的时候都出现了异常。

表名和字段名都确认了。

他开始构造最终的攻击语句，让网页把会员表里第一条记录的用户名和密码显示出来。

页面刷新。

这一次，原本显示数字的位置，变成了“adi”和一串32位的字符串。

字符串是用户密码经过加密处理后的哈希值。

成了。

林子恒长长出了口气。

他拿到了管理员的账号和密码哈希值。

虽然哈希值无法还原，但他并不需要管理员密码。

既然已经能够操控数据库里的查询语句，他就可以直接往数据库里插入一条新的管理员记录，把自己的账号加进去。

但是这样容易触发警报，他选择先稳一手。

他先记下网站程序文件的物理路径，然后在URL里用“../”之类的路径序列跳出网站根目录，去访问服务器系统目录下的日志文件。

再通过读取日志的最后更新时间，来判断管理员是否在线。

很幸运！

管理员并不在线，而且是下午五点多离线的。

现在已是晚上八点四十，管理员应该不会上线了。

结论：今晚就是最佳动手时间！

林子恒立即创建一个新账号，再给这个账号赋予网站管理员权限。

重新登录该帐号，发现页面多出一个链接：管理员入口。

点击进入。

页面切换以后，看到了服务器后台！