淺談開源web程式後臺的安全性

一、前言

不知怎的最近甚是思念校園生活，思念食堂的炒飯。 那時會去各種安全bbs上刷刷帖子，喜歡看別人寫的一些關於安全技巧或經驗的總結;那時BBS上很多文章標題都是：成功滲透XXX，成功拿下XXX。 這裡便以一篇入侵菲律賓某大學的文章引出文章的主題，我們先簡要看一下過程。 大學網站使用了名為joomla的開源web程式，(1)青年使用一個joomla已經公開的漏洞進入web後臺(2)青年使用joomla後臺上傳限制不嚴的缺陷上傳了一個webshell(3)控制主機贈送我國國旗。

原來入侵一台主機如此容易，管理員果斷給web程式打上安全補丁。 管理員的工作是結束了，作為安全從業人員再一想是不是joomla後臺這裡可以上傳webshell是不是有問題呢，如果joomla後臺不能上傳webshell，是不是可以減少入侵的可能和損失。 下面進入本文的主題：web幕後程式的安全性。

二、簡介

國內很多網站都是基於開源論壇、cms搭建的，比如discuz、phpwind、dedecms等。 這些程式都是國內開源web程式中的佼佼者，也比較注重安全性。 平時大家關注比較多的是sql注入、xss這些可以直接竊取使用者資料的漏洞。 網上因為弱口令被入侵的案例數不勝數，此外使用者資料洩漏事件時而發生，單純靠密碼防護的後臺被突破，被社工的可能性越來越大。 獲取一個管理後臺密碼後，再結合幕後程式的任意代碼執行、檔包含或命令注入等漏洞得到一個shell，竊取使用者資料不是什麼難事。 此時幕後程式的安全性成為一個短板。

Discuz是一款流行的論壇程式，筆者這裡就以它的幕後程式為例簡單分析一下其安全性，下面直接看一些漏洞案例(Discuz最新版本已打補丁,請使用者及時升級到最新版-Discuz! X3.1 R20140101)。

三、案例分析

Tips：下文提到的$settingnew是discuz後臺存儲表單資料的變數，後臺使用者可控。

案例一：使用者輸入資料過濾邏輯不當

漏洞檔：X3\source\admincp\admincp_setting.php

分析：

案例二：二次注入

簡單介紹一下二次注入，惡意使用者alice在A處傳入惡意資料並被存儲到資料庫，在A處不直接導致安全問題; B處引用到A處存儲的資料，從而觸發安全問題。

漏洞檔：X3\source\admincp\admincp_setting.php

分析：

案例三：程式升級新增邏輯導致的漏洞

漏洞檔：X3\source\admincp\admincp_adv.php

案例四：漏洞修補不完善

漏洞檔：X3\api\uc.php

分析：

這個問題早在2010年外部已經公開，官方已及時發出補丁

詳情請參考：HTTP://www.oldjun.com/blog/index.php/archives/76/

四、總結

上面這些例子主要是筆者實踐經驗的一些總結，不一定全面，希望能給大家拓展一些思路;比如上述提到的二次注入，$settingnew['seccodedata']['type']這個變數沒過濾，$ settingnew的其他陣列也可能沒過濾，也確實存在多處類似的問題，大家可以自行去嘗試一下。 關於代碼審計的方法主要有兩個大方向：(1)危險函數向上追蹤輸入;(2)追蹤使用者輸入是否進入危險函數;這裡的危險函數關於危險函數主要包括代碼執行相關：eval、assert，檔包含：include、require等， 命令執行：system、exec等，寫檔：fwrite、file_put_contents等;

代碼審計的方法這裡推薦兩篇文章:

HTTPs://code.google.com/p/pasc2at/wiki/SimplifiedChinese

HTTP://wenku.baidu.com/view/c85be95a3b3567ec102d8a12.html

五、反思

1、一切輸入都是有害的;

幕後程式的使用者輸入相比前臺主要增加了後臺表單的資料，此外有些後臺支援上傳檔(如dz1.5的自訂sql)，上傳檔的內容也屬於輸入;這些輸入都屬於使用者範圍。 一定要做嚴格的控制和過濾。

2、安全意識;

其實很多漏洞的產生並不是技術問題導致的，而是我們缺乏安全意識，不重視安全而釀成的慘劇。 尤其是第三個和第四個，完全不應該發生;需要對開發人員做安全宣導和基本的安全培訓。

3、漏洞Review;

(1)開發人員收到漏洞後要對漏洞產生的原因做總結，並Review代碼中是否有類似的問題。 有些時候開發人員僅僅是修補了安全人員或白帽子提供的漏洞點，另外一處代碼有類似的問題沒修補繼續爆出漏洞，無窮無盡。 這樣做還會帶來更大的隱患，駭客是非常樂意並擅長總結反思的，每一個補丁其實也是給駭客拓展了思路，如果修補不完全後果很嚴重。

(2)開發人員修補完成後安全人員需要進行測試確認，上述的案例四就是鮮明的例子。 有條件的情況下安全人員應該整理一些常見漏洞修復指引，這樣也可以提高工作效率。