Iwebshop xss 0day code analysis

Some time ago, dedecms and so on broke out a variety of 0-day cases, so I found a small php open-source program to open the knife.

Tool used in the process: phpxref: a useful php code audit auxiliary tool in Windows Grep: linux to find the key statement version: iwebshop2.3.11113010 tracking program: From index. php tracks all the way: here we found that the index was modified after the program was installed. php homepage code: Location:/iwebshop/install/include/-> function. below is an example of the application url in php: http: // 172.16.7.2/iwebshop/index. php? Controller = simple & action = login. The key values are controller and action. The php file directory of the entire program is integrated according to the name of controller and action. The entire application logic can be simplified to: 1. create IWebApplication Class Object a. a contains a config attribute array location pointing to the entire app:/iwebshop/lib/-> iweb. php 2. call the execRequest () method of a to obtain url Information and create controller object B. In this case, a is taken as a parameter.
Location:/iwebshop/lib/core/-> webapplication_class.php 3. create action Object c in the run () method of B (the view object is generated here) Location:/iwebshop/lib/web/controller/-> controller_class.php 4.run the run( to the video .html file in c, run the render method in B for rendering. In the runtime folder, generate the rendered PHP file and return it to the browser. This completes a basic set of processes. The problem with www.2cto.com lies in calling the rendering function renderView.


The program directly includes the rendered file and returns it. We can view the source code of runtime/site/index. php. We can see that the content in the title is directly output as <? Php echo $ siteConfig-> name;?>, Without any filtering, we can see how the config class is defined in Config. php and what is the content of $ site_config. Location:/iwebshop/classes/-> config. php can see the $ siteConfig = ($ this-> config)-> getInfo content. In my environment, it is actually config/site_config.php. Pay attention to the "name" field. It can be seen that as long as you try to change the name field to xss payload, a persistent xss is formed throughout the site (all front-end view pages contain the title field ). After unremitting efforts, we found that the name field can be modified in the background. Final effect: Modification Method: In the rendering function, the output content is purified. Summary: because it is an uncommon php open-source application, it is normal to have many problems, xss is caused by no filtering measures in the program before output to the page. I believe that there are more than one title in this app, in addition, the app may still have SQL injection because the input is not filtered, and further mining is required. This vulnerability is quite weak. Currently, it is proved that the simplest method is to modify the website title in the background. It is not clear whether there are other methods to use it, the purpose of writing this article is to record it in stages for your reference.