我们在上一篇文章中学习了DEDECMS的模板标签、模板解析原理，以及通过对模板核心类的Hook Patch来对模板的解析流量的攻击模式检测，达到修复模板类代码执行漏洞的目的
http://www.cnblogs.com/LittleHann/p/3574694.html
通过这段时间的思考，我大概对目前CMS中主流的WEB漏洞进行了大致的分类，这里给朋友们分享一些我的想法:
) 本地变量覆盖类型的漏洞: 在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 ) 模板类代码执行漏洞，对CMS中负责模板标签解析的核心文件进行Hook Patch，检测模板解析中的流量，对涉及:
http://ha.cker.in/1006.seo
2.1) 代码执行
2.2) webshell写入的攻击模式进行检测 ) 数据库注入类漏洞，黑客通过在变量输入的地方添加额外的攻击性SQL代码来达到修改原始SQL语句的目的: 在CMS中一般有一个核心类专门用来进行数据库操作，对这个核心类进行Hook，
对即将流入数据库的流量进行检测 ) 代码注入执行类漏洞，典型的如 $var = "${${phpinfo()}}"(注意，如果是单引号就失效了)这种语法，这种攻击场景真实存在，但是却没有一个很好的"中心流量节点"，目前还没想到好
的方法做Hook Patch。这种代码执行常常和模板类代码执行同时出现
http://ha.cker.in/1006.seo ) 利用服务器错误请求、数据库错误请求会被记录到日志中(常常是.php形式)，然后将webshell写进日志的做法进行GETSHELL
http://sebug.net/vuldb/ssvid-24262 ) 利用文件上传漏洞，文件上传的漏洞主要有以下几个攻防的点
) 利用畸形文件名进行绕过防御代码:
1.1) shell.asp;.jpg(IIS解析漏洞)
1.2) shell.PhP(大小写绕过黑名单)
) 利用配置漏洞，CMS一般都会有"允许上传文件的后缀、类型"的黑名单限制
2.1) 管理员自己不小心错误配置了"允许上传文件的后缀、类型"，导致了允许.php这类脚本的直接上传
2.2) 黑客通过别的手段拿到了网站后台的密码，进行了配置信息的修改
2.3) 通过register_globals=on漏洞，进行了变量覆盖，进而绕过防御逻辑，进行非法文件上传
) 利用一些主流的存在漏洞的文件上传开源组件: FCKeditor、kindeditor进行文件上传
3.1) 防御代码漏洞: asp.asp;jpg
3.2) IIS解析漏洞: 创建shell.asp/文件夹，则在这个目录下的任意扩展名的文件都可以被当作asp执行
以上的思路，我会在今后的文章中逐一和大家一起学习，并努力找到一种修复CMS漏洞的底层方法。
这篇文章中，我们一起来学习一下DEDECMS中涉及数据库操作的代码逻辑，并思考怎么在"关键流量节点"上进行Hook Patch，从而达到解决数据库注入类漏洞的目的
本文主要分为以下几个部分:
. DEDECMS中数据库操作的方法、原理
. 对数据库查询的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中数据库操作核心类原理之前，我觉得有两点要先明确一下:
) DEDECMS严格来说是一个MVC框架，很适合网站开发者在其上进行二次开发
) 因为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 = ;
/*
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"] = ;
//连接数据库
$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造成误拦截，而这个规则的优化过程应该是一个震荡曲线，即一个不断修改、精细化的过程。大致的步骤可以是这样:
. 根据目前手上掌握的攻击SQL，对这些语句进行"骨架抽取"，找出它们共同的正则特征
. 编写仅仅刚好够覆盖这些特征的正则规则
. 将这些正则规则上线测试运行，同时做好拦截、误报、漏报记录
. 定期对日志记录进行梳理，根据误报、漏洞的情况进行小范围的正则规则修改，注意是小范围的修改，一次尽量只作刚好能解决现有的误报、漏洞问题的修改
. 重复循环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 ;
}
else
{
//die("good");
return ;
}
}
解决了规则问题，我们现在可以开始我们本文的真正目的了: 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) == )
{
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 ;
}
else
{
//die("good");
return ;
}
}
经过测试，拿目前DEDE主流的POC进行渗透，防御效果较好，不过正如我们之前说的，这个正则规则需要一个不断地优化、修正过程。正如那句名言一样: 攻防对抗是一个长期的动态的过程，需要我们不断的去拓展思维，从攻击者、防御者两方面同时去思考。
我个人愚见: 目前虽然有乌云等漏洞批量平台不断地帮助开源WEB系统厂商去发现并修补漏洞，但总体来说，防守方还是处于一种被动防守的情况。而且比起被动防守来说，更大的问题在于，大部分的网站对自己的WEB系统出现的漏洞不具备快速的响应能力，更不用说很多中小站长在阿里云买了服务器之后，在上面装了一个DEDEV5.7之后，缺乏经常性的代码维护，导致了出现了高危漏洞的时候，这些站长没有及时修补漏洞，进行导致被黑客渗透入侵。这样的情况在阿里云ECS上的情况尤其严重。
鉴于以上的情况，我提出2点YY(仅仅是YY)
. 参考云服务的思想，云服务商直接提供"云CMS"服务，用户可以选择需要购买什么类型的CMS(例如DEDE、ECSHOP)、版本也可以自己定制。云服务商在服务端统一维护一套WEB系统代码，进行严格的代码审计和加固，这样可以起到和堡垒主机同样的效果，通过放大单个节点的风险、从而减小防御范围面。 . 将IDS的流量分析思想融入代码安全审计中，将目前遇到的所有CMS漏洞进行归类，找到最底层的流量节点，对这些核心文件进行Hook Patch，最终的目的是抽象出一个漏洞防御规则库，达到一劳永逸防御现有代码、以及可能出现的0DAY的威胁，因为比起对单个文件的修补，对一类漏洞，对底层代码逻辑的Hook，是可以达到提前预判的效果的
以上两点是我个人的YY，但是我觉得，未来的WEB漏洞的攻防应该有一种更加有效、有概括性的修补方案。就像windows的里程碑技术: DEP、SageSEH、ASLR等技术，都是在做归类性的漏洞修复，这些技术修复的不是某个漏洞，而是一整类漏洞，并同时很大程度上防御了很多未知的漏洞，这种优秀的思想是很值得借鉴的。
Copyright (c) 2014 LittleHann All rights reserved