Cookie、HTTP Header、JSON API 與背景工作

安全提醒：本文為防禦導向的虛構案例與不可部署片段；測試僅限自有或明確授權環境。

只檢查表單會漏掉大量來源。Cookie 可被使用者修改，HTTP Header 可能來自代理或客戶端，JSON 欄位可深層巢狀，訊息佇列與 CSV 也可能承載外部資料。安全審計要沿資料流，而不是沿畫面。

本篇會學到什麼

• 建立完整輸入來源清單
• 辨識代理 Header 與內部訊息的信任假設
• 讓所有 SQL sink 使用一致的安全資料存取層

必備名詞與心智模型

Source 不等於 HTML input。任何能被組織外部、租戶、使用者或上游系統影響的資料都是不可信。即使訊息有簽章，也只證明來源與完整性，不代表內容可當 SQL。

發生情境與生活化比喻

分析系統把 User-Agent、推薦碼 Cookie 與 JSON filter 寫入資料庫，夜間工作再產生統計。生活化比喻是包裹從不同入口進倉庫，但最後都經過同一台機器；每個入口都需要格式規則，機器也必須把內容當資料。

不安全的原始碼

$agent = $_SERVER['HTTP_USER_AGENT'] ?? '';
$campaign = $_COOKIE['campaign'] ?? '';
$body = json_decode(file_get_contents('php://input'), true);
$sql = "INSERT INTO events(agent,campaign,kind) VALUES ('$agent','$campaign','"
     . ($body['kind'] ?? '') . "')";

此片段刻意省略連線、路由與部署設定，只用來辨識資料流，請勿放入任何服務。

逐步看懂資料如何變成查詢

1. Header、Cookie、JSON 是三個獨立外部來源
2. 程式沒有 schema 驗證或長度限制
3. 三個值被拼進同一 INSERT
4. 資料庫解析一整段 SQL
5. 後續報表若再拼接內容，還可能形成 Second-order 風險

修補後原始碼

$kind = is_string($body['kind'] ?? null) ? $body['kind'] : '';
$allowedKinds = ['page_view','search','purchase'];
if (!in_array($kind, $allowedKinds, true)) { /* 回傳 400 */ }
$stmt = $pdo->prepare(
    'INSERT INTO events(agent,campaign,kind) VALUES (:agent,:campaign,:kind)'
);
$stmt->execute([
    'agent'=>mb_substr($agent,0,255),
    'campaign'=>mb_substr($campaign,0,80),
    'kind'=>$kind,
]);

修補的共同原則是先固定 SQL 結構，再把值獨立綁定；無法作為值綁定的識別字只能從程式內允許清單產生。

如何驗證修補

• 缺少、錯型別、巢狀物件與超長 JSON 都有明確處理
• Header 與 Cookie 的引號只作為資料
• 允許的事件 kind 使用嚴格比對
• 背景 consumer 同樣使用參數化，不信任 producer

閱讀提醒：以下分析的目的，是讓你能在自己的程式、測試資料與授權環境中辨識風險。面對正式系統時，先取得明確授權並保存變更紀錄；不要用錯誤訊息或一次回應就推論資料外洩，也不要把文章中的概念改造成自動化探測。安全工作的完成條件，是能說明根因、修補位置、回歸結果與剩餘風險。

更多應用情境、常見誤判與觀察方法

把原理放回真實開發情境

Cookie、Header、JSON、Webhook 與佇列訊息都能由外部影響，需先做 Schema／型別驗證再進資料層。 實作時不要只盯著畫面上的輸入框，還要檢查 API 參數、伺服器端預設值、資料轉換與最後呼叫的資料庫介面。最實用的閱讀方式，是把每一段程式標成「外部來源、轉換、控制、資料庫 sink」，確認資料值沒有在途中重新變回 SQL 結構。

常見誤判

前端隱藏欄位、內網 API 或已簽章訊息不等於內容適合成為 SQL 結構。 安全判斷不能只靠畫面、單次錯誤或某一個防護產品；應同時看原始碼、驅動程式實際執行方式、資料庫權限與回歸測試。若無法證明查詢結構固定，就應把它視為待修的設計風險。

開發與 SOC 可以觀察什麼

為同步與非同步流程保留 trace ID，記錄欄位名稱與驗證結果，不記錄敏感原值。 日誌宜記錄時間、路由、請求關聯 ID、查詢名稱、結果狀態與耗時，敏感值則遮罩或雜湊。偵測規則的用途是縮短發現時間；阻擋之後仍須回到程式碼修補，並搜尋其他共用元件與相同資料流。

審查時的三個追問

1. 這個值最早由誰控制，經過哪些轉換？
2. 它在資料庫呼叫中是資料值，還是欄位、排序、運算式等結構？
3. 若預防失效，最小權限、監控與事件流程能限制並發現多少影響？

開發與維運防禦清單

• 盤點 query string、path、form、JSON、XML、Cookie、Header、檔案與 queue
• 建立共用 repository/query API，減少各處手寫 SQL
• 對代理轉送 Header 設可信代理清單
• 記錄 schema 驗證失敗率，不記完整敏感 payload

重點整理與下一篇

至此已完成常見入口與攻擊類型。下一階段會分別比較 MySQL、SQL Server、PostgreSQL、Oracle 與 SQLite 的語法、驅動與權限差異。

參考資料與更新日期

• OWASP Input Validation
• OWASP SQL Injection Prevention

更新日期：2026-07-20