JDBC 安全機制深度剖析：Applet 沙箱、驅動責任與連線防護（三）

安全考量的兩大核心情境

• Java Application：本地程式碼，受信任
• 未驗證 Applet：嚴格禁止存取本地與任意網路資料庫

5.1 JDBC 與未驗證 Applet 的嚴格契約

• 遵循 Java 通用安全規則
• 視未驗證 Applet 為不可信
• 禁止不可信 Applet 存取本地資料庫
• 向 DriverManager 註冊的驅動，僅能存取其來源資料源
• Applet 僅能存取其下載來源伺服器的資料
• 驅動層確信無認證/權限風險時，始允許 Applet 開啟連線

資料庫伺服器鮮少透過 IP 限制存取，這些限制雖繁瑣，但與 Applet 通用限制一致，無需放寬。

5.2 JDBC 與 Java 應用程式

從本地類路徑載入驅動，允許自由存取檔案、遠端伺服器。若未驗證的 sun.sql.Driver 從遠端載入，則受同源策略限制，僅能與同源程式碼配合。

5.3 驅動開發者的安全責任（關鍵）

驅動安裝於本地後成為受信環境一部分，必須防範惡意 Applet 濫用。所有原則在連線開啟瞬間執行檢查，連線建立後不再重複檢查。

5.3.1 共享 TCP/IP 連線時的謹慎檢查

單一連線開啟由 Java 安全管理器自動檢查調用堆疊中的 Applet 權限。但跨多資料庫連線共享 TCP 連線時，驅動必須自行檢查每個調用者權限：

SecurityManager security = System.getSecurityManager();
if (security != null) {
    security.checkConnect(hostName, portNumber);
}

不允許時拋出 SecurityException。範例：Applet A 開啟 foobah 連線，不代表 Applet B 可自動共用。

5.3.2 本地檔案存取檢查

驅動需確信調用者有權開啟檔案：

security.checkRead(fileName);

5.3.3 最壞情況防禦：本地方法橋接

使用本地方法（如 JDBC-ODBC Bridge）時，難以判斷底層函數將存取哪些本地檔案。必須假設最壞情況，拒絕所有下載 Applet 的資料庫存取，除非驅動完全確信安全。
Bridge 必須檢查 ODBC 資料源名稱，確保 Applet 僅存取其「生源地」；無法判斷主機名時直接拒絕。

判斷調用者為可信應用或 Applet：

security.checkWrite("foobaz"); // 能寫任意檔案即為可信應用

總結

JDBC 安全模型核心在於連線建立瞬間的上下文敏感檢查，驅動開發者承擔關鍵防禦責任，特別是連線共享與本地橋接場景。這套機制與 Java 沙箱模型深度融合，確保企業資料資產在開放網路環境下的安全邊界。