走進科學 WAF(Web Appllication Firewall)

Andrew.Hann發表於2013-11-21

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/modsecurity Apache的一塊模組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、為攻擊者顯示一條警告資訊甚至是結束使用者會話。

走進AI科學之美
2019-09-17
AI
Azure Front Door（三）啟用 Web Application Firewall (WAF) 保護Web 應用程式，拒絕惡意攻擊
2021-03-26
WebAPP
《黑神話：悟空》爆紅之後，我走進了遊戲科學
2020-09-14
遊戲
Web應用安全防護-WAF
2021-08-29
Web
JavaEE學習之走進JSP
2020-12-23
JavaJS
走進小作坊（十一）----移動web實現指南
2014-07-15
Web
美國科學促進會：機器學習“正在導致科學危機”
2019-02-25
機器學習
什麼是 Web 應用防火牆（WAF）？
2020-04-11
Web防火牆
全新 Cloudflare Web 應用程式防火牆（WAF）
2021-08-12
CloudWeb防火牆
走進Java
2020-12-15
Java
讀懂深度學習，走進“深度學習+”階段
2023-01-13
深度學習
SpringCloud學習之路（一）- 走進SpringCloud
2019-03-25
SpringGCCloud
走進前端的過程--方向式學習
2019-01-16
前端
提高學習改進記憶的科學方法
2016-05-15
資料科學難在實踐，有哪些彎路可以不走？
2019-03-22
資料科學
六個學習方法帶你走進學習狀態
2020-12-08
科學技術部：2019年度中國科學十大進展
2020-02-27
走進Oracle世界
2020-01-23
Oracle
【RabbitMQ】走進RabbitMQ
2017-03-12
MQ
【總結】淺析Waf優缺點之硬體Waf、軟體Waf、雲Waf
2017-12-26
為什麼要部署Web應用防火牆（WAF）？
2020-01-09
Web防火牆
讓小白不走彎路：學習web前端流程，以及學習誤區
2019-10-31
Web前端
go 學習筆記之走進Goland編輯器
2019-08-07
筆記GoLand
走進 JDK 之 Integer
2019-02-27
JDK
走進 JDK 之 Boolean
2019-03-26
JDKBoolean
走進 JDK 之 Float
2019-03-09
JDK
走進 JDK 之 Long
2019-03-04
JDK
走進 JDK 之 Enum
2019-04-18
JDK
走進springboot
2021-04-03
Spring Boot
帶你走進 Redis
2022-12-30
Redis
走進mysql基礎
2018-02-04
MySql
騰訊雲WEB應用防火牆(WAF)如何修改DNS解析?
2020-11-18
Web防火牆DNS
打造一款可靠的WAF（Web應用防火牆）
2017-12-26
Web防火牆
讓科學重回資料科學
2017-03-13
資料科學
防火牆（firewall）
2023-03-07
防火牆
OpenResty學習筆記03：再探WAF
2023-05-10
REST筆記
漫說安全｜智慧的雲WAF，開掛的Web防禦
2019-01-15
Web
走進WebApiClientCore的設計
2020-05-20
WebAPIclient

走進科學 WAF(Web Appllication Firewall)

相關文章