前段时间dedecms等爆出各种0day，一时手痒，于是找了个小的php开源程序开刀
过程中用到的工具：
phpxref ：Windows下很好用的php代码审计辅助工具
Grep ：linux下来查找关键语句
跟踪程序：
从index.php入手一路跟踪：
到这里发现在安装完程序之后修改了index.php首页代码：
位置：/iwebshop/install/include/ -> function.php
下面是该应用程序url的一个范例：
http://172.16.7.2/iwebshop/index.php?controller=simple&action=login
其中关键的是controller和action键值，整个程序的php文件目录都是按照controller和action的名称进行整合的。
整个应用程序逻辑可以简化为：
1.创建IWebApplication类对象a，a中包含一个指向整个app的config属性数组
位置：/iwebshop/lib/ -> iweb.php
2.调用a的execRequest()方法获取url信息，创建控制器controller对象b，此时将a本身作为参数带入。
位置：/iwebshop/lib/core/ -> webapplication_class.php
3.在b的run()方法中创建action对象c（这里产生的是视图对象）
位置：/iwebshop/lib/web/controller/ -> controller_class.php
4.运行c中run()方法找到视图.html文件，运行b中的render方法进行渲染，在runtime文件夹中生成渲染后的php文件并返回给浏览器，至此完成基本的一套流程。 HdhCmsTest2cto测试数据
问题在于在调用渲染函数renderView中
程序直接将渲染后的文件包含进来并返回。
我们查看runtime/site/index.php源代码
可以看到title中的内容直接输出为<?php echo $siteConfig->name; ?>，未经过任何过滤，那我们查看config.php中Config类是如何定义的，$site_config的内容是什么。
位置：/iwebshop/classes/ -> config.php
又以上可以看出$siteConfig = ($this->config)->getInfo的内容，在我的环境中其实就是config/site_config.php，注意"name"字段。
由此可见，只要想办法将name字段修改为xss payload，一个持久性的xss就在全站形成了（所有前台的view页面都包含title字段）。经过不懈努力，发现name字段其实可以通过后台来修改。
最后效果：
修改方式：
在渲染函数中对输出内容净化
总结：
由于是不常见的php开源应用程序，因此存在较多问题是很正常的，因为输出到页面前程序没有任何过滤措施导致xss，我相信该app中存在同样问题的绝不止title一处地方，而且从输入也没有过滤来看该app还可能存在sql注入，需要进一步挖掘。
这个 漏洞 本身相当鸡肋，目前证明最简单的方式是需要到后台修改网站title，至于是否还有其他利用方法尚不得而知，写这篇文章的目的也仅仅是阶段性记录一下以供参考。
查看更多关于iwebshop xss 0day代码分析 - 网站安全 - 自学php的详细内容...