记一次简单代码审计:挖掘存储XSS打管理Cookie
我的代码审计也是刚刚上路,对于使用量大的CMS来说还无能为力,只能挖挖小的web程序漏洞。OK下面转入正题:拿下一个服务器,上面有十来个网站,在上面发现一个个人博客网站,asp+access,做的比较简单,以前也没怎么见过。
这类简单且使用量小的web程序存在漏洞的可能性是非常大的,于是就down下源码,本地搭建环境开始审计,白盒+黑盒。
首页是这个样子,简单的页面,简单的网站。
先随便翻翻,看看有没有sql注入之类的,打开一篇文章如下图。看到url,是个标准的数字型参数查询。随手用单引号、and 1=1测试了一下,均返回到首页面去了,看来是做了一定的防注入。那么下面就看看它的代码层是怎么处理的。
根据URL,找到位于根目录下的bonews.asp文件,重点看id参数处理,这里直接转到id参数处理部分的代码。可以看到参数ID以request方式传入,然后紧接着以:if id=”” or not IsNumeric(id)做了一次过滤。
这里要说一下,request方式包含get/post/cookie三种方式(可能表述不准确,但意思就是这里id参数以get/post/cookie三种方式中的任意一种传入,都能执行成功)。如果它的防注入仅仅是过滤其中一种方式传入的参数(比如只针对GET方式传入过滤),那么我们就可以换一种提交方式进行注入,不过本例不成功。
转到过滤语句:if id=”” or not IsNumeric(id)。首先判断id是否为空,然后用IsNumeric函数判断传入的id参数是否为数字型,如果这两个判断任意一个为真,哪么就结束程序执行。怪不得我们前面测试单引号和and 1=1不成功了。试了一下将id参数和注入语句组合转换为十六进制,提示访问错误无果。百度了一下,发现这个isnumeric函数对于数字型注入貌似无解,遂放弃。
又看了另外两个页面,发现都是传入ID参数,同样用isnumeric()做了过滤,遂放弃挖SQL注入漏洞思路(当然仔细找找可能会找到,不过楼主这里就没有深挖了)
看到文章下面有一个在线留言框,于是尝试看看这里会不会有什么漏洞?
直接转到相应的HTML代码。根据form表单中的action指向,可知处理提交内容的程序为/admin/adhuifu_fox.asp文件。根据textarea框中的name值可知提交内容后,程序会将其转换为数组,提交内容对应的key值为”jianjie”。
下面转到/admin/adhuifu_fox.asp文件,来到它处理提交参数的地方。从下面的处理过程可知非常简单。只是用trim()函数去掉前后空格,然后用replace函数将单引号替换成反引号,这个处理只对sql注入可能有点用(当然如果结合宽字节注入的话这点过滤也是不够的),但对于XSS则完全没有防范了。
再继续往下,来到这里。可知这段程序将提交的内容更新到了数据库中的huifu表中去了(这里发散一下,如果在回复显示那里直接从数据库中查询我们提交内容对应的键值”jianjie”,那么如果之前提交一个注入语句到数据库中去,哪么就可以控制它查询出来的结果了!就和帝国CMS留言回复的注入类似!!@#33)。
OK,顺着上面的思路回到bonews.asp文件,来到查询huifu表的地方。很不幸对于huifu表的查询并没有查询jianjie字段,只查询了newsid字段,so这个思路就不通了。
好吧,那下面就试试XSS吧。因为前面已经发现,对于留言内容的处理很简单,只过滤了单引号。所以这里就提交一个<script>alert(/xss/)</script>进去看看。OK,弹出了预想中的框框,是个存储性XSS。
当然光弹出这个框是不够的,还要能对实际渗透有点作用才行。
来到后台留言管理页面,同样也弹出了个东东。
哪么下面就可以构造打管理员cookie的XSS了~~~~!在XSS平台上生成一个短连接,留言回复上去。然后后台管理员账户登录到留言管理处看看,再回到XSS平台,就收到了管理的cookie了。。。
好了这次简单审计就差不多了,对于审计大牛来说非常简单。我也是刚入门水平,SO这里仅是简单分享。当然可能有人会说这种简单XSS漏洞直接黑盒测试就出来了,在留言框插入一个XSS,就能判断是否存在漏洞。但这里要说的是,知其然还要知其所以然,能挖洞但不知漏洞原理没法持久提高。 又要有一波网站因为xss要沦陷了 感谢LZ分享。讲的很细心 作为小白受教了 不错,还是灰盒测试比较省力 楼主详细
知其然还要知其所以然,能挖洞但不知漏洞原理没法持久提高。 说的太对了 收藏了,楼主霸气
涨姿势了
加油,学习我也像学习
页:
[1]