走进科学 WAF(Web Appllication Firewall)

1. 前言

当WEB应用越来越为丰富的同时，WEB 服务器以其强大的计算能力、处理性能及蕴含的较高价值逐渐成为主要攻击目标。SQL注入、网页篡改、网页挂马等安全事件，频繁发生。

企业等用户一般采用防火墙作为安全保障体系的第一道防线。但是，在现实中，他们存在这样那样的问题，例如传统的防火墙体系无法对当前快速爆发和蔓延的0DAY漏洞进行快速响应和对抗，而要彻底解决此类漏洞的代码审计和代码修补往往需要较长的时间，由此产生了WAF（Web应用防护系统）。TecNova-WAF Web应用防护系统（Web Application Firewall, 简称：WAF）代表了一类新兴的信息安全技术，用以解决诸如防火墙一类传统设备束手无策的Web应用安全问题。与传统防火墙不同，WAF工作在应用层，因此对Web应用防护具有先天的技术优势。基于对Web应用业务和逻辑的深刻理解，WAF对来自Web应用程序客户端的各类请求进行内容检测和验证，确保其安全性与合法性，对非法的请求予以实时阻断，从而对各类网站站点进行有效防护。

2. WAF分类

WAF是一种网络设备(硬件WAF)或者是一种将安全特性添加到web应用(软件的内置WAF)的基于软件的解决方案。即WAF从定义上可以分为:

硬件WAF:

http://www.nsfocus.com/1_solution/1_2_8_1.html   NSFOCUS Web Application Firewall

http://www.barracuda.com.cn/products/    梭子鱼Web应用防火墙

http://www.venustech.com.cn/SafeProductInfo/413/39.Html    天清Web应用安全网关

软件WAF:

http://www.modsecurity.org/projects/modsecurityApache的一块模块ModSecurity

https://phpids.org/       为PHP应用设计的WAF系统

http://msdn.microsoft.com/zh-cn/library/aa302368.aspx   集成到IIS平台的ISAPI过滤器

http://www.aqtronix.com/WebKnight/Manual/WebKnight-Chinese.pdf

http://www.aqtronix.com/?PageID=99     集成到IIS的过滤器

代码级WAF(使用脚本语言实现的过滤器模式)

这种机制本质上属于应用程序安全架构的范畴，它是遵循安全编码最佳实践的产物。就PHP Web应用来说，可以在php.ini中修改:

; Automatically add files before PHP document.

; http://php.net/auto-prepend-file

auto_prepend_file =

; Automatically add files after PHP document.

; http://php.net/auto-append-file

auto_append_file =

配置指令，这些指令指向那些在每个请求的PHP脚本执行"之前"和"之后"才执行的PHP文件。这样就可以在各种HTTP请求集合(GET,POST,COOKIE)之前对数据进行一些前发处理。

一些开源的web框架如CodeIgniter会采用一些Global Routing全局路由机制来改变原本的HTTP交互流程，从而使程序猿有机会hook住一些关键的处理逻辑，在进入核心代码前对用户发送的数据进行处理。

http://codeigniter.org.cn/user_guide/general/routing.html

还可以使用web应用的编程语言来实现过滤器。模块代码可以在请求和响应阶段之间进行执行。

ASP.NET的System.Web.IHttpModule接口:

http://msdn.microsoft.com/zh-cn/library/system.web.ihttpmodule(VS.80).aspx

http://msdn.microsoft.com/zh-cn/library/ms227673(v=vs.90).aspx

(实际上，我们可以利用.NET的这个原生的接口开发自己的HTTP服务器或接收处理模块)

javax.servlet.Filter接口

http://docs.oracle.com/javaee/6/api/javax/servlet/Filter.html

public class SqlInjDetectionFilter implements Filter

{

    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException

    {

       //check request data for maliious characters

       deDetectSqlI(rep, res);

       //call next filter in the chain

       chain.doFilter(servletRequest, servletResponse);

    }

}

将这个接口代码添加到应用中，并在应用配置文件(web.xml)中显式地激活它们。之后每个请求/响应就会"自动"地去对J2EE web源(.jsp, servlet)文件的请求而调用该方法。这就是接口编程的好处，因为J2EE原本就实现了这个Filter机制，并提供了一个接口规范，我们只要在我们的代码中去继承实现这个接口，就可以把代码具现化，从而自定义我们自己的安全处理逻辑。

OWASP Stinger

https://www.owasp.org/index.php/Category:OWASP_Stinger_Project

一款开源的J2EE过滤器

Security Parameter Filter(SPF)

http://spf.codeplex.com/

一款ASP.NET HttpModule

3. WAF的特性

3.1 异常检测协议

Web应用防火墙会对HTTP的请求进行异常检测，拒绝不符合HTTP标准的请求。并且，它也可以只允许HTTP协议的部分选项通过，从而减少攻击的影响范围。甚至，一些Web应用防火墙还可以严格限定HTTP协议中那些过于松散或未被完全制定的选项。

RFC对HTTP的数据包格式有明确的定义: http://www.rfc-editor.org/rfc/rfc2068.txt 。正常情况下，应用收到的HTTP数据包应该符合这个规定的范畴内，除此之外，在具体的应用中对HTTP Header中的字段的数据类型以及参数长度都有明确的规定，如果超过了这个范畴，也会造成安全问题。

利用场景:

1) Http Split攻击(CRLF攻击的一种)

http://resources.infosecinstitute.com/http-response-splitting-attack

(利用了服务器处理HTTP协议格式的机制漏洞，向HTTP数据包中注入CRLF，从而将当前的HTTP数据隔断成2个数据包，使攻击者有机会控制当前的HTTP响应和下一次的HTTP响应)

2)  利用cookie信息超过一定的长度限制来绕过Cookie中的HttpOnly(XSS攻击)

在道哥的《白帽子讲web安全》中提到这叫Server Limit DOS攻击。

http://hi.baidu.com/aullik5/item/938f60fb7747b16e3c1485ca

(因为应用系统对HTTP Header中的参数长度没有进行检测造成的漏洞)

3) 基于Content-Length的DOS攻击

http://ha.ckers.org/slowloris/

(其原理是以极低的速度往服务器发送HTTP请求,在正常的HTTP包头中，是以两个CLRF表示HTTP Header部分结束的。由于web server只收到了一个\r\n，因此将认为HTTP Header部分没有结束，并保持此连接不释放，继续等待完整的请求，以此来造成和TCP半开连接DDOS攻击相同的攻击效果，应该说原理都是一样的)

4) X-Forward- For注入

http://sebug.net/vuldb/ssvid-8427

(一些应用会对用户登录时所在的IP地址或代理服务器的来源做记录，并保存到数据库中，如果没有使用正则强制限制为IP格式的话，可能会造成SQL注入)

5) 本地变量覆盖攻击

当目标应用开启了register_global、使用extract()，或者使用了动态变量本地注册的模拟register_global时，如果不对用户发送的参数的个数和范围做限制。即区分哪些是应该允许提交的，哪些是不允许提交的参数，则可能导致本地变量覆盖漏洞。

本地变量覆盖可能造成很严重的代码逻辑绕过，因为代码中，往往是使用类似 if($var){...}这样的形式来控制代码逻辑的，而通过本地变量覆盖可以改变$var的值甚至数据类型，即代码中的关键跳被攻击者控制了，很容易造成关键的防御代码被绕过。

http://sebug.net/vuldb/ssvid-15146

(这是一个二段攻击，巧妙利用本地变量覆盖导致wirite file最终getshell的例子)

6) 变量类型导致目标应用程序运行报错信息泄漏攻击

http://sebug.net/vuldb/ssvid-1080

(未对提交的参数的数据类型进行检测导致的漏洞)

7) HTTP Parameter Pollution

HPP攻击，通过GET或POST向服务器发起请求时，提交两个相同的参数，那么服务器会产生一些特殊的行为。

http://www.80sec.com/%E6%B5%85%E8%B0%88%E7%BB%95%E8%BF%87waf%E7%9A%84%E6%95%B0%E7%A7%8D%E6%96%B9%E6%B3%95.html

http://www.freebuf.com/articles/web/5908.html

http://hi.baidu.com/aullik5/item/860da508a90709843c42e2ca

这里插个题外话:

我们应该考虑一种输入验证策略就是将应用输入分为可编辑的和不可编辑的两类来区别对待。并且锁定不可编辑的输入以便无法操作它们。不可编辑输入是指最终用户不需要直接修改的输入，比如隐藏表单字段、URI和查询字符串参数、cookie等(或者说如果你是正常的用户，你是不会去修改的变量，这样可以对攻击者进行针对性的防御，体现了用户平衡的安全的原则)。

实现这种策略的技术范例是 HDIV(HTTP Data Integrity Validator HTTP数据完整性验证器)和SPF(Security Parameter Filter)。可以使用HDIV保护大多数遵循MVC模式的J2EE web应用。
http://www.hdiv.org/

3.2 增强的输入验证

输入验证是一种在保证应用安全上很有用的工具。可以把它作为纵深防御的一部分来看待。

1) 在应用输入层使用白名单输入验证以便验证所有用户输入都符合应用要接收的内容。应用只允许接收符合期望格式的输入
2) 在客户端浏览器上同样执行白名单过滤策略(节省往返流量)
3) 在web应用防火墙(WAF)层使用黑名单和白名单输入验证(以漏洞"签名"和"有经验"行为的形式)以便提供入侵检测/阻止功能和监视应用攻击
4) 在应用中自始自终地使用参数化语句以保证执行安全的SQL执行
5) 在数据库查询中使用转义技术(要注意跨系统间的编码问题，防御基于字符编码位宽的绕过: 宽字节注入)
6) 在向UI发送之前对数据进行编码。

http://code.google.com/p/owasp-esapi-php/
http://www.oschina.net/p/owasp-esapi-java

而在WAF中这些规则被抽象成了积极模型和消极模型。也就是白名单和黑名单的互补使用。

http://www.nsfocus.com/waf/jishu/js_01.html

3.3 及时补丁

任何时候，遵循安全编码规范 http://www.php.net/manual/zh/security.php，并进行严格的代码审计 http://code.google.com/p/pasc2at/wiki/SimplifiedChinese都是最好的办法。解决漏洞的源头也是对源代码进行修补。但是，在面对突发事件的0DAY攻击的时候，代码防御往往不能适应快速响应的需求，所以就需要一种快速的运行时保护机制。WAF在这种场景下可以充当虚拟补丁或补缀解决方案的作用。通过针对具体的漏洞场景编写紧急响应防御规则，来进行hot patch。

http://security.zdnet.com.cn/security_zone/2012/0208/2077704.shtml

3.4 基于规则的保护和基于异常的保护

基于规则的保护可以提供各种Web应用的安全规则，WAF生产商会维护这个规则库，并时时为其更新。用户可以按照这些规则对应用进行全方面检测。

ModSecurity

https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Configuration_Directives

和

PHPIDS都是使用规则的保护模式。

http://phpids.org/docs/

还有的产品可以基于合法应用数据建立模型，并以此为依据判断应用数据的异常。但这需要对用户企业的应用具有十分透彻的了解才可能做到。往往需要结合模式识别中的自学习思想，前期使用大量的样本对分析器进行学习，以此来建立一种概率统计下的识别模式，更多的来说是行为模式，比如正常用户的URL跳转流程，每分钟发送HTTP请求数量，HTTP包平均大小等。

3.5 状态管理

WAF能够判断用户是否是第一次访问并且将请求重定向到默认登录页面并且记录事件。通过检测用户的整个操作行为我们可以更容易识别攻击。状态管理模式还能检测出异常事件（比如登陆失败），并且在达到极限值时进行处理。这对暴力攻击的识别和响应是十分有利的。

参考下面的iptables规则:

# iptables -I INPUT -p tcp --dport 80 -m iplimit --iplimit-above 100 --iplimit-mask 24 -j REJECT

# iptables -I INPUT -p tcp --dport 23 -m iplimit --iplimit-above 2 -j REJECT

# iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT

# iptables -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT

# iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

# iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

3.6 URL策略/页面层策略

WAF可以在不修改源代码的情况下，为易受攻击的URL或页面打虚拟补丁。

1. 页面覆写
如果页面易受攻击且需要替换，则可以创建一个在运行时提交的替代页面或类，通过修改Web应用配置文件中的配置可以实现这种替换。在ASP.NET应用中，则可以使用HTTP句柄实现这一任务。

<httpHandlers>

    <add verb="*"

       path="PageVulnToSqlI.aspx"

       type="Chapter9.Examples.SecureAspxHandler, Subclass"

       validate="false" />

</httpHandlers> 

2. URL重写
URL重写是一种与页面覆写类似的技术。可以通过配置Web服务器或应用框架来接收那些发送给易受攻击页面或URL的请求，并将它们重定向到该页面的替代版本。页面的新版本通过一种安全的方式来实现原始页面逻辑。应该在服务器端实现这种重定向以保持与客户端的无缝相连。根据Web服务器和应用平台的不同，可通过多种方法来实现该任务。

Apache的mod_rewrite模块

http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html

和

.NET框架的urlMappings元素

http://msdn.microsoft.com/zh-cn/library/ms228302(VS.85).aspx

就是两个示例。

4. ModSecurity配置与分析

https://github.com/SpiderLabs/Mod

事实上，WAF的标准就是开源的ModSecurity。ModSucirty被开发成Apache的一个模块。

4.1 安装:

https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Windows_MS_VC_8

linux下可以通过数据源直接安装:

$ sudo yum install mod_security

$ sudo /etc/init.d/httpd restart

windows下需要下载.dll文件

http://www.apachelounge.com/download/

放到指定目录下(E:\wamp\bin\apache\Apache2.4.4\modules  根据你的环境而定)

修改httpd.conf中模块加载的加载项即可。

LoadModule security2_module modules/mod_security2.so

4.2 配置

ModSecurity 配置指令可以直接被添加到你的配置文件中(典型配置是在httpd.conf文件中)。但是他不一定确信这个模块被激活或者是禁止在web服务器启动的时候启动它(分布式配置文件机制 .htaccess)。它通常是将配置信息放在<IfModule>容器内.在没有激活这个模块的时候,它可以允许Apache跳过这个配置容器。

<IfModule security2_module>

    Include conf/security2/security2.conf

</IfModule>

自从Apache允许将一组配置数据保存在一个(例如modsecurity.conf)配置文件中，然后被httpd.conf 使用Include 方法调用。注意这里这路径:

E:\wamp\bin\apache\Apache2.4.4\conf\security2\security2.conf(根据你的具体环境而定)

保存后，重启apache:

表示配置成功。

4.3 规则编写学习

我们接下来从WAF在检测和防御SQL注入上使用到的技术来学习ModSecurity规则的编写。

1) 可配置规则集

https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-Configuration_Directives

web应用的环境是唯一的。WAF必须高度可配置才能适应各种不同的情况。ModSecurity的威力在于规则语言上，这种语言是配置指令和应用到HTTP请求和响应上的一种简单编程语言的组合。ModSecurity的结果通常是一个具体的动作，比如允许请求通过、把请求记录到日志或者阻塞该请求。

SecRule VARIABLE OPERATOR [ACTIONS]

VARIABLE: 告诉ModSecurity到哪里访问请求或响应(作用的对象)

OPERATOR: 怎样检查数据

ACTIONS: 出现"匹配"时做哪些操作(可选，它可以定义默认的全局动作)

处理HTTP请求时，可以对ModSecurity的规则进行配置以实现否定(黑名单)或肯定(白名单)的安全模型。

ModSecurity采用链式的规则模式(类似iptables中的路由链)，把整个HTTP交互检测过程分为5个阶段:

1. HTTP头部

2. HTTP内容

3. 服务器的回复HTTP包头部

4. 服务器的回复HTTP包内容

5. 日志记录

2)  规则编写(请求)

modsecurity_crs_40_generic_attacks.conf

# SQL injection

SecRule REQUEST_FILENAME|ARGS|ARGS_NAME

"(?:\b(?:(?:elect\b(?:.{1,100)?\b(?:(?:length

|count|top)\b.{1,100}?\

bfrom|from\b.{1,100}?\bwhere)|.*?\b(?:d(?:ump\b.*\bfrom|ata_type)|(?:to_

(?:numbe|cha)|inst)r))|p_(?:(?:addextendedpro|

sqlexe)c|(?:oacreat|prepar)e|execute

(?:sql)?|makewebtask)|ql_(?:longvarchar|variant))

xp_(?:reg(?:re(?:movemultistring|

ad)|delete(?:value|key)|enum(?:value|key)s|

addmultistring|write)|e(?:xecresultset|

numdsn)|(?:terminat|dirtre)e|availablemedia|loginconfig|

cmdshell|filelist|makecab|

ntsec)|u(?:nion\b.{1,100}?\bselect|tl_(?:file|http))

|group\b.*\bby\b.{1,100}?\

bhaving|d(?:elete\b\w*?\bfrom|bms_java)|load\b\w*?\bdata\b.*\

binfile|(?:n?varcha|tbcreato)r)\b|i(?:n(?:to\b\w*?\b

(?:dump|out)file|sert\b\w*?\

binto|ner\b\w*?\bjoin)\b|(?:f(?:\b\w*?\(\w*?\

bbenchmark|null\b)|snull\b)w*?\

()|a(?:nd\b ?(?:\d{1,10}|[\'\"][^=]{1,10}[\'\"]) ?[=<>]+|utonomous_

transaction\b)|o(?:r\b ?(?:d[1,10}|[\'\"][^=]{1,10}[\'\"])

?[=<>]+|pen(?:rowset|query)\b)|having\b ?(?:\d{1,10}|

[\'\"][^=]{1,10}[\'\"])

?[=<>]+print\b\w*>\@\@|cast\b\w*?\()|(?:;\w*?\b(?:

shutdown|drop)|\@\@version)\b|'(?:s(?:qloledb|a)|msdasql|dbo)')" \

"phase:2,capture,t:none,t:htmlEntityDecode,t:replac

eComments,t:compressWhit-eSpace,t:lowercase,ctl:

auditLogParts=+E,log,auditlog,msg:'SQL injection

Attack;, id:'950001',tag:'WEB_ATTACK/SQL_INJECTION',l

ogdata:'%{TX.0}',severity:

'CRITICAL'" 

我们来逐行对这个配置文件进行分析。

1. SecRule REQUEST_FILENAME|ARGS|ARGS_NAME

该规则是一个安全规则(SecRule)，用户分析数据并根据结果执行动作，并且我们在结尾处看到phase:2。代表这是链式检测中的第二阶段，就HTTP Body的检查。检查的范围(参数)是REQUEST_FILENAME(请求路径)|ARGS(POST数据)|ARGS_NAME(参数名)

2. "(?:\b(?.............msdasql|dbo)')" \

这是一段非常长的正则表达式，并且启用了捕获分组，直接用眼睛看压力有点大，我们可以借助一些正则工具来帮助我们识别和学习它的思路。

RegexBuddy: http://www.regexbuddy.com/

可以看到，规则对用户发送的数据中包含的敏感关键字进行了不区分大小写地匹配: 包括select, from, where等。

对字符型的split and balance绕过(使用+,|| 等连字符来拼接字符串，以及chr，char的使用)进行了防御。

对sqlserver的存储过程，xp_cmdshell,oracle的PL/SQL代码dbms_*进行了防御。

对Timing Attack的时间延迟性盲注benchmark进行了防御。

3. 规范化(canonicalization)

在前端安全技术中常见的编码绕过技术利用的就是不同系统间的编码位宽(addslashes()楼哦的那个)，不同编码的解码顺序(htmlParser和javascriptParser的解码顺序)，不同的解码规则(unicode->ascii转换中非可见字符的占位符问题)的这些"不一致性"导致的漏洞。

WAF为了解决这个"非规范化"带来的问题，在进行实际的检查前会对数据进行一次规范化处理。把所有输入转换成可预见和可控范围内的数据。让我们的规则能100%地匹配到目标对象。

t:none,t:htmlEntityDecode(html解码，HTML编码绕过思路),t:replac
eComments(删除注释，防御注释绕过/*! sql_code */这种漏洞利用),t:compressWhit-eSpace(/**/, 空格/*&id=*/等绕过思路),t:lowercase(绕过基于黑名的大小写畸形绕过思路: SleCt FroM ..)

ModSecurity的手册上能查到更详细的数据规范化的处理函数列表。

4. auditLogParts=+E,log,auditlog,msg:'SQL injection  Attack;, id:'950001',tag:'WEB_ATTACK/SQL_INJECTION',logdata:'%{TX.0}',severity:  'CRITICAL'"

借助之前的正则捕获分组特性将抓到的攻击参数记录进数据库，方便审计人员后续的跟进以及0DAY的捕获。注意在这之前要进行转义处理以避免日志伪造攻击(success/r admin faild...伪造换行符的攻击)。

总体来说，ModSecurity的这个规则集是基于消极模型的黑名单规则，它们可以根据应用产生错误肯定。因而，这些动作action的最好的动作就是log。因为黑名单是一种经验的产物，只要被黑名单匹配到就"一定(相对)"是一种攻击模式。而要实现白名单，我思考了一下正则代码，感觉就要难很多，首先要解决的第一个问题就是： 什么样的行为是正确的，不同的应用(银行系统，CMS，B2C)的业务差别很大，用户在浏览和使用过程中产生的点击行为也差别很大，例如对于银行业务来说，用户的操作一般是遵循一条线性的轨迹，不会差太多。而对于B2C网站来说，往往各个连接之间的关联不是很大，用户经常会产生跳跃性URL。这个行为模式很难去界定。

我唯一能想到的就是可以对参数的类型和范围做一个白名单限定。假如在script.php的请求中必须包含一个id参数，它的值必须是1~3位长度的数字。我们可以这样编写正则表达式:

<Location /app/script.php>

　　SecRule &ARGS "!@eq 1"

　　SecRule ARGS_NAMES "!^id$"

　　SecRule ARGS:id "!^\d{1,3}$"

</Location>

3)  规则编写(响应)

WAF在减轻SQL注入的影响方面还有另外一个关键特性---抑制关键信息泄漏。

modsecurity_crs_50_outbound.conf

# SQL Errors leakage

SecRule RESPONSE_BODY

"(?:\b(?:?:s(?:elect list because it is not contained

in (?:an aggregate function

and there is no|either an aggregate function or the)

GROUP BY clause|upplied

argument is not a valid (?:(?:M(?:s |y)|Postgre)SQL|O

(?:racle|DEC)))|S(?:yntax

error converting the \w+ value .*? to a column of

data type|QL Server does not

exist or access denied)|Either BOF is True , or the

current record has been

deleted(?:; the operation|\. Requested)|The column

prefix .{0,50}? does not match with a table name or

alias name used in the query|Could not find server '\w+' in

sysservers\. execute sp_addlinkedserver)\b|Un(?:closed

quotation mark before the

character string\b|able to connect to PostgreSQL

server:)|(?:Microsoft OLE DB

Provider for .{0,30} [eE]rror |error '800a01b8)'|

(?:Warning: mysql_connect\

(\)|PostgreSQL query failed):|you hava an error in

your SQL syntax(?: near

'|;)|cannot take a \w+ data type as an argument\*.

|incorrect syntax near

(?:\'|the\b|@@error\b)|microsoft jet database engine

error'8|ORA-\d(5)}: ) |\[Microsoft\]\[ODBC]"\"Phase:

4,t:none,ctl:auditLogParts=+E,deny,log,auditlog,

status:500,msg:'SQLInformation Leakate',id:'970003',

tag:'LEAKAGE/ERRORS', severity:'4'" 

同样，我们也用RegexBuddy来对这段正则进行分析。

这里要明确一点。一般来说，泄露与应用行为有关的不必要的信息会明显帮助攻击者发现应用中的弱点。这些信息包括软件版本(攻击者可以针对性的进行NDAY攻击)和与应用失败有关的错误明细(sqlserver的错误回显尤其严重，例如利用强制类型转换的错误回显注入)，比如发生在数据库服务器上的sql语法错误。有时候，不仅错误信息本身，攻击者还可以利用sql的逻辑推理来实施盲注。

规则很好的实现了这一思想，对一些主流数据库可能的错误回显进行了黑名单过滤。确保不会产生明显的错误回显，同时我们可以看到，这种规则没有对基于推理的盲注进行防御。事实上，防御盲注的最好方式是在代码层进行安全编码，包括对所有的涉及数据库操作的代码实施错误处理机制，使用定制化的200错误页(这种方法无法防御时间型盲注，防御实时间型盲注要从请求中进行过滤敏感函数)。

5. 总结

可以使用传统的基于网络的IDS(Intrusion Detection Systems)来检测SQL注入攻击。但这些IDS距离应用和Web服务器非常远，通常不是最理想的选择。如果已经在网络中运行了这样一种IDS，则可以修改它并将其作为防御的起始线。

可以将WAF作为一种非常好的IDS，因为它运行在应用层并且可针对受保护的应用进行微调。大多数WAF都附带有一种被动模式和警告功能。在许多产品应用环境中，会优先使用这种功能中的安全过滤器或WAF。可以使用它们来检测攻击并向管理员发出警告，管理员之后可以决定对该漏洞采取何种措施(例如，为特定的页面/参数组合启用恶意请求阻塞或者应用虚拟补丁)。

另一种选择是使用PHPIDS(https://phpids.org/) 这样的嵌入式解决方案。PHPIDS不会过滤或审查输入，它检测攻击并根据配置来采取措施。其覆盖范围从简单的日志记录到向开发团队发送一封紧急情况的e-mail、为攻击者显示一条警告信息甚至是结束用户会话。