Oracle 與 SQLite 的規模、部署方式和 SQL dialect 差異極大，卻都可能因應用程式拼接查詢而出現 SQL Injection。『企業資料庫有安全功能』與『SQLite 沒有網路埠』都不是免疫證明。
本篇會學到什麼
- 理解 Oracle bind variable 與動態 PL/SQL
- 理解 SQLite prepare/bind/step 生命週期
- 回答哪些資料庫不會被 SQL Injection 的常見問題
必備名詞與心智模型
Oracle bind variable 使用 :name，能代表資料但不能替代 DDL 或任意 query text；動態 SQL 仍需 bind、驗證與明確格式模型。SQLite 會把所有 SQL 編譯成 prepared statement，再以 sqlite3_bind_* 綁值；若應用程式先拼接文字，嵌入式架構也阻止不了語法被改寫。
發生情境與生活化比喻
Oracle 後台依日期產生財務報表，SQLite 桌面程式依標籤搜尋本機筆記。前者可能在 PL/SQL EXECUTE IMMEDIATE 拼接，後者可能在 C/Python/PHP 中拼接；兩者的 source-to-sink 分析方式相同。
不安全的原始碼
-- Oracle 閱讀片段
statement := 'SELECT id,total FROM invoices WHERE label=''' || p_label || '''';
EXECUTE IMMEDIATE statement;
// SQLite 閱讀片段
$sql = "SELECT id,title FROM notes WHERE tag='" . $tag . "'";此片段刻意省略連線、路由與部署設定，只用來辨識資料流，請勿放入任何服務。
逐步看懂資料如何變成查詢
- Oracle p_label 或 SQLite tag 來自外部資料
- 程式在資料庫解析前完成字串拼接
- Oracle 動態 SQL 或 SQLite parser 接收完整命令文字
- 資料庫品牌與是否有網路服務不改變根因
- 各自的角色/檔案權限決定後果範圍
修補後原始碼
-- Oracle：固定 statement，以 bind variable 傳值
EXECUTE IMMEDIATE
'SELECT id,total FROM invoices WHERE label=:label'
BULK COLLECT INTO rows USING p_label;
// SQLite/PDO：固定模板並綁定值
$stmt = $pdo->prepare('SELECT id,title FROM notes WHERE tag=:tag');
$stmt->execute(['tag'=>$tag]);修補的共同原則是先固定 SQL 結構，再把值獨立綁定；無法作為值綁定的識別字只能從程式內允許清單產生。
如何驗證修補
- Oracle 動態 SQL 搜尋字串串接與 NLS-dependent conversion
- DDL 或識別字需求使用嚴格允許清單/DBMS_ASSERT 等適當 API
- SQLite 應用檔案權限限制非預期讀寫
- 合法引號與 Unicode 在兩種驅動都保持資料語意
- 文件明確寫出版本、驅動與 placeholder 差異
閱讀提醒：以下分析的目的，是讓你能在自己的程式、測試資料與授權環境中辨識風險。面對正式系統時，先取得明確授權並保存變更紀錄；不要用錯誤訊息或一次回應就推論資料外洩，也不要把文章中的概念改造成自動化探測。安全工作的完成條件，是能說明根因、修補位置、回歸結果與剩餘風險。
更多應用情境、常見誤判與觀察方法
把原理放回真實開發情境
Oracle 的 bind variable 與 SQLite 的 prepare/bind/step 名稱不同，但核心都是固定結構、分離資料值。 實作時不要只盯著畫面上的輸入框，還要檢查 API 參數、伺服器端預設值、資料轉換與最後呼叫的資料庫介面。最實用的閱讀方式，是把每一段程式標成「外部來源、轉換、控制、資料庫 sink」，確認資料值沒有在途中重新變回 SQL 結構。
常見誤判
沒有網路服務的 SQLite 仍會受應用輸入影響；Oracle 功能完整也不代表應用查詢天然安全。 安全判斷不能只靠畫面、單次錯誤或某一個防護產品；應同時看原始碼、驅動程式實際執行方式、資料庫權限與回歸測試。若無法證明查詢結構固定，就應把它視為待修的設計風險。
開發與 SOC 可以觀察什麼
依引擎調整權限：Oracle 限制 schema 權限；SQLite 限制檔案、程序與備份存取。 日誌宜記錄時間、路由、請求關聯 ID、查詢名稱、結果狀態與耗時，敏感值則遮罩或雜湊。偵測規則的用途是縮短發現時間；阻擋之後仍須回到程式碼修補，並搜尋其他共用元件與相同資料流。
審查時的三個追問
- 這個值最早由誰控制，經過哪些轉換？
- 它在資料庫呼叫中是資料值，還是欄位、排序、運算式等結構？
- 若預防失效，最小權限、監控與事件流程能限制並發現多少影響？
開發與維運防禦清單
- Oracle 使用 bind variable、明確格式與最小 role
- SQLite 使用 prepare/bind/step，不以單機部署為安全理由
- 永遠不回答某主流資料庫『不會被注入』
- 同時保護備份、資料庫檔、trace 與 audit log 中的敏感值
重點整理與下一篇
各資料庫都有參數 API，但 PDO、prepared statement 與 ORM 仍可能被誤用。下一篇整理 raw query、動態欄位與錯誤抽象層。
參考資料與更新日期
更新日期：2026-07-20
