# HTTP request smuggling Lab3

本題是 HTTP Request Smuggling 來繞過前端安全控制（CL.TE 漏洞），目標是：偷偷從後端請求 /admin/delete?username=carlos，把 carlos 幹掉。

重點：
- 前端會阻擋對 `/admin` 路徑的請求。
- 後端支援 `/admin` 路徑，但只接受 `Host: localhost`。
- 前端不支援 chunked encoding（這就是 CL.TE 的開場白）。

核心概念：CL.TE
- 前端根據 Content-Length 切包（CL）
- 後端根據 Transfer-Encoding 處理（TE）

也就是你把第二段請求藏在第一段 request 的 body 裡，
前端不會看到它，後端卻會執行。

所以一樣先進入網站並攔截封包。


這裡直接去 admin 看確實會被擋下來。


所以一樣寫 chunk 內容，並在第二次請求中指定去 admin 的頁面。


這裡他炸 401，因為我們去 admin 介面的時候沒帶 cookie 被攔下來。


所以我們在請求中嘗試加上 localhost 看看。


結果重複 Host 被他擋下來。


所以我們嘗試想辦法讓 smuggled 請求「吃掉」第二個 request 的 header。


前端看到：

- 從 Transfer-Encoding 開始到 0 結尾，算一段 chunk，
- `Content-Length: 116` 包含了這段 chunk 跟後面的字串，前端只依
content-length 截斷請求體，不理會 chunk 格式。

後端看到：

- 用 chunked 解碼，把 0 視為 chunk 結尾，
- 後面跟著的 `GET /admin...` 等字串，變成了新的請求（因為 chunked 編碼解析後，body剩餘這段沒被吃掉），
- 直接把它當成獨立請求處理。

:::info
### 前端和後端的角色不同

前端伺服器只根據 `Content-Length: 116` 來讀請求的長度，讀了116個字元就停，不管 Transfer-Encoding。

後端伺服器因為有 `Transfer-Encoding: chunked`，它會按照 chunked 編碼方式解析請求體，直到遇到 chunk 結尾 0\r\n\r\n。

### 為什麼 header 被吃掉？

因為「第二段請求」的 header 就在 chunked body結尾後面，前端只看 content-length 截斷，後端用 chunked 編碼讀，兩個解讀標準不一樣，導致後端「看到」了完整第二段請求的 header，變成真正的第二個 HTTP request。
:::


當然也成功了，所以接著是砍掉目標使用者，從 admin 的頁面可以看到砍掉使用者的連結是啥。


/admin/delete?username=carlos

所以我們丟回請求中在試試。


---