根據預設，ASP.NET 伺服器會儲存 HttpSessionState 物件，以及在記憶體中它參照的屬性和任何物件。此模型會將作用中的階段作業狀態限制為，僅由單一機器的系統記憶體來提供。為了擴充這些限制的容量，要頻繁的配置伺服器以維持階段作業狀態資訊，如此不僅可擴充容量，還可在多台機器上進行複製以增進整體的效能。為了要維持其階段作業狀態，伺服器必須序列化 HttpSessionState 物件，此作業要求所有儲存在伺服器中的物件皆為可序列化的。

為了使階段作業能夠正確的進行序列化，所有應用程式儲存為階段作業屬性的物件必須聲明 [Serializable] 屬性。此外，如果物件要求自訂的序列化方法，它還必須執行 ISerializable 介面。

範例 1：以下的類別把自己新增至階段作業中，但因為它不可序列化，這個階段作業也就不能正確也序列化。

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

如果多個執行緒嘗試鎖定資源，呼叫 sleep() 的同時還持續鎖定會讓所有其他執行緒等待資源釋放，這會導致效能降低與鎖死。

範例 1：下列程式碼會呼叫 sleep() 並同時持續鎖定。

ReentrantLock rl = new ReentrantLock();
...
rl.lock();
Thread.sleep(500);
...
rl.unlock();

許多聰穎的人花了大量的時間精神，試圖找出如何使用 double-checked locking 來增進效能。但都沒有人成功。

範例 1：乍看之下，它似乎既能避免不必要的同步處理又能保障執行緒的安全。

if (fitz == null) {
  synchronized (this) {
    if (fitz == null) {
      fitz = new Fitzer();
    }
  }
}
return fitz;

程式設計師希望保證只分配一個 Fitzer() 物件，但是又不希望每次呼叫此程式碼時都進行一次同步化。這就是所謂的 double-checked locking。

不幸的是，這並沒有用，且可分配多個 Fitzer() 物件。請參閱 Double-Checked Locking is Broken 聲明以取得更多詳細資訊 [1]。

在執行緒對其他在 mutex 等待的執行緒發出訊號後，它必須在另一個 pthread_mutex_unlock() 函數能開始執行之前，先呼叫此函數來解除 mutex 鎖定。如果發出訊號的執行緒沒能解除 mutex 鎖定，就不會回傳在第二個執行緒呼叫的 pthread_cond_wait()，而且也不會執行該執行緒。

範例 1：以下程式碼藉由呼叫 pthread_cond_signal()，對一個在 mutex 上等待的執行緒發出訊號，但卻無法解除另一個執行緒在等待的 mutex 鎖定。

   ...
   pthread_mutex_lock(&count_mutex);

   // Signal waiting thread
   pthread_cond_signal(&count_threshold_cv);
   ...

應用程式需要非常頻繁地呼叫暫存檔案，許多種不同的機制都是為了在 C 程式庫或 Windows(R) API 中建立暫存檔案而存在的。大多函數很容易受到多種形式的攻擊。
範例 1：以下程式碼使用暫存檔案來儲存處理之前從網路收集的中間資料。

...
if (tmpnam_r(filename)){
	FILE* tmp = fopen(filename,"wb+");
	while((recv(sock,recvbuf,DATA_SIZE, 0) > 0)&&(amt!=0))
		amt = fwrite(recvbuf,1,DATA_SIZE,tmp);
}
...

這程式碼並不容易被注意到，但卻容易受到很多不同的攻擊，因為它建立暫存檔案的方式並不安全。以下各節將詳述由此函數及其它內容所造成的安全弱點。大部分臭名昭著與暫存檔案建立有關的安全問題已在 Unix 作業系統上出現，但是 Windows 應用程式同樣存在著這樣的風險。此章節討論的主題為在 Unix 和 Windows 上建立暫存檔案。

不同系統間使用的方法和運作方式可能是不同的，但是各自造成的基本風險則相差不大。請參閱「建議事項」一節，以瞭解核心安全語言的相關資訊及安全建立暫存檔案的相關建議方法。

設計用來幫助建立暫存檔案的函數可依據其是否是提供檔案名稱或實際開啟新檔，而分成兩個部分。

群組 1 -「唯一的」檔案名稱：

第一組 C 程式庫和 WinAPI 函數是用來幫助建立暫存檔案，其透過產生唯一的檔案名稱來建立要被某程式打開的新暫存檔案。這部分包含了如 tmpnam()、tempnam()、mktemp() 這樣的 C 程式庫函數以及與其等價的以 _ (下劃線) 開頭的 C++ 文件和 Windows API 中的 GetTempFileName() 函數。這組函數在檔案名稱選擇方面很可能會有 Race Condition 的麻煩。雖然函數保證在選取檔案時，其檔案名稱是唯一的，但是沒有機制能防止其他處理或攻擊者在選取檔案後和應用程式試圖開啟檔案之前的這段時間內，建立一個相同檔案名稱。相比一個由其他程式呼叫相同函數所引發的合法衝突，攻擊者非常有可能建立一個惡意的衝突，因為由這些函數建立的檔案名稱沒有充分的隨機化來使猜測更加困難。

如果建立了特定名稱的檔案，那麼根據這個檔案的開啟方式，現有內容或存取權限都可能保持不變。如果現有檔案內容實質上是惡意的，攻擊者就可以在應用程式從暫存檔案讀取資料時向程式注入危險資料。如果攻擊者預先建立了一個能輕鬆獲取存取權限的檔案，那麼被應用程式儲存在暫存檔案裏的資料將被存取、修改或毀壞。在 Unix 系統上，如果攻擊者預先定義了一個檔案作為另一個重要檔案的連接，那麼更狡猾的攻擊也可能存在。那麼，如果應用程式從檔案截取資料或將資料寫入檔案，它將不知不覺地為攻擊者執行惡意操作。如果程式是以提升過的權限執行，那將是極其嚴重的威脅。

最後，最好的情況就是呼叫 open() 函數並使用 O_CREAT 和 O_EXCL 旗標，或者呼叫 CreateFile() 函數並使用 CREATE_NEW 屬性來開啟檔案。如此一來，如果檔案已經存在，那麼檔案建立就會失敗，也可以防範以上所描述的攻擊類型。然而，如果攻擊者可以準確預測一個檔案序列的檔案名稱，那麼應用程式將被強制禁止開啟所需的臨時儲存空間，進而引發 Denial of Service (DoS) 攻擊。如果使用由這些函數產生的一小部分亂數來選擇檔案名稱，那麼這種類型的攻擊將不難實現。

群組 2 -「唯一的」檔案：

C 程式庫函數的第二部分是藉由產生唯一的檔案名稱且開啟該檔案，來解決一些與暫存檔案有關的安全問題。這部分包含了像 tmpfile() 這樣的 C 函數和與之對應的以 _ (下劃線) 開頭的 C++ 函數，以及表現更為出色的 C 程式庫函數 mkstemp()。

類似 tmpfile() 的函數構成唯一的檔案名稱，並藉由與傳遞 "wb+" 標記時 fopen() 使用的相同方法開啟檔案，就像讀/寫模式下的二位元檔一樣。如果檔案已存在，tmpfile() 將把檔案大小縮小為 0，藉此緩和前面提到的有關存在於唯一檔案名稱選擇與隨之打開選取檔案之間的 Race Condition 的安全問題。然而，這個運作方式顯然不能解決函數的安全性問題。首先，攻擊者可能使用可能由 tmpfile().開啟的檔案所保存的寬鬆存取權限來預先建立檔案。其次，在 Unix 系統上，如果攻擊者預先建立了一個檔案作為其他重要檔案的一個連接，應用程式可能會使用其被提升的權限去縮小該檔案，這樣就能按照攻擊的意願執行破壞。最後，如果 tmpfile() 建立了一個新檔案，那麼套用在此檔案上的存取權限在不同的作業系統間是不同的；如此一來，應用程式就極易受到攻擊，而攻擊者甚至不需要預先猜測到將被使用的檔案名稱也可進行攻擊。

最後，mkstemp() 函數是建立暫存檔案的安全方式。它將以一個使用者結合一組隨機生成的字元提供的檔案名稱範本的方式，來建立並開啟唯一的檔案。如果它不能建立此檔案，它將回傳 -1 表示失敗。在先進的系統上，是使用模式0600 來開啟檔案，這就意味著這個檔案將免受干擾，除非使用者改變其存取權限。然而，mkstemp() 仍然會受到使用能夠預先推測的檔案名稱的威脅，而且如果攻擊是藉由猜測或預先建立將要使用的檔案名稱的檔案導致 mkstemp() 函數失效的話，將使應用程式極易受到 Denial of Service 攻擊。

開啟階段作業時間愈久，攻擊者威脅使用者帳戶的機率就愈大。階段作業仍為作用中時，攻擊者可能會暴力破解使用者密碼、破解使用者的無線加密金鑰，或是從開啟的瀏覽器控制階段作業。如果足夠大量的階段作業正在執行，較長的階段作業逾時時間也會導致無法釋放記憶體，最後造成阻斷服務。

範例 1：以下範例中的程式碼為未活動時間間隔上限設定了負值，導致階段作業無限期地處於作用中狀態。

...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...

讓 Web 應用程式嘗試關閉自身的容器是不對的。呼叫終結方法可能是殘餘除錯程式碼的一部分，或是從非 J2EE 應用程式所匯入程式碼的一部分。

為了提高應用程式的可靠性和性能，一個 J2EE 應用程式能利用多個 JVM。為使終端使用者把多個 JVM 看作單個應用程式，J2EE 容器可以在多個 JVM 之間複製 HttpSession 物件，所以當一個 JVM 不可用時，另一個 JVM 可以在不中斷應用程式流程的情況下接替它。

為了使階段作業複製能夠正常運作，應用程式在階段作業中儲存為屬性的值必須執行 Serializable 介面。

範例 1：下面的這個類別會把自己增加至階段作業中，但由於物件是不可序列化的，因此不能複製此階段作業。

public class DataGlob {
   String globName;
   String globValue;

   public void addToSession(HttpSession session) {
     session.setAttribute("glob", this);
   }
}

在某些情況下，J2EE 標準會禁止在 Web 應用程式中進行執行緒管理，且執行緒管理非常容易發生錯誤。管理執行緒非常困難，並且可能會以無法預測的方式干擾應用程式容器的運作。即使容器沒有受到干擾，執行緒管理通常還是會發生錯誤，例如無法偵測並診斷鎖死 (deadlock)、Race Condition 及其他同步錯誤。

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

在程式碼中很容易發現的兩個可疑假設為：「此方法呼叫永遠都不會失敗」以及「即使此呼叫失敗也沒有關係」。因此當程式設計師忽略情況時，已暗示他們是以其中一個假設來執行操作。

範例 1： 以下所引用的程式碼忽略可能在 CICS 交易時發生的錯誤情況。

...
EXEC CICS
  INGNORE CONDITION ERROR
END-EXEC.
...

如果在此錯誤情況下交易失敗，程式會當作沒有發生任何異常的情況下繼續執行。程式不會記錄有關此特殊情況，這將使得事後嘗試尋找程式此異常的運作方式變得很困難。

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

在程式碼中很容易發現的兩個可疑假設為：「此方法呼叫永遠都不會失敗」以及「即使此呼叫失敗也沒有關係」。因此當程式設計師忽略異常時，已暗示他們是以其中一個假設來執行操作。

範例 1：以下所引用的程式碼忽略了由 doExchange() 拋出的罕見異常。

try {
  doExchange();
}
catch (RareException e) {
  // this can never happen
}

如果拋出了 RareException，程式會繼續執行，就像什麼都沒有發生過一樣。程式不會記錄有關此特殊情況，這將使得事後嘗試尋找程式此異常的運作方式變得很困難。

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

在程式碼中很容易發現的兩個可疑假設為：「此函數呼叫永遠都不會失敗」以及「即使此呼叫失敗也沒有關係」。因此當程式設計師忽略異常時，已暗示他們是以其中一個假設來執行操作。

範例 1：下列程式碼會忽略執行插入指令時所丟出的數個異常。

PROCEDURE do_it_all
IS
BEGIN
  BEGIN
    INSERT INTO table1 VALUES(...);
    COMMIT;
  EXCEPTION
    WHEN OTHERS THEN NULL;
  END;
END do_it_all;

因為表格不存在、未提供必要值或某些其他原因，就可能會丟出異常。如果發生錯誤，將無法得知訊息，因為程序不會報告該錯誤或記錄發生的錯誤類型。

多重 catch 區塊看上去可能比較繁瑣，但藉由捕捉高層級的類別 (比如 Exception)「濃縮」catch 區塊，可能會混淆那些需要特殊處理的異常，或是捕捉了不應該在程式中某階段捕捉的異常。捕捉範圍過大的異常，實質上是與「Java 分類定義異常」目的相違背的，並且隨著程式的增長且開始拋出新類型的異常時，此做法將導致嚴重的危險。因為，新的異常類型將不會被注意到。

範例 1：以下引用的程式碼使用相同的方式處理三種不同的異常類型。

  try {
    doExchange();
  }
  catch (IOException e) {
    logger.error("doExchange failed", e);
  }
  catch (InvocationTargetException e) {
    logger.error("doExchange failed", e);
  }
  catch (SQLException e) {
    logger.error("doExchange failed", e);
  }

其實，似乎使用單一 catch 區塊來處理這些異常會比較好一點，如下所示：

  try {
    doExchange();
  }
  catch (Exception e) {
    logger.error("doExchange failed", e);
  }

但是，如果修改 doExchange() 後而拋出新的異常類型，而此異常需以不同方式來處理，那麼過大範圍的 catch 區塊將會阻止編譯器指出這個情況 (有新的異常拋出)。此外，新的 catch 區塊也可處理從 RuntimeException 衍生的異常，例如 ClassCastException 和 NullPointerException，而處理這些異常並不在程式設計師的意圖之內。

聲明一個可拋出 Exception 或是 Throwable 異常的方法，會使呼叫者很難處理和修復發生的錯誤。Java 的異常機制被設定為：呼叫者可以很容易的預計到方法有可能會發生什麼錯誤，並且編寫程式碼以處理各個特定的異常情況。同時聲明：一個方法拋出一個過於籠統的異常違反該系統。

範例 1：下列方法拋出三種類型的異常。

public void doExchange()
  throws IOException, InvocationTargetException,
         SQLException {
  ...
}

這樣看起來比較整齊

public void doExchange()
  throws Exception {
  ...
}

這樣做會防礙呼叫者理解和處理所發生異常。此外，如果 doExchange() 方法因為變更了程式碼，而引入一個需要不同處理方式的異常，則不能用簡單的方式來處理該要求。

通常在以下三個情況，程式設計師會擷取 NullPointerException：

1.程式包含了 Null 指標解除參照。擷取異常狀況的結果比修復基本問題還要簡單。

2. 程式明確的拋出了 NullPointerException 異常狀況來提醒出現錯誤情況。

3. 程式碼是測試代碼的一部分，它在測試的類別中提供了非預期的輸入。

在上述三種情況中，只有最後一種是可接受的。

範例 1：以下程式碼錯誤地擷取了 NullPointerException。

  try {
    mysteryMethod();
  }
  catch (NullPointerException npe) {
  }

通常在以下三個情況，程式設計師會擷取 NullReferenceException：

1.程式包含了 Null 指標解除參照。擷取異常狀況的結果比修復基本問題還要簡單。

2. 程式明確的拋出了 NullReferenceException 異常狀況來提醒出現錯誤情況。

3. 程式碼是測試代碼的一部分，它在測試的類別中提供了非預期的輸入。

在上述三種情況中，只有最後一種是可接受的。

範例 1：以下程式碼錯誤地擷取了 NullReferenceException。

  try {
    MysteryMethod();
  }
  catch (NullReferenceException npe) {
  }

finally 區塊中的回傳指令，會導致 try 區塊中所拋出的任意異常遭丟棄。

範例 1：在下列程式碼中，由第二次呼叫 doMagic 方法，同時將 true 參數傳送給該方法，會導致拋出 MagicException 異常，該異常將不會傳送給呼叫者。finally 區塊中的回傳指令，會導致異常遭丟棄。

public class MagicTrick {

public static class MagicException extends Exception { }

public static void main(String[] args) {

  System.out.println("Watch as this magical code makes an " +
                     "exception disappear before your very eyes!");

  System.out.println("First, the kind of exception handling " +
                     "you're used to:");
  try {
    doMagic(false);
  } catch (MagicException e) {
    // An exception will be caught here
    e.printStackTrace();
  }

  System.out.println("Now, the magic:");
  try {
    doMagic(true);
  } catch (MagicException e) {
    // No exception caught here, the finally block ate it
    e.printStackTrace();
  }
  System.out.println("tada!");
}

public static void doMagic(boolean returnFromFinally)
throws MagicException {

  try {
    throw new MagicException();
  }
  finally {
    if (returnFromFinally) {
      return;
    }
  }
}

}

只有在應用程式在非同步結束後需要進行清除動作，才會出現 ThreadDeath 錯誤。如果出現 ThreadDeath 錯誤，請務必重新拋出該錯誤來真正停止執行緒。拋出 ThreadDeath 的用意為停止執行緒。如果接收 ThreadDeath，就會導致執行緒持續執行並造成意外行為，因為原來拋出 ThreadDeath 的使用者想停止該執行緒。

範例 1：下列程式碼捕捉到 ThreadDeath，但並未重新拋出。

try
{
//some code
}
catch(ThreadDeath td)
{
//clean up code
}

在 Java 中，finally 區塊永遠會在對應 try-catch 區塊後執行，而且通常用來釋放已配置資源，例如檔案控制碼或資料庫指標。在 finally 區塊中拋出異常，可以略過重要的清除程式碼，這是因為將中斷正常程式執行。

範例 1：在下列程式碼中，拋出 FileNotFoundException 時，會略過呼叫 stmt.close()。

public void processTransaction(Connection conn) throws FileNotFoundException
{
    FileInputStream fis = null;
    Statement stmt = null;
    try
    {
        stmt = conn.createStatement();
        fis = new FileInputStream("badFile.txt");
        ...
    }
    catch (FileNotFoundException fe)
    {
        log("File not found.");
    }
    catch (SQLException se)
    {
        //handle error
    }
    finally
    {
        if (fis == null)
        {
            throw new FileNotFoundException();
        }

        if (stmt != null)
        {
            try
            {
                stmt.close();
            }
            catch (SQLException e)
            {
                log(e);
            }
        }
    }
}

在以下情況中會出現 Unhandled Exception 弱點：

1. 拋出一個異常

2. 在異常離開目前頁面前，未能對其進行適當處理。

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

在程式碼中很容易發現的兩個可疑假設為：「此操作永遠都不會失敗」以及「即使此操作失敗也沒有關係」。因此當程式設計師未擷取到操作可能拋出的異常時，已暗示他們是以其中一個假設來執行操作。