關於繞過IISWAF-POST注入的一種思路猜想
本文是一種設想繞過IIS WAF的思路猜想，並不代表真正的有這樣的漏洞，連作者自己都沒有去驗證過，僅當大家在吃完晚飯以後刷刷Freebuf打發時間吧。IIS僅限於IIS6，當然不排除把IIS6的外掛丟到IIS7上面跑的情況。
一. IIS WAF是什麼？
什麼是WAF，關於這個問題不多解釋，連面試官都問過我好幾次。 IIS WAF是一種利用IIS的ISAPI FILTER外掛來完成的一種過濾，攔截WEB工具的軟牆。該外掛直接安裝於IIS擴充套件屬性裡。市面上面對應的有早期的MYIIS-VIF，如今的什麼什麼盾，什麼什麼狗，什麼什麼寶，什麼什麼防篡改系統。但隨著時間的推移，在基於埠轉發的NGINX的waf成為了主流（統一攔截）。
二. IIS WAF是怎麼做成的？
相關的安裝文章等，大家可以在這裡看到： ofollow,noindex" target="_blank">https://docs.microsoft.com/en-us/iis/configuration/system.webServer/isapiFilters/ 通俗點，就是利用微軟提供的介面文件提前捕獲了使用者的輸入和輸出場景，然後用安全的套路去規劃和尋找安全風險點。詳細的介面文件大家可以看到這裡： https://msdn.microsoft.com/zh-tw/library/ms525878.ASPX
三. 針對SQL%E6%B3%A8%E5%85%A5/">SQL注入來具體聊聊
SQL注入是web安全裡的大頭，特別是POST注入環節。所有，如果你的滲透測試行為在提交POST引數的被攔截了，肯定是非常頭疼的。針對sdk開發中HttpFilterProc回撥函式中，對POST資料的攔截主要在回撥訊息：SF_NOTIFY_READ_RAW_DATA中。
針對SF_NOTIFY_READ_RAW_DATA的訊息引數分析，我們可以看到這樣的資料結構資訊：
typedef struct _HTTP_FILTER_RAW_DATA HTTP_FILTER_RAW_DATA { PVOID pvInData; DWORD cbInData; DWORD cbInBuffer; DWORD dwReserved; } HTTP_FILTER_RAW_DATA, * PHTTP_FILTER_RAW_DATA;
pvindata是傳入的原始資料指標地址，cbinData是傳入的總資料大小，cbinbuffer是傳入的現有資料大小。為了組合資料，我們需要在這個訊息體裡不斷分配記憶體去拼合資料。站在攻防的角度來分析問題，此時此刻我們應該站在軟體設計者的角度來分析問題，因為為了防護的效能和效果，很可能在防護軟體開發中存在一些安全程式碼空洞。
（1） 如何檢測傳入資料的安全？
對每個cbinbuffer進行檢查，包括用正則表示式掃描。
（2）可以把資料全部組合完畢後一起掃描嗎？
可行，但萬一使用者提交的資料非常非常大怎麼辦？不要把自己玩死。
（3）是否可以折中？
可以，只檢測資料前1M的內容。後面的忽略？！
（4）武斷點？
只要cbinData夠大，就直接斷開連線或者輸出錯誤資訊。但這樣做是不完整的，是不夠人性的，是tmd的很武斷的……………………..
四 . 攻擊猜想
針對cbinBuffer的資料大小，有2000位元組的規定，也就是說，我們提交的資料是以做多2000位元組的一個Buff來進行處理的。我們是否可以提交這樣的資料：
猜想1：
AAAAAAAAAAAAAAAA……AAASEL(2000 BYTE)
ECTAAAAAAA*AAAAA…….AAAF(2000 BYTE)
ROMAAAAAAAAAAAA……AAAA(2000 BYTE)
猜想2：
AAAAAAAAAAAAAA..(200000)……..
（猜想1的資料）
這樣的模式是構建比較大的資料，在2000緩衝區的折斷區存放需要注入的關鍵字和資料內容，從而繞過針對特定關鍵字的檢查。反正，都是腦洞大開了，怎麼去研究和測試，留給青少年們去吧，反正都是一種猜想，想想而已。歡迎大家來評論區一起碰水。下回我來給大家繼續聊聊NGINX waf常被人繞過和忽略的中招小姿勢。
關於作者：顧問級網路安全專家，首席軟體設計師，有多年大型安全產品和滲透工具的開發經驗，理論與實踐相結合型。專注於大資料分析、資料建模，趨勢分析。MYIIS-VIF軟體作者(IIS WAF)。