走進科學 WAF(Web Appllication Firewall)

時間 2019-11-24

標籤走進科學 waf web appllication firewall 欄目 HTML 简体版

原文原文鏈接

1. 前言

當WEB應用愈來愈爲豐富的同時，WEB 服務器以其強大的計算能力、處理性能及蘊含的較高價值逐漸成爲主要攻擊目標。SQL注入、網頁篡改、網頁掛馬等安全事件，頻繁發生。

企業等用戶通常採用防火牆做爲安全保障體系的第一道防線。可是，在現實中，他們存在這樣那樣的問題，例如傳統的防火牆體系沒法對當前快速爆發和蔓延的0DAY漏洞進行快速響應和對抗，而要完全解決此類漏洞的代碼審計和代碼修補每每須要較長的時間，由此產生了WAF（Web應用防禦系統）。TecNova-WAF Web應用防禦系統（Web Application Firewall, 簡稱：WAF）表明了一類新興的信息安全技術，用以解決諸如防火牆一類傳統設備一籌莫展的Web應用安全問題。與傳統防火牆不一樣，WAF工做在應用層，所以對Web應用防禦具備先天的技術優點。基於對Web應用業務和邏輯的深入理解，WAF對來自Web應用程序客戶端的各種請求進行內容檢測和驗證，確保其安全性與合法性，對非法的請求予以實時阻斷，從而對各種網站站點進行有效防禦。

javascript

2. WAF分類php

WAF是一種網絡設備(硬件WAF)或者是一種將安全特性添加到web應用(軟件的內置WAF)的基於軟件的解決方案。即WAF從定義上能夠分爲:html

硬件WAF:前端

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

http://www.barracuda.com.cn/products/ 梭子魚Web應用防火牆mysql

http://www.venustech.com.cn/SafeProductInfo/413/39.Html 天清Web應用安全網關
linux

軟件WAF:git

http://www.modsecurity.org/projects/modsecurity Apache的一塊模塊ModSecuritygithub

https://phpids.org/ 爲PHP應用設計的WAF系統web

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、爲攻擊者顯示一條警告信息甚至是結束用戶會話。