我們在上一篇文章中學習了DEDECMS的模板標簽、模板解析原理，以及通過對模板核心類的Hook Patch來對模板的解析流量的攻擊模式檢測，達到修復模板類代碼執行漏洞的目的
http://www.cnblogs.com/LittleHann/p/3574694.html
通過這段時間的思考，我大概對目前CMS中主流的WEB漏洞進行了大致的分類，這里給朋友們分享一些我的想法:
1) 本地變量覆蓋類型的漏洞: 在common.inc.php這種本地變量注冊的關口進行流量監控，通過正則規則，防止黑客通過在GET、POST、COOKIE位置提交以下兩類數據: 1.1) 輸入"未正確初始化的變量"，來達到修改程序原本變量的數據類型的目的 http://www.yunsec.net/a/security/bugs/script/2013/0120/12286.html 1.2) 覆蓋已經存在的變量達到修改代碼流的目的 http://sebug.net/vuldb/ssvid-20859 2) 模板類代碼執行漏洞，對CMS中負責模板標簽解析的核心文件進行Hook Patch，檢測模板解析中的流量，對涉及: http://ha.cker.in/1006.seo 2.1) 代碼執行 2.2) webshell寫入的攻擊模式進行檢測 3) 數據庫注入類漏洞，黑客通過在變量輸入的地方添加額外的攻擊性SQL代碼來達到修改原始SQL語句的目的: 在CMS中一般有一個核心類專門用來進行數據庫操作，對這個核心類進行Hook， 對即將流入數據庫的流量進行檢測 4) 代碼注入執行類漏洞，典型的如 $var = "${${phpinfo()}}"(注意，如果是單引號就失效了)這種語法，這種攻擊場景真實存在，但是卻沒有一個很好的"中心流量節點"，目前還沒想到好 的方法做Hook Patch。這種代碼執行常常和模板類代碼執行同時出現 http://ha.cker.in/1006.seo 5) 利用服務器錯誤請求、數據庫錯誤請求會被記錄到日志中(常常是.php形式)，然后將webshell寫進日志的做法進行GETSHELL http://sebug.net/vuldb/ssvid-24262 6) 利用文件上傳漏洞，文件上傳的漏洞主要有以下幾個攻防的點 1) 利用畸形文件名進行繞過防御代碼: 1.1) shell.asp;.jpg(IIS解析漏洞) 1.2) shell.PhP(大小寫繞過黑名單) 2) 利用配置漏洞，CMS一般都會有"允許上傳文件的后綴、類型"的黑名單限制 2.1) 管理員自己不小心錯誤配置了"允許上傳文件的后綴、類型"，導致了允許.php這類腳本的直接上傳 2.2) 黑客通過別的手段拿到了網站后台的密碼，進行了配置信息的修改 2.3) 通過register_globals=on漏洞，進行了變量覆蓋，進而繞過防御邏輯，進行非法文件上傳 3) 利用一些主流的存在漏洞的文件上傳開源組件: FCKeditor、kindeditor進行文件上傳 3.1) 防御代碼漏洞: asp.asp;jpg 3.2) IIS解析漏洞: 創建shell.asp/文件夾，則在這個目錄下的任意擴展名的文件都可以被當作asp執行
以上的思路，我會在今后的文章中逐一和大家一起學習，並努力找到一種修復CMS漏洞的底層方法。
這篇文章中，我們一起來學習一下DEDECMS中涉及數據庫操作的代碼邏輯，並思考怎么在"關鍵流量節點"上進行Hook Patch，從而達到解決數據庫注入類漏洞的目的
本文主要分為以下幾個部分:
1. DEDECMS中數據庫操作的方法、原理 2. 對數據庫查詢的SQL流量的攻擊模式檢測
相關學習資料
http://blog.sina.com.cn/s/blog_56f273130100ul0l.html http://www.chinab4c.com/dedecmsjiaocheng/201112/22944.html http://hi.baidu.com/tong_jh/item/e64b2a402fed8c11886d107e http://blog.chinaunix.net/uid-286494-id-2134474.html http://open.taobao.com/doc/detail.htm?spm=0.0.0.0.FytuX1&id=813
1. DEDECMS中數據庫操作的方法、原理
在開始學習DEDECMS中數據庫操作核心類原理之前，我覺得有兩點要先明確一下:
1) DEDECMS嚴格來說是一個MVC框架，很適合網站開發者在其上進行二次開發 2) 因為DEDE從架構上是一個MVC架構，所以很多的底層操作，例如數據庫操作、數據變量清洗、輸入變量本地化、模板解析的關鍵代碼都會集中在幾個特定的文件中，即OOP的設計思想，
這就為我們針對不同種類的漏洞做流量分析提供很好的基礎出發點
既然是基於MVC的二次開發法，我們先編寫一些PHP代碼，測試一下怎么使用DEDE提供的單例模式(工廠模式)數據庫操作類來進行方便的數據庫操作
在DEDE網站的根目錄(注意，是網站的根目錄)下編寫test.php
E:\wamp\www\dede5.7\test.php
<?php //引入涉及數據庫操作的核心類文件 require_once (dirname(__FILE__) . "/include/common.inc.php"); //遵從單例模式(工廠模式)，直接調用$dsql類進行數據庫操作 //IsTable: 判斷指定的表是否存在 if($dsql->IsTable('dede_admin')) { //1. SetQuery+Execute: 執行一個帶返回結果(結果數組)的SQL語句，如SELECT，SHOW等 $sql = "SELECT value FROM #@__sysconfig where varname='cfg_mb_open'"; $dsql->SetQuery($sql); $dsql->Execute(); //2. ExecuteNoneQuery: 執行一個不返回結果集(數組)的SQL語句，如update,delete,insert等，但它會返回mysql的執行結果，例如插入的row的ID等信息 $sql = " DELETE from `#@__mytag` WHERE aid=1"; $rs = $db->ExecuteNoneQuery($sql); //3. ExecuteNoneQuery2: 執行一個返回影響記錄條數的SQL語句，如update,delete,insert等 $sql = "UPDATE `#@__downloads` SET downloads = downloads+1 WHERE hash='$hash' "; $rs = $dsql->ExecuteNoneQuery2($sql); } ?>
以上的3種SQL代碼執行方法就是DEDECMS中所有涉及到數據庫操作所使用的方法了，其他的方法都是這3種的別名方法，即轉接層。
可以看到在MVC模式下進行二次開發是很方便的，這是很多開源框架：CI、TP、主流框架WordPress的常用開發模式接下來，我們來深入源代碼，學習一下
require_once (dirname(__FILE__) . "/include/common.inc.php");
這個文件是DEDECMS中的一個核心配置文件，其中包含了很多方面的內容，我們今后學習變量覆蓋類漏洞的攻防還會涉及到這個文件，今天我們重點關注的是這個文件中和數據庫有關的代碼
/* 引入數據庫類 1. 如果在安裝時選擇了mysqli數據庫連接方式，並且當前PHP支持了mysqli模塊，則包含dedesqli.class.php文件 2. 默認情況下，包含dedesql.class.php */ if ($GLOBALS['cfg_mysql_type'] == 'mysqli' && function_exists("mysqli_init")) { require_once(DEDEINC.'/dedesqli.class.php'); } else { require_once(DEDEINC.'/dedesql.class.php'); }
dedesql.class.php和dedesqli.class.php代碼邏輯上是一樣的，只有在關鍵函數的最后會加上一個字母"i"，表示是原始mysql函數的改進(improve)版本(當然嚴格來說，這兩個文件在某些細節上還是不一樣的，例如dedesql.class.php的ExecuteNoneQuery2函數就存在一個SQL注入漏洞，而dedesqli.class.php則做了有效的過濾，這些問題都是我們在本文需要解決的問題，我們的目標就是找到"所有數據庫請求流量的最終的節點"，在這個節點上運用正則規則進行攻擊模式檢測)
require_once(DEDEINC.'/dedesql.class.php');
這個類非常龐大，里面封裝了數據庫Meta信息i獲取、數據庫操作、SQL錯誤執行信息記錄...
我們逐一來學習一下:
/* 在工程所有文件中均不需要單獨初始化這個類，可直接用 $dsql 或 $db 進行操作 為了防止錯誤，操作完后不必關閉數據庫 */ $dsql = $db = new DedeSql(FALSE);
$dsql = $db = new DedeSql(FALSE);
//用外部定義的變量初始類，並連接數據庫 function __construct($pconnect=FALSE,$nconnect=FALSE) { //標識是否關閉數據庫 $this->isClose = FALSE; //標識是否開啟安全檢查 $this->safeCheck = TRUE; //標識是否已經存在先前的數據庫連接資源標識符(默認為FALSE) $this->pconnect = $pconnect; //標識是否需要重新進行連接(默認為FALSE) if($nconnect) { //如果需要重新進行連接，調用Init進行初始化 $this->Init($pconnect); } }
$this->Init($pconnect);
function Init($pconnect=FALSE) { $this->linkID = 0; /* 1. 這里是一個關鍵，程序"信任"了來自全局變量$GLOBALS中和數據庫配置信息有關的數據，用以之后進行數據庫連接 2. 利用全局變量覆蓋+數據庫連接方向劫持的繞過漏洞就是源自於這個不太安全的步驟 3. 個人覺得，這種關鍵信息不能從內存中去提取，應該直接從配置文件中去讀取會比較安全一點 4. 另外，完全可以使用持久單例模式，一次數據庫連接完成之后，之后的請求就可以復用這個連接標識符，不用再重復連接、關閉了 */ $this->dbHost = $GLOBALS['cfg_dbhost']; $this->dbUser = $GLOBALS['cfg_dbuser']; $this->dbPwd = $GLOBALS['cfg_dbpwd']; $this->dbName = $GLOBALS['cfg_dbname']; $this->dbPrefix = $GLOBALS['cfg_dbprefix']; $this->result["me"] = 0; //連接數據庫 $this->Open($pconnect); }
以上就是我們在inlcude這個common.inc.php后，程序進行的數據庫連接初始化工作，之后，我們就可以方便地在程序中調用$dsql、或$db的方法進行SQL操作了
從某種程序上來說，這實現了一個工廠模式(雖然這樣說可能不太准確)，但是這極大的方便了我們在DEDE的框架內進行二次開發確實不爭的事實，理解了這種思想對我們理解CI、TP這樣的開源框架的基本原理也是大有裨益的
接下來，我們回到剛才的話題，前面說過，在DEDE中的SQL操作只有3種，也就是說，所有的SQL請求流量最終都會通過這4個函數得以實現，我們一起來對這4個函數進行一下代碼審計學習，我會直接COPY原始的DEDECMS V5.7的源代碼，並盡我所能去在代碼中加上我的理解注釋
0x1: SetQuery+Execute
$sql = "SELECT value FROM #@__sysconfig where varname='cfg_mb_open'";
$dsql->SetQuery($sql);
//設置SQL語句，會自動把SQL語句里的#@__替換為$GLOBALS['cfg_dbprefix'](在配置文件中為$cfg_dbprefix) function SetQuery($sql) { $prefix="#@__"; /* 1. 這樣做的目的是為了兼容多個DEDECMS同時安裝在同一個數據庫中，它們可以使用不同的前綴 2. 在原始的SQL中，所有的前綴都采用一個占位符"#@__"，然后在代碼執行前，根據當天配置的前綴(例如"dede_")進行替換。這是一種典型的適配器代碼層的思想 */ $sql = str_replace($prefix,$GLOBALS['cfg_dbprefix'],$sql); //將替換后的SQL代碼賦值給$this->queryString，用以之后發送給數據庫 $this->queryString = $sql; }
$dsql->Execute();
//執行一個帶返回結果的SQL語句，如SELECT，SHOW等 function Execute($id="me", $sql='') { global $dsql; /* 1. 這是第一個要重點注意的關鍵代碼，我們知道，Init這個函數會從全局變量$GLOBALS中獲取數據庫連接信息，從而給黑客以利用本地變量覆蓋來達到修改數據庫連接方向的目的。
那我們要問自己一個問題了，什么時候能觸發這個Init的執行條件呢？ 2. 答案很明顯: $dsql->isInit == FLASE的時候，那什么時候能滿足這個條件呢？ 3. 答案是在每次腳本請求中的第一次涉及數據庫操作的時候(GetOne、Execute、ExecuteNoneQuery、ExecuteNoneQuery2中任意一種)的時候 4. 因為我們知道: PHP是一種解釋性的腳本語言，每次的腳本解釋執行都會有自己獨立的代碼空間，腳本請求之間不會互相共享內存。所以在每次的腳本請求中，$dsql這個對象初始都
是null的，$dsql->isInit的初始默認值也是FALSE，在一個腳本請求中多次出現數據庫操作的時候，從第二次開始的數據庫請求就不需要再重新進行數據庫連接了(除非代碼強制
進行重連接) 5. 這種在同一個腳本中的"持久化連接"和ADO.NET中的持久化數據庫連接不是一個層次的技術，要注意區別 6. 這也給了我們一點關於漏洞挖掘的啟示，如果想挖掘"利用全局變量覆蓋+數據庫連接方向劫持的繞過漏洞"，就必須尋找那種在腳本中第一次出現的、黑客可以控制輸入參數的數據庫
操作函數，這也是一種代碼審計的思路 */ if(!$dsql->isInit) { $this->Init($this->pconnect); } //如果這個連接已經關閉，則重新打開連接 if($dsql->isClose) { $this->Open(FALSE); $dsql->isClose = FALSE; } if(!empty($sql)) { $this->SetQuery($sql); } /* 1. 這個80Sec為DEDE提供的SQL語句安全檢查 2. 個人愚見: 覺得這個Hook點還不夠"中心化"、"底層化"，我的觀點是在SetQuery這個函數進行Hook Patch，因為SetQuery是整個dedesql.class.php中所有涉及到SQL操作都
會涉及到的函數，在這個點進行流量分析，能做到更好的覆蓋效果 */ if($this->safeCheck) { CheckSql($this->queryString); } $t1 = ExecTime(); //調用PHP原生的mysql擴展接口，執行數據操作 $this->result[$id] = mysql_query($this->queryString,$this->linkID); //記錄執行時間 if($this->recordLog) { $queryTime = ExecTime() - $t1; $this->RecordLog($queryTime); } /* 記錄數據庫執行錯誤信息，方便調試，這里可能涉及到另一種利用發送附帶webshell代碼的錯誤服務器、數據庫請求來將webshell注入日志中達到getshell的目的，不過這不是數據
庫防御方案能解決的問題，這屬於另一類解決方案了，我們之后的文章中會談到這類漏洞 */ if(!empty($this->result[$id]) && $this->result[$id]===FALSE) { $this->DisplayError(mysql_error()." <br />Error sql: <font color='red'>".$this->queryString."</font>"); } }
0x2: ExecuteNoneQuery
//執行一個不返回結果的SQL語句，如update,delete,insert等 function ExecuteNoneQuery($sql='') { global $dsql; //這里的注意點和Execute函數是一樣的 if(!$dsql->isInit) { $this->Init($this->pconnect); } if($dsql->isClose) { $this->Open(FALSE); $dsql->isClose = FALSE; } if(!empty($sql)) { $this->SetQuery($sql); }else{ return FALSE; } //DEDE實現的一種參數化查詢方法 if(is_array($this->parameters)) { foreach($this->parameters as $key=>$value) { $this->queryString = str_replace("@".$key,"'$value'",$this->queryString); } } //SQL語句安全檢查，和之前的一樣 if($this->safeCheck) CheckSql($this->queryString,'update'); $t1 = ExecTime(); $rs = mysql_query($this->queryString,$this->linkID); //查詢性能測試 if($this->recordLog) { $queryTime = ExecTime() - $t1; $this->RecordLog($queryTime); //echo $this->queryString."--{$queryTime}<hr />\r\n"; } return $rs; }
0x3: ExecuteNoneQuery2
//執行一個返回影響記錄條數的SQL語句，如update,delete,insert等 function ExecuteNoneQuery2($sql='') { global $dsql; if(!$dsql->isInit) { $this->Init($this->pconnect); } if($dsql->isClose) { $this->Open(FALSE); $dsql->isClose = FALSE; } if(!empty($sql)) { $this->SetQuery($sql); } if(is_array($this->parameters)) { foreach($this->parameters as $key=>$value) { $this->queryString = str_replace("@".$key,"'$value'",$this->queryString); } } $t1 = ExecTime(); mysql_query($this->queryString,$this->linkID); //查詢性能測試 if($this->recordLog) { $queryTime = ExecTime() - $t1; $this->RecordLog($queryTime); //echo $this->queryString."--{$queryTime}<hr />\r\n"; } return mysql_affected_rows($this->linkID); }
以上3個函數在DEDECMS中的不同數據庫操作場景中出現，它們提供不同粒度的SQL操作接口，但對於代碼安全審計者來說，我們關注的並不是它們的業務場景的功能，我更注重的是關鍵節點流量的攻擊模式檢測。即對SetQuery這個函數進行Hook Patch，檢測所有通過它的流量。
2. 對數據庫查詢的SQL流量的攻擊模式檢測
在進行Hook Patch之前，我們首先要解決一個問題，SQL注入攻擊都有什么樣的攻擊模式，我們該怎樣把它們抽象成正則規則來進行模式匹配呢？
這里參考了一篇博客的思路
http://blog.chinaunix.net/uid-286494-id-2134474.html
不過它和我們的應用場景還不太一樣，他寫的SNORT規則是基於HTTP層的流量檢測，而我們這里要做的SQL Inject Hook Patch是在數據庫執行層做注入檢測，我們面對的是純的SQL語法。我們必須結合SQL語法的自身情況進行分析，找到一種好的方法來區分出正常的業務SQL、以及攻擊性SQL。
根據我自身的經驗來說，確定一種規則不能僅僅考慮能不能有效地檢測出注入SQL，還要考慮另一個方面: "誤報"，我們的規則不能太嚴，否則會造成對正常的業務SQL造成誤攔截，而這個規則的優化過程應該是一個震盪曲線，即一個不斷修改、精細化的過程。大致的步驟可以是這樣:
1. 根據目前手上掌握的攻擊SQL，對這些語句進行"骨架抽取"，找出它們共同的正則特征 2. 編寫僅僅剛好夠覆蓋這些特征的正則規則 3. 將這些正則規則上線測試運行，同時做好攔截、誤報、漏報記錄 4. 定期對日志記錄進行梳理，根據誤報、漏洞的情況進行小范圍的正則規則修改，注意是小范圍的修改，一次盡量只作剛好能解決現有的誤報、漏洞問題的修改 5. 重復循環3、4的過程，不斷達到誤報、漏洞、准確性的一個平衡點
我目前就是在做3、4的這個循環過程，希望能在不斷的攻防分析中找到一種好的SQL注入攻擊模式的檢測模式，分享一下我的思路，也希望有更好想法的朋友能不吝賜教，分享一些別的檢測想法
/* 檢測傳入的SQL語句是否是攻擊性SQL。即注入性檢測 返回1: 有攻擊性 返回0: 沒有攻擊性 */ public function CheckSql($db_string) { /* 規則1: 最常見的注入點往往發生在where子句的and邏輯表達式后面，黑客通過在and后面的子句中構造: 1) 子查詢來直接進行非法數據獲取(以獲取數據為目的) 2) 或者進行盲注推理(逐字符二分推理) 3) Error Based Inject(報錯注入) 典型語句如下: 1) error based group by inject select * from admin where id=5 and name='littlehann' order by=5 and (select 1 from(select count(*),concat((select password from users where
username=0x41646d696e),0x3a,floor(rand(0)*2))x from information_schema.tables group by x)a) -- 2) ASCII、ORD Bitwise Blind Inject select * from admin where id=5 and name='littlehann' order by password,if((substring(password,1,1) > 'F'),1,2)-- */ $express_1 = "/([A-Za-z])?(where(\s)*)(.)*?(concat\(\).*|char|(chr.*){4,}|floor\(\).*|substr(ing)?.*|ascii\(\).*|ord\(\).*)/i"; /* 規則2: 黑客常用利用where子句的注入點，進行union select注入探測，目的是獲取目標的表、庫結構信息。為進一步滲透作准備。 典型的語句如下: 1) volumn numbers detection where 1=2 union select 1, from dual where 1=2 union select 1,1 from dual where 1=2 union select 1,1,1 from dual ... */ $express_2 = "/([A-Za-z])?(where).*(union)(\s)*(all)?(\s)*select(\s)*((\d|null),(\s)*){2,}/i"; /* 規則3: 在sql查詢中，有一些敏感關鍵字是不允許使用的 典型語句如下: 1) Time Delay Based Inject、DDOS(基於時間延遲的盲注、或者DDOS) select * from admin where id=5 and name='littlehann' or sleep(ord(substr(password,1,1)))-- select * from admin where id=5 and name='littlehann' or sleep(9999999990999999)-- select * from admin where id=5 and name='littlehann' or benchmark(ord(substr(password,1,1))*1000000,MD5(1))-- 2) load_file、outfile important data leak select id,name from admin where id=5 and name='littlehann' and 1=2 union select 1,concat(select loadfile '...') 3) database api funcion always-true inject detection select * from admin where id=5 and name='littlehann' or database() = database() */ $express_3 = "/[^0-9a-z@\._-]{1,}(sleep|benchmark|waitfor|load_file|outfile|(database\(\).*){1,}|((current_|system_){0,1}user\(\).*){1,}|@@version)
[^0-9a-z@\.-]{1,}/i"; /* 規則4: 黑客在滲透測試的前期，會使用手工方法、或自動化的掃描工具，在SQL查詢中"拼接"一種"注入性永真" 典型語句如下: 1) always-true detection(對於永真的位置如果出現在where子元素的第二個位置判斷為注入探測的可能性更大，即and后面跟上永真) select * from admin where id=5 and 1=1 */ $express_4 = "/([A-Za-z])?(where)(.|\s)*?(or|and|like)(\s)(('\d'|\d)(=|>|<|like)('\d'|\d))/i"; /* 規則5: 黑客在進行注入的時候，常常會使用到一些注釋符，目的是在注入攻擊性paylaod之后，直接關閉原始SQL語句，避免引號、閉合導致的SQL語法錯誤，使SQL注入成功執行 典型語句如下 1) #、-- Comment Based Inject select g.goods_barcode,g.payment_ft,g.goods_sn,c.color_name,s.size_name,g.id,g.goods_id,g.color_id,g.size_id from order_return_goods g,size
s,color c where g.size_id=s.size_id and g.color_id=c.color_id and g.return_order_id='52099' UNION ALL SELECT NULL, NULL, NULL, NULL# AND
'WnZS'='WnZS' */ $express_5 = "/([A-Za-z])?(where(\s|.)*)(#.*|--)/i"; if (preg_match($express_1, $db_string) || preg_match($express_2, $db_string) || preg_match($express_3, $db_string) || preg_match($express_4,
$db_string) || preg_match($express_5, $db_string)) { //die("detected!!!"); return 1; } else { //die("good"); return 0; } }
解決了規則問題，我們現在可以開始我們本文的真正目的了: CMS代碼漏洞修復
Hook Patch Point
E:\wamp\www\dede5.7\include\dedesql.class.php -> SetQuery
E:\wamp\www\dede5.7\include\dedesqli.class.php -> SetQuery
//設置SQL語句，會自動把SQL語句里的#@__替換為$this->dbPrefix(在配置文件中為$cfg_dbprefix) function SetQuery($sql) { $prefix="#@__"; $sql = str_replace($prefix,$GLOBALS['cfg_dbprefix'],$sql); if($this->CheckSql($sql) == 1) { die("Request Error!"); } $this->queryString = $sql; } public function CheckSql($db_string) { $express_1 = "/([A-Za-z])?(where)(.|\s)*?(concat|char|(chr){4,}|case|floor|#.*|--)/i"; $express_2 = "/([A-Za-z])?(where).*(union)(\s)*(all)(\s)*select(\s)*(\d|null,(\s)*){2,}/i"; $express_3 = "/[^0-9a-z@\._-]{1,}(sleep|benchmark|load_file|outfile|(user\(\).*){1,})[^0-9a-z@\.-]{1,}/i"; if (preg_match($express_1, $db_string) || preg_match($express_2, $db_string) || preg_match($express_3, $db_string)) { //die("detected!!!"); return 1; } else { //die("good"); return 0; } }
經過測試，拿目前DEDE主流的POC進行滲透，防御效果較好，不過正如我們之前說的，這個正則規則需要一個不斷地優化、修正過程。正如那句名言一樣: 攻防對抗是一個長期的動態的過程，需要我們不斷的去拓展思維，從攻擊者、防御者兩方面同時去思考。
我個人愚見: 目前雖然有烏雲等漏洞批量平台不斷地幫助開源WEB系統廠商去發現並修補漏洞，但總體來說，防守方還是處於一種被動防守的情況。而且比起被動防守來說，更大的問題在於，大部分的網站對自己的WEB系統出現的漏洞不具備快速的響應能力，更不用說很多中小站長在阿里雲買了服務器之后，在上面裝了一個DEDEV5.7之后，缺乏經常性的代碼維護，導致了出現了高危漏洞的時候，這些站長沒有及時修補漏洞，進行導致被黑客滲透入侵。這樣的情況在阿里雲ECS上的情況尤其嚴重。
鑒於以上的情況，我提出2點YY(僅僅是YY)
1. 參考雲服務的思想，雲服務商直接提供"雲CMS"服務，用戶可以選擇需要購買什么類型的CMS(例如DEDE、ECSHOP)、版本也可以自己定制。雲服務商在服務端統一維護一套WEB系統代碼，進行嚴格的代碼審計和加固，這樣可以起到和堡壘主機同樣的效果，通過放大單個節點的風險、從而減小防御范圍面。 2. 將IDS的流量分析思想融入代碼安全審計中，將目前遇到的所有CMS漏洞進行歸類，找到最底層的流量節點，對這些核心文件進行Hook Patch，最終的目的是抽象出一個漏洞防御規則庫，達到一勞永逸防御現有代碼、以及可能出現的0DAY的威脅，因為比起對單個文件的修補，對一類漏洞，對底層代碼邏輯的Hook，是可以達到提前預判的效果的
以上兩點是我個人的YY，但是我覺得，未來的WEB漏洞的攻防應該有一種更加有效、有概括性的修補方案。就像windows的里程碑技術: DEP、SageSEH、ASLR等技術，都是在做歸類性的漏洞修復，這些技術修復的不是某個漏洞，而是一整類漏洞，並同時很大程度上防御了很多未知的漏洞，這種優秀的思想是很值得借鑒的。
Copyright (c) 2014 LittleHann All rights reserved