DEDECMS数据库执行原理、CMS代码层SQL注入防御思路

我们在上一篇文章中学习了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:wampwwwdede5.7 est.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 />
"; 
    }
    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 />
"; 
    }
    
    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:wampwwwdede5.7includededesql.class.php -> SetQuery

E:wampwwwdede5.7includededesqli.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