因爲工做緣由，分析了不少的cms也都寫過文章，不過以爲好像沒什麼騷操做都是網上的基本操做，因此也就沒發表在網站上，都保存在本地。最近忽然發現本身博客中實戰的東西太少了，決定將之前寫的一些文章搬過來，因爲當時寫的初4是給本身留個記錄，之後方便查看，因此寫的都很簡單，只有代碼審計和復現，沒有詳細寫挖掘中遇到的一些坑。之後寫的文章中會盡可能寫詳細的php
-----------------------------------------------------------------------------------shell
CVE-2019-5886
在shopxo\application\install\controller\Index.php文件中，Add方法中沒有校驗鎖文件，致使攻擊者能夠重裝數據庫（我是後來才知道的，能夠利用MySQL LOAD DATA LOCAL INFILE讀取任意客戶端文件）數據庫
Index.php文件是處理系統安裝的CreateConfig文件，可是惟獨它的Add方法中沒有校驗鎖文件，且方法內第174行處調用CreateConfig()生成數據庫配置文件，而$params是從post參數中取的，進入CreateConfig方法中小程序
能夠看到該方法中是將$params中的值寫入database.php中，包括數據庫地址，數據庫名以及帳號密碼等。這樣咱們重裝系統將數據庫綁定到攻擊者本身的數據庫上。服務器
---------------------------------------------------------------------------app
這個地方是寫入php文件中，理論上咱們能夠插入php代碼後getshell的，當時我當時技術很菜，由於各類緣由沒成功（具體什麼我也不記得了），不過我如今知道了一個新的方法：函數
閉合array後 Array.eval($_GET['evil']),相似這樣。post
漏洞復現：網站
訪問install模塊下的index控制器下的add方法，並構造以下請求spa
能夠發現本地數據庫中新建了一個shopxo2的數據庫，實際場景中攻擊者能夠在本身額公網服務器中的數據庫開啓遠程鏈接，連上本身的數據庫。
最關鍵的地方是數據庫配置文件也修改了
CVE-2019-5887漏洞分析
在shopxo/extend/base/FileUtil.php文件的201行處發現調用了rmdir函數：
追蹤$aim_dir發現是可控的，發現shopxo/service/AppMiniService.php文件中的Delete方法中調用了UnlinkDir方法：
當$path不以".zip"結尾時，會調用UnlinkDir方法，而$path來源於params['id']。繼續回溯：
shopxo/application/admin/controller/Appminialipaylist.php這個Controller文件的Delete方法調用了AppMiniService::Delete,改項目中全部的Controller的構造函數中都會調用父類的input()，也就是將請求參數中的值爲$params賦值。
漏洞復現
在後臺小程序操做處，點擊刪除
使用burp抓包，構造請求
能夠看到返回包中已經成功刪除