SQL 特殊字元處理完整指南：防注入、防 XSS、資料庫寫入與輸出編碼

使用者輸入是資安防護的第一道防線。本文系統性整理特殊字元在「資料庫操作」與「頁面輸出」兩大場景的處理策略，涵蓋單引號轉義、HTML 編碼、URL 參數防護，並提供可直接使用的 ASP/VBScript 函數。

一、資料庫操作場景

1.1 寫入操作

動態 SQL 拼接： 必須將單引號 ' 雙化為 ''，SQL Server 會儲存為單一單引號。

Function SQLEncode(fString)
    If IsNull(fString) Then SQLEncode = "" : Exit Function
    SQLEncode = Replace(fString, "'", "''")
End Function

' 使用範例
sql = "INSERT INTO users (name) VALUES ('" & SQLEncode(username) & "')"

ADO Recordset AddNew / 參數化查詢 / 預存程序： 完全不需手動轉義，驅動程式與資料庫引擎自動處理參數綁定，杜絕注入風險。強烈建議優先使用預存程序或參數化查詢。

1.2 查詢條件

無論 SELECT、UPDATE、DELETE 的 WHERE 子句，若使用動態 SQL 拼接，必須對單引號雙化，同 SQLEncode 函數。

二、頁面輸出場景（防 XSS）

2.1 一般輸出

使用 Server.HTMLEncode() 將 <、>、"、& 轉為 HTML 實體。但 不處理單引號、空格、換行。

2.2 表單控件輸出（含 textarea）

務必使用雙引號包裹 value 屬性，並套用 Server.HTMLEncode()：

<input type="text" name="uname" value="<%=Server.HTMLEncode(username)%>">

若用單引號包裹，攻擊者輸入 ' onclick='alert(1) 即可突破屬性邊界執行腳本。

2.3 保留格式的輸出（textarea 內容顯示在 div 等區塊）

Server.HTMLEncode() 不轉換空格與換行，需自訂函數：

Function HtmlEncode(fString)
    If Not IsNull(fString) Then
        fString = Replace(fString, ">", ">")
        fString = Replace(fString, "<", "<")
        fString = Replace(fString, Chr(34), """)  ' 雙引號
        fString = Replace(fString, Chr(39), "'")  ' 單引號
        fString = Replace(fString, Chr(32) & Chr(32), "  ") ' 雙空格
        fString = Replace(fString, Chr(9), " ")       ' Tab
        fString = Replace(fString, Chr(10), "
")    ' 換行 LF
        fString = Replace(fString, Chr(13), "")        ' 回車 CR
        HtmlEncode = fString
    End If
End Function

三、URL 參數傳遞

建議僅傳遞數值型參數，接收端以 IsNumeric() 或 CLng() 驗證。字串參數若必須透過 URL 傳遞，需雙重編碼：Server.URLEncode(SQLEncode(str))，接收端先 Server.URLDecode 再 SQLEncode。

四、總結：九大防護原則

1. 驗證輸入資料型別（數值、日期、長度、格式）。
2. 優先使用預存程序操作資料庫。
3. 次優先使用 AddNew / 參數化查詢。
4. 動態 SQL 的查詢條件必須經 SQLEncode() 處理單引號。
5. 表單控件 value 屬性永遠用雙引號包裹。
6. 控件輸出資料套用 Server.HTMLEncode()。
7. textarea 內容輸出區塊套用自訂 HtmlEncode() 保留格式。
8. 使用 Request.Form()、Request.QueryString() 明確指定來源，避免 Request() 模糊查找。
9. 避免 URL 傳遞字串參數，僅限數值參數。

誤區提醒： 客戶端 JavaScript 過濾不可靠（請求可偽造、繞過），伺服器端驗證才是唯一防線。過度限制字元會降低使用者體驗，應採「白名單驗證」而非「黑名單過濾」。