DEDECMS數據庫執行原理、CMS代碼層SQL注入防護思路

時間  2019-11-29
標籤 dedecms 數據庫 執行 原理 cms 代碼 sql 注入 防護 思路 欄目 CMS 简体版
原文   原文鏈接

咱們在上一篇文章中學習了DEDECMS的模板標籤、模板解析原理，以及經過對模板核心類的Hook Patch來對模板的解析流量的攻擊模式檢測，達到修復模板類代碼執行漏洞的目的php

http://www.cnblogs.com/LittleHann/p/3574694.htmlhtml

經過這段時間的思考，我大概對目前CMS中主流的WEB漏洞進行了大體的分類，這裏給朋友們分享一些個人想法:mysql

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漏洞的底層方法。web

這篇文章中，咱們一塊兒來學習一下DEDECMS中涉及數據庫操做的代碼邏輯，並思考怎麼在"關鍵流量節點"上進行Hook Patch，從而達到解決數據庫注入類漏洞的目的sql

本文主要分爲如下幾個部分:shell

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中數據庫操做的方法、原理express

在開始學習DEDECMS中數據庫操做核心類原理以前，我以爲有兩點要先明確一下:windows

1) DEDECMS嚴格來講是一個MVC框架，很適合網站開發者在其上進行二次開發
2) 由於DEDE從架構上是一個MVC架構，因此不少的底層操做，例如數據庫操做、數據變量清洗、輸入變量本地化、模板解析的關鍵代碼都會集中在幾個特定的文件中，即OOP的設計思想，
　　這就爲咱們針對不一樣種類的漏洞作流量分析提供很好的基礎出發點

既然是基於MVC的二次開發法，咱們先編寫一些PHP代碼，測試一下怎麼使用DEDE提供的單例模式(工廠模式)數據庫操做類來進行方便的數據庫操做api

在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. 重複循環三、4的過程，不斷達到誤報、漏洞、準確性的一個平衡點

我目前就是在作三、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

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程