JDBC 安全性機制深度解析：Applet 沙箱、驅動程式責任與權限檢查

JDBC 安全模型核心原則

JDBC 必須遵循 Java 安全規範，針對未驗證的 Applet 嚴格限制資料庫存取權限，防止惡意程式碼竊取或破壞資料。

5.1 JDBC 與未驗證 Applet

• 未驗證 Applet 被視為不可信
• 禁止存取本地資料庫
• 已向 DriverManager 註冊的驅動，僅能存取其來源對應的資料源
• Applet 僅能連回其下載來源伺服器的資料庫
• 若驅動層確信連線無認證/權限風險，才允許 Applet 開啟連線

資料庫伺服器通常透過 IP 限制存取，此限制與一般 Applet 沙箱一致，無需放寬。

5.2 JDBC 與 Java 應用程式

本地 Java 應用 (Trusted Code) 從 classpath 載入驅動，擁有完整檔案/網路存取權，同一般桌面程式。

若未驗證的 sun.sql.Driver 從遠端載入，則受限於同源原則，只能與同源程式碼配合運作。

5.3 驅動程式開發者的安全責任

驅動一旦安裝於本地端，即成為受信任程式碼一部分，必須防禦惡意 Applet 濫用。所有檢查發生在 連線建立瞬間，連線成功後不再重複檢查。

5.3.1 共享 TCP 連線時的權限檢查

若驅動在多連線間共享單一 TCP 連線，必須自行檢查每個呼叫者權限：

SecurityManager security = System.getSecurityManager();
if (security != null) {
    security.checkConnect(hostName, portNumber); // 拋出 SecurityException 表示拒絕
}

例：Applet A 開啟連至 foobah 的 TCP，不代表 Applet B 可共用此連線。

5.3.2 本地檔案存取檢查

SecurityManager security = System.getSecurityManager();
if (security != null) {
    security.checkRead(fileName); // 檢查讀取權限
    // security.checkWrite(fileName); // 檢查寫入權限
}

5.3.3 最壞情況防禦：JDBC-ODBC Bridge 範例

使用本地方法 (Native) 橋接時，難以追蹤底層將存取哪些檔案。驅動必須採「預設拒絕」策略：

• 檢查 ODBC 資料源名稱是否包含主機資訊，若無法判斷則拒絕
• 透過 security.checkWrite("foobaz") 判斷呼叫者是否為可信應用 (可寫任意檔 = Trusted)，否則視為 Applet 予以封鎖

此機制確保即使驅動被安裝在本地，惡意 Applet 也無法繞過沙箱直接存取資料庫。