FastCGI 作為反向代理協定：明確分幀與標頭域隔離消滅 HTTP 請求夾帶攻擊
agwa.name (Andrew Ayer) · 2026-04-29
Andrew Ayer 在 2026 年 4 月 29 日重新審視 FastCGI，主張這個誕生於 1996 年的協定在安全性架構上優於現代 HTTP 反向代理方案。其核心論點圍繞 HTTP/1.1 的兩個結構性缺陷。
HTTP/1.1 的訊息邊界問題
HTTP/1.1 使用文字分隔符號（如 Content-Length 與 Transfer-Encoding chunked）來界定請求邊界。當前端代理與後端應用伺服器對這些標頭的解釋存在歧異時，攻擊者可以構造一個請求讓代理視之為一筆、後端視之為兩筆，形成 HTTP Request Smuggling。這類漏洞（如 TE-CL、CL-TE 等變體）已在真實環境中被大量利用。
HTTP/1.1 的標頭域混淆問題
HTTP 反向代理必須區分「來自用戶端的不可信標頭」與「代理自身注入的可信資訊」（如 X-Forwarded-For、REMOTE_ADDR）。由於兩者都透過同一個 HTTP 標頭空間傳遞，惡意用戶端可以注入偽造的 X-Real-IP 或 REMOTE_ADDR 標頭，若代理未正確覆蓋或過濾，後端程式將收到偽造的客戶端資訊。
FastCGI 如何結構性解決這兩個問題
FastCGI 使用二進位分幀，每個記錄包含類型、請求 ID、內容長度及 padding 長度，邊界由協定本身明確定義，不依賴可被操弄的文字標頭，從而消滅請求夾帶的可能性。在標頭域隔離方面，FastCGI 的設計規範規定：來自用戶端的 HTTP 標頭必須以 HTTP_ 前綴傳遞（如 HTTP_X_FORWARDED_FOR），而代理注入的伺服器端資訊（如 REMOTE_ADDR、SERVER_NAME）使用不帶前綴的標準參數名稱。後端程式只需信任非 HTTP_ 前綴的參數，就能安全地區分兩個來源。
與 HTTP/2 的比較
HTTP/2 以二進位幀解決了分幀問題，但在反向代理場景中，前端通常是 HTTP/2 而後端仍是 HTTP/1.1，翻譯層重新引入了不一致性。FastCGI 則從一開始就為「代理與應用伺服器之間的通訊」設計，不需要跨協定版本轉換。
原始來源：agwa.name — FastCGI: 30 Years Old and Still the Better Protocol for Reverse Proxies
Rust 型別系統的邊界：uutils coreutils 的 44 個 CVE 解析
corrode.dev · 2026-04-29
一項針對 uutils（Rust 重寫版 GNU coreutils）的外部安全稽核發現 44 個 CVE。這份清單揭示了 Rust 編譯器提供記憶體安全保證的同時，無法阻止哪些種類的漏洞。
TOCTOU（時間競態）
最大的漏洞群來自多次 syscall 作用於同一路徑之間的時間視窗。CVE-2026-35355 為典型範例：
fs::remove_file(to)?;
let mut dest = File::create(to)?; // 此處重新解析路徑在 remove_file 與 create 之間，擁有父目錄寫入權限的攻擊者可以插入一個指向 /etc/shadow 的符號連結，使後續的 File::create 截斷敏感檔案。修正方式是使用 OpenOptions::create_new(true)，該呼叫明確拒絕符號連結目標。根本原因是 Rust 標準函式庫的高階 API（fs::metadata、File::create）每次呼叫都重新解析路徑，缺乏 C 語言 openat/fstatat 那種以檔案描述符為錨點的原子操作。
UTF-8 邊界問題
Rust 的 String/&str 強制要求 UTF-8，在處理 Unix 系統呼叫（檔名、路徑）時產生三種有問題的模式：from_utf8_lossy 會靜默將無效位元組替換為 U+FFFD（資料損毀）；unwrap/? 在非 UTF-8 輸入時觸發 panic（拒絕服務）；正確做法是透過 OsStr 或 &[u8] 保留原始位元組。CVE-2026-35346（comm 工具）即因 String::from_utf8_lossy 損毀二進位檔案而入選。
信任邊界穿越前的資源解析
CVE-2026-35368（chroot，最嚴重漏洞）展示了在 chroot 之後呼叫 get_user_by_name 的問題：該函式會從新根目錄載入 libnss_* 共用函式庫，允許攻擊者控制的檔案系統以 uid 0 執行任意程式碼。修正是在穿越信任邊界之前完成所有資源解析。
Panic 作為拒絕服務向量
CVE-2026-35348（sort --files0-from）在收到非 UTF-8 檔名時呼叫 expect() 觸發 panic，終止整個 process。在排程工作或 CI 管線中，此類崩潰形成系統層級中斷。文章建議使用 Clippy lint（unwrap_used、expect_used、panic 設為 warn）防止此類模式進入程式碼庫。
Rust 防住的問題
作為對比，44 個 CVE 中沒有任何緩衝區溢位、use-after-free、double-free、資料競態或 null 指標解引用——這些在 GNU coreutils 的同類漏洞中均有前例。
型別系統的根本限制
「型別系統可以編碼許多事物，但無法編碼其控制範圍之外的條件，例如兩次 syscall 之間的時間流逝。」Rust 的安全保證不延伸至語意層級的系統狀態、時序或外部行為。
穩定版 Rust 中的可觀測特化：以 FusedIterator 保證為基礎
goldstein.lol · 2026-04-28
Rust 的特化（specialization）功能長期以來僅在 nightly 版本中提供，且由於健全性問題而多次延期穩定。然而，作者在 2026 年 4 月發現一個在穩定版 Rust 上確實可觀測的特化行為，且此行為有文件保證。
核心機制：FusedIterator 與 .fuse() 的無操作保證
標準函式庫文件明確說明：對一個已實作 FusedIterator 的迭代器呼叫 .fuse() 是 no-op——編譯器保證這個包裝是零成本的。這是 Rust 標準函式庫中唯一有文件保證的特化。
利用此保證偵測 Send
作者設計了一個 Checker<T> 迭代器，追蹤迭代次數。透過有條件地僅對滿足 T: Send 的型別實作 FusedIterator，可以在執行期觀察 .fuse() 是否產生包裝——從而偵測 T 是否 Send：
impl<T: Send> FusedIterator for Checker<T> {}
// 若 T: Send，.fuse() 是 no-op，迭代次數不變
// 若 T: !Send，.fuse() 加入包裝，可從呼叫計數觀察到差異意義
這表示在穩定版 Rust 中，可以透過完全合規的記錄行為（documented behavior）在執行期觀測型別是否實作某個 trait，形成一種受限但真實的特化效果。作者表示：「這是我所知唯一一個有保證會發生的特化……因此我相信這是在穩定版 Rust 上僅靠記錄行為觀測特化的可能途徑。」
Odin 語言設計哲學：受惠語法（Blessed Syntax）vs. 可廣義化語法
gingerbill.org (Bill Hall) · 2026-04-29
Odin 語言的設計者 Bill Hall 在 2026 年 4 月詳細闡述語言設計中「受惠語法」（Blessed Syntax）的概念，以及 Odin 為何選擇限制使用者定義的運算子多載。
兩種陣營的對立
語言設計存在兩條路線：「務實陣營」（C、Pascal 等）直接為常見場景提供特殊語法支援，但不允許使用者以相同方式擴展；「可廣義化陣營」（C++、Rust、Haskell 等）讓使用者定義的型別能獲得與內建型別相同的語法待遇。
受惠語法的設計取捨
Odin 明確選擇前者。對於字串、陣列、切片、哈希映射、列舉陣列（enumerated arrays）和位元集（bit sets），Odin 提供特化的內建語法。使用者無法以任意型別重複這些語法，但這帶來一個好處：整個生態系統中不會出現十幾個互不相容的「字串類型」，每個都有略微不同的 + 語義。
方言形成問題
Hall 認為廣義化運算子多載最大的代價是「方言形成」（dialect formation）——每個函式庫都可能在 <<、*、| 等符號上賦予不同語義，使程式碼的可讀性依賴於使用者對所有相關函式庫的熟悉程度。受惠語法透過明確限制，讓程式碼在慣用方式（idiomatic）上維持一致。
核心原則：「非常好地解決平均常見情況，而非允許能力去（拙劣地）解決一切問題。」
.NET Agent Governance Toolkit：MCP 工具呼叫的策略引擎與威脅偵測
Microsoft .NET Blog · 2026-04-29
Microsoft 於 2026 年 4 月 29 日發布 Agent Governance Toolkit（AGT），這是一個用於 .NET 環境中控管 Model Context Protocol（MCP）工具呼叫的管線框架，目標是讓 AI agent 在生產環境中能受到可稽核的策略約束。
架構：四層管線
AGT 圍繞 GovernanceKernel 為核心，串接以下元件：
- McpGateway：攔截所有工具呼叫，在執行前套用完整評估管線
- McpSecurityScanner：工具定義的預執行驗證，偵測 typosquatting、描述中的提示注入（prompt injection）模式以及嵌入的惡意 URL，並對每個工具定義計算風險評分（0–100）
- McpResponseSanitizer：工具輸出的後處理過濾
- GovernanceKernel：以 YAML 宣告式策略為基礎的中央協調器
策略定義與衝突解析
策略以 YAML 撰寫，包含條件、動作（allow/deny/rate-limit）與優先序，多條策略衝突時由 ConflictResolutionStrategy（如 DenyOverrides）決定結果：
var kernel = new GovernanceKernel(new GovernanceOptions
{
PolicyPaths = new() { "policies/mcp.yaml" },
ConflictStrategy = ConflictResolutionStrategy.DenyOverrides,
EnableRings = true,
EnablePromptInjectionDetection = true
});可觀測性
AGT 內建 OpenTelemetry metrics 追蹤策略決策、封鎖次數、速率限制觸發與評估延遲。稽核事件訂閱允許跨 agent 操作記錄治理決策。
技術規格
框架目標 .NET 8.0+，唯一外部相依是 YamlDotNet，不需要外部服務。工具呼叫在執行前完成評估，通過後才將淨化後的參數傳遞給工具。