http connection有兩種連線方式:短連線和長連線;
短連線即一次請求對應一次tcp連線的建立和銷毀過程。
長連線是多個請求共用同乙個連線這樣可以節省大量連線建立時間提高通訊效率。目前主流瀏覽器都會在請求頭裡面包含connection:keep-alive欄位,該字段的作用就是告訴http伺服器響應結束後不要關閉連線,瀏覽器會將建立的連線快取起來,當在有限時效內有再次對相同伺服器傳送請求時則直接從快取中取出連線進行通訊。當然被快取的連線如果空閒時間超過了設定值(如firefox為115s,ie為60s)則會關閉連線。
長連線也叫持續連線,短連線也叫非持續連線。
持續連線存在的問題:對於非持續連線,瀏覽器可以通過連線是否關閉來界定請求或響應實體的邊界;而對於持續連線,這種方法顯然不奏效。有時,儘管我已經傳送完所有資料,但瀏覽器並不知道這一點,它無法得知這個開啟的連線上是否還會有新資料進來,只能傻傻地等了。
用content-length解決:計算實體長度,並通過頭部告訴對方。瀏覽器可以通過 content-length 的長度資訊,判斷出響應實體已結束
content-length引入的新問題:由於 content-length 字段必須真實反映實體長度,但是對於動態生成的內容來說,在內容建立完之前,長度是不可知的。這時候要想準確獲取長度,只能開乙個足夠大的buffer,等內容全部生成好再計算。但這樣做一方面需要更大的記憶體開銷,另一方面也會讓客戶端等更久。
我們需要乙個新的機制:不依賴頭部的長度資訊,也能知道實體的邊界——分塊編碼(transfer-encoding: chunked)
transfer-encoding,是乙個http頭部字段(響應頭域),字面意思是「傳輸編碼」,最新的http規範裡,只定義了一種編碼傳輸:分塊編碼(chunked)。
分塊傳輸編碼(chunked transfer encoding)是超文字傳輸協議(http)中的一種資料傳輸機制,允許http由網頁伺服器傳送給客戶端的資料可以分成多個部分。分塊傳輸編碼只在http協議1.1版本(http/1.1)中提供。資料分解成一系列資料塊,並以乙個或多個塊傳送,這樣伺服器可以傳送資料而不需要預先知道傳送內容的總大小。
在頭部加入transfer-encoding:chunked之後,就代表這個報文採用了分塊編碼。這時,報文中的實體需要改為用一系列分塊來傳輸。
每個分塊包含十六進製制的長度值和資料,長度值獨佔一行,長度不包括它結尾的crlf(\r\n),也不包括分塊資料結尾的crlf。
最後乙個分塊長度值必須為0,對應的分塊資料沒有內容,表示實體結束。
訊息體格式如下:
hex的分塊長度+回車+換行
chunked data
結束塊的分塊長度為0
例如:
如要傳送的內容(訊息體)為:123456789
那麼訊息體的格式為:
91234567890
content-encoding 和 transfer-encoding 二者經常會結合來用,其實就是針對 transfer-encoding 的分塊再進行 content-encoding壓縮。
分塊傳輸可以在長度標識處加上分號「;」作為注釋,幾乎所有可以識別transfer-encoding資料報的waf,都沒有處理分塊資料報中長度標識處的注釋,導致在分塊資料報中加入注釋的話,waf就識別不出這個資料報了。如:
9;kkkkk
1234567=1
4;ooo=222
2345
0(兩個換行)
靶環境:xampp+sqlibs+安全
編寫Burp分塊傳輸外掛程式繞WAF
我們先來看看外掛程式要實現的功能 在burp repeater套件上可對資料報進行快速chunked解碼編碼 自動化對burp的proxy,scanner,spider等套件的資料報進行編碼 可設定分塊長度,是否開啟注釋限於邊幅,我只說明核心函式,並通過注釋的方式解釋 的相關功能。2.1 編碼函式 ...
sql注入型別 步驟以及繞waf注入
一 sql注入 sql注入就是是一種將 sql語句插入或新增到應用 使用者 的輸入 引數中的攻擊,之後再將這些引數傳遞給後台的sql伺服器加以解析並執行。最終使使用者可控的輸入被帶入到了資料庫中進行執行。1.1存在 sql注入的地方大致有 l get l post l cookie l http頭部...
WAF繞過的一些總結和思考,WAF怎麼防繞過。
資料報 waf 利用string儲存請求引數,解碼後檢測 apac he c 語言等利用string等儲存結構儲存請求,在解碼時,00會成為 null 從而截斷接下去的請求內容 因此例如 id 1 00 20and 201 1 就成為了 id 1 從而繞過waf檢測 型別2 fuzz.php cod...