ASP.NET 4.0 請求驗證失效原因與解決方案

ASP.NET 內建請求驗證可防範 XSS 攻擊，但在需要接收 HTML 內容（如富文本編輯器）時必須關閉。ASP.NET 4.0 改變驗證時機，導致傳統關閉方式失效。本文解析原因並提供解決方案。

現象

在 ASP.NET 2.0/3.5 中，於 web.config 設定 <pages validateRequest="false" /> 或頁面指令 <%@ Page ValidateRequest="false" %> 即可關閉。但在 4.0 仍會拋出：

A potentially dangerous Request.Form value was detected from the client.

根本原因

• 驗證時機提前：4.0 以前驗證發生在頁面處理階段，可依頁面設定決定是否驗證。4.0 將驗證移至 IHttpHandler.BeginRequest 之前，即所有進入 ASP.NET 管線的請求（含 Web Service、HttpHandler、HttpModule）皆會驗證。
• 尚未建立 Handler：驗證執行時尚未實例化 Handler，無法讀取頁面的 ValidateRequest 設定，故頁面級設定失效。

解決方案：恢復 2.0 行為模式

在 web.config <system.web> 區段加入：

<httpRuntime requestValidationMode="2.0" />

此設定指示 ASP.NET 使用舊版驗證邏輯，僅在頁面處理階段驗證，並尊重頁面/設定檔的 validateRequest="false"。

完整 web.config 範例

<configuration>
  <system.web>
    <httpRuntime requestValidationMode="2.0" />
    <pages validateRequest="false" /> <!-- 全域關閉，或在單頁指令關閉 -->
  </system.web>
</configuration>

MASP.NET MVC 專案

• 控制器/動作標記 [ValidateInput(false)]（需搭配上述 requestValidationMode="2.0"）。
• 或針對特定屬性使用 [AllowHtml] 屬性（Model 層級），更精確控制。

安全性警示

• 關閉驗證後，必須自行對使用者輸入進行編碼/過濾（輸出時使用 HttpUtility.HtmlEncode、Razor 自動編碼、或 AntiXSS Library）。
• 僅對必要頁面/欄位關閉，避免全站關閉。
• 考慮使用成熟編輯器（CKEditor、TinyMCE）內建 XSS 過濾。

ASP.NET Core 差異

Core 預設不啟用請求驗證，採用輸出編碼策略（Razor 自動 HTML 編碼），開發者需專注於輸出端安全，較符合現代 Web 安全觀。