Fortify Audit Workbench 筆記 Unreleased Resource: Database（ 未釋放資源：數據庫）

Unreleased Resource: Database 未釋放資源：數據庫

Abstract

程序可能無法成功釋放某一項系統資源。

Explanation

程序可能無法成功釋放某一項系統資源。 資源泄露至少有兩種常見的原因：
－ 錯誤狀況及其他異常情況。
－ 未明確程序的哪一部份負責釋放資源。
大部分 Unreleased Resource 問題只會導致一般的軟件可靠性問題， 但如果攻擊者能夠故意觸發資源泄漏，該攻擊者就有可能通過耗盡資源池的方式發起 denial of service 攻
擊。
例 1： 下面的方法絕不會關閉它所打開的文件句柄。 FileInputStream 中的 finalize() 方法最終會調用 close()，但無法保證它調用 finalize() 方法的時間。 在繁忙的環境中，這會導致 JVM 用盡它所有的文件句柄。

private void processFile(String fName) throws FileNotFoundException,
IOException
{
FileInputStream fis = new FileInputStream(fName);
int sz;
byte[] byteArray = new byte[BLOCK_SIZE];
while ((sz = fis.read(byteArray)) != -1) {
processBytes(byteArray, sz);
}
}

例 2： 在正常條件下，以下代碼會執行數據庫查詢指令，處理數據庫返回的結果，並關閉已分配的指令對象。 但如果在執行 SQL 或是處理結果時發生異常，指令對象將不會關閉。 如果這種情況頻繁出現，數據庫將用完所有可用的指針，且不能再執行任何 SQL 查詢。

Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(CXN_SQL);
harvestResults(rs);
stmt.close();

Recommendation

1.絕不要依賴 finalize() 回收資源。 為了使對象的 Finalize() 方法能被調用，垃圾收集器必須確認對象符合垃圾回收的條件。 但是垃圾收集器只有在 JVM 內存過小時才會使用。因此，無法保證何時能夠調用該對象的 finalize() 方法。 垃圾收集器最終運行時，可能出現這樣的情況，即在短時間內回收大量的資源，這種情況會導致“突發”性能，並降低總體系統通過量。 隨着系統負載的增加，這種影響會越來越明顯。 最后， 如果某一資源回收操作被掛起（例如該操作需要通過網絡訪問數據庫），那么執行 finalize() 方法的線程也將被掛起。 2. 在 finally 代碼段中釋放資源。 例 2 中的代碼可按以下方式改寫：

public void execCxnSql(Connection conn) {
    Statement stmt;
    try {
        stmt = conn.createStatement();
        ResultSet rs = stmt.executeQuery(CXN_SQL);
        ...
    }
    finally {
        if (stmt != null) {
            safeClose(stmt);
        }
    }
}
public static void safeClose(Statement stmt) {
    if (stmt != null) {
        try {
            stmt.close();
        } catch (SQLException e) {
            log(e);
        }
    }
}

以上方案使用了一個助手函數，用以記錄在嘗試關閉指令時可能產生的異常。 該助手函數大約會在需要關閉指令時重新使用。 同樣， execCxnSql 方法不會將 stmt 對象預置為空。 而是進行檢查，以確保調用safeClose() 之前， stmt 不是 null。 如果沒有檢查 null， Java 編譯器會報告 stmt 可能沒有進行初始化。 編譯器做出這一判斷源於 Java 可以檢測未初始化的變量。 如果用一種更加復雜的方法將 stmt 初始化為 null，那么 Java 編譯器就無法檢測 stmt 是否已被初始化。