根據預設，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 中建立暫存檔案而存在的。大多函數很容易受到多種形式的攻擊。
範例：以下程式碼會在對從網路收集的直接資料進行處理之前，使用暫存檔案進行儲存。

...
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 及其他同步錯誤。

與 block.timestamp 或 block.number 相關的值通常由開發人員用來觸發與時間相關的事件，但是，這些值通常給人一種用起來通常不安全的時間感。

由於區塊鏈的去中心化性質，節點只能在一定程度上同步時間。使用 block.timestamp 充其量是不可靠的，在最壞的情況下，惡意挖礦者可以更改其區塊的時間，只要他們認為這樣做有好處。

至於 block.number，即使可以預測區塊之間的時間 (大約14秒)，區塊時間也不是恆定的，並且可能會根據網路活動而異。如此一來，對於與時間相關的計算來說，block.number 並不可靠。

範例 1：以下程式碼使用 block.number，在一定時間過後才會解鎖資金。

function withdraw() public {
    require(users[msg.sender].amount > 0, 'no amount locked');
    require(block.number >= users[msg.sender].unlockBlock, 'lock period not over');
    uint amount = users[msg.sender].amount;
    users[msg.sender].amount = 0;
    (bool success, ) = msg.sender.call.value(amount)("");
    require(success, 'transfer failed');
}

Node.js 可讓開發人員將回撥指派給 IO 封鎖的事件。這能夠帶來更好的效能，因為回撥會異步執行，以便主應用程式不會遭到 IO 的封鎖。但是，當回撥以外的內容仰賴回撥內的程式碼才能首先執行時，這可能會反過來造成競爭情形。

範例 1：以下程式碼會對照用於驗證的資料庫來檢查使用者。

 
...
var authenticated = true; 
...
database_connect.query('SELECT * FROM users WHERE name == ? AND password = ? LIMIT 1', userNameFromUser, passwordFromUser, function(err, results){
  if (!err && results.length > 0){
    authenticated = true;
  }else{
    authenticated = false;
  }
});

if (authenticated){
  //do something privileged stuff
  authenticatedActions();
}else{
  sendUnathenticatedMessage();
}

在此範例中，我們將會呼叫後端資料庫來確認使用者的登入憑證，且如果確認，我們會將變數設為 true，否則會設為 false。很遺憾，由於回撥遭到 IO 封鎖，因此將會異步執行, 並可能在對 if (authenticated) 進行檢查後執行，而由於預設值為 true，因此無論使用者是否確實得到驗證，回撥都將進入 if 陳述式。

應用程式會從共用儲存區安裝應用程式，任何具有外部儲存區讀取/寫入權限的應用程式都可以寫入該儲存區。 由於競爭情形，監控資料夾的惡意應用程式可針對替代 APK 檔案交換已下載的 APK 檔案，其中將使用安裝程序而非合法更新。

範例 1： 下列程式碼會從共用儲存區安裝應用程式：

    Intent intent = new Intent(Intent.ACTION_VIEW);
    intent.setDataAndType(Uri.fromFile(new File(Environment.getExternalStorageDirectory() + "/download/" + "app.apk")), "application/vnd.android.package-archive");
    intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    startActivity(intent);

File access race condition (也稱為 time-of-check)、time-of-use (TOCTOU) race conditions，在以下情況中出現：

1. 程式檢查檔案特性時，根據名稱來參照檔案。

2.程式稍後會使用相同的檔案名稱執行檔案系統作業，並假設先前檢查的屬性並未變更。
範例 1：以下程式碼來自一個安裝了 setuid root 的程式。程式代表無權限使用者執行了特定的檔案操作，並使用存取檢查來確保它不使用其根權限執行目前使用者不應該執行的操作。程式使用 access() 系統呼叫來檢查在程式開啟檔案和執行必要操作之前，執行程式的使用者是否具有權限去存取這些指定的檔案。

  if (!access(file,W_OK)) {
    f = fopen(file,"w+");
    operate(f);
    ...
  }
  else {
    fprintf(stderr,"Unable to open file %s.\n",file);
  }

access() 呼叫的運作方式在意料之中，而且，如果執行程式的使用者具有必要的權限來編輯檔案，那麼就會回傳 0，其他情況則會回傳-1。無論怎樣，因為 access() 和 fopen() 都是對檔案名稱進行操作，而不是對檔案控制碼進行操作，所以當 file 變數傳送到 fopen() 的時候，就不能保證這個變數仍然能夠像傳送到 access() 的時候那樣參照磁碟上相同的檔案。如果攻擊者在 access() 呼叫之後，用指向不同檔案的一個象徵連結來取代 file，程式就會使用它的根權限對檔進行操作，即使這個檔案攻擊者在其他情況下是無法篡改的。藉由欺騙程式去執行其他情況下不被允許的操作，攻擊者就能取得權限的提高。

這種形式的弱點具有 root 權限，因而沒有受到程式的限制。如果應用程式有能力執行攻擊者在其他情況下不被允許的任何操作，那麼這個程式就是一個可能的攻擊目標。

導致這種攻擊的弱點的間隙是在這段時間內，檔案特性經過測試到檔案被使用為止。即使檔案的使用緊接在測試之後，現代的作業系統也無法確認在程式佔用 CPU 前所執行的程式碼數量。攻擊者有多種技術來延長機會時間的長度，以便更容易地發動攻擊。然而，即使機會時間很短，攻擊企圖也可能一而再地重複，直到成功。

範例 2：以下程式碼會建立檔案，然後變更該檔案的所有者。

    fd = creat(FILE, 0644);  /* Create file */
    if (fd == -1)
        return;
    if (chown(FILE, UID, -1) < 0) {  /* Change file owner */
      ...
    }

此程式碼假設對 chown() 呼叫所操作的檔案與對 creat() 的呼叫所建立的檔案相同，但實際上未必如此。由於 chown() 是針對檔案名稱 (而非檔案控制碼) 進行操作，因此攻擊者可能會使用並非由攻擊者所擁有的檔案連結來取代檔案。隨後，對 chown() 的呼叫會為攻擊者提供所連結檔案的擁有權。

java.text.Format 中的 parse() 和 format() 方法有 race condition，可能導致使用者看見其他使用者的資料。

範例 1：以下程式碼顯示此設計上的缺陷。

public class Common {

    private static SimpleDateFormat dateFormat;
    ...

    public String format(Date date) {
        return dateFormat.format(date);
    }
    ...

    final OtherClass dateFormatAccess=new OtherClass();
    ...

    public void function_running_in_thread1(){
        System.out.println("Time in thread 1 should be 12/31/69 4:00 PM, found: "+ dateFormatAccess.format(new Date(0)));
    }

    public void function_running_in_thread2(){
        System.out.println("Time in thread 2 should be around 12/29/09 6:26 AM, found: "+ dateFormatAccess.format(new Date(System.currentTimeMillis())));
    }
}

此程式碼在單一使用者的環境下可正常執行，但兩個執行緒同時執行程式碼時，便會產生下列輸出：

Time in thread 1 should be 12/31/69 4:00 PM, found: 12/31/69 4:00 PM
Time in thread 2 should be around 12/29/09 6:26 AM, found: 12/31/69 4:00 PM

在此案例中，因為執行 format() 時發生 race condition，第一個執行緒的日期會在第二個執行緒的輸出中顯示。

RoamingFolder 和 RoamingSettings 屬性會取得漫遊應用程式資料存放區中的容器，該容器可用於在兩部或多部裝置之間共用資料。透過寫入及讀取儲存在漫遊應用程式資料存放區中的物件，開發人員會增加遭受危害的風險。這包括透過漫遊應用程式資料存放區來共用這些物件的資料、應用程式和系統的保密性、完整性與可用性。

開發人員應先實作必要技術控制措施之後才能使用該功能。

每當不可重入函數被安裝為訊號處理常式時，就會出現訊號處理常式的 Race Condition，表示它保留了一些內部狀態，或呼叫其他也同樣如此的函數。這種 Race Condition 在安裝相同函數去處理多重訊號時，會更有可能發生。

訊號處理的 Race Condition 很有可能會在以下情況中出現：

1. 程式安裝單一訊號處理常式來處理多個訊號。

2. 兩個被安裝處理常式的不同訊息在短時間內連續收到，導致訊號處理常式的 Race Condition。

範例：以下程式碼為兩個不同的訊號安裝了一個相同且不可重入的信號處理常式。如果攻擊者使訊號在正確時間內發送出去，訊號處理常式會承受 Double Free 弱點威脅。以相同值呼叫 free() 兩次，會導致 Buffer overflow。當程式使用相同引數呼叫 free() 兩次，就會毀損程式中的記憶體管理資料結構。這樣的毀損會使程式當機，或者在某些情況下，還會導致之後兩次的 malloc() 呼叫回傳相同的指標。如果 malloc() 兩次回傳值都相同，且程式之後讓攻擊者控制整個已經寫入雙倍分配記憶體的資料，此程式就變得容易受到 Buffer overflow 攻擊。

void sh(int dummy) {
  ...
  free(global2);
  free(global1);
  ...
}

int main(int argc,char* argv[]) {
  ...
  signal(SIGHUP,sh);
  signal(SIGTERM,sh);
  ...
}

許多 Servlet 開發人員並不了解 Servlet 都是單一個體。Servlet 只能有一個實例，而且當不同執行緒同時處理多個要求時，都會使用及重複使用該單一實例來處理這些要求。

這種誤解的結果為：由於開發人員使用 Servlet 成員欄位，所以使用者可能會看到其他使用者的資料。換句話說，將使用者資料儲存在 Servlet 成員欄位中會造成資料存取的 race condition。

範例 1：下面的 Servlet 將要求參數的值儲存在成員欄位中，並且接著會將該參數值回傳到回應輸出串流。

public class GuestBook extends HttpServlet {

   String name;

   protected void doPost (HttpServletRequest req, HttpServletResponse res) {
     name = req.getParameter("name");
     ...
     out.println(name + ", thanks for visiting!");
   }
}

當這段程式碼在單一使用者環境中正常地運作時，如果兩個使用者幾乎同時存取此 Servlet，可能會導致這兩個要求處理器的執行緒以下列方式插入：

執行緒 1： 將「Dick」指派至 name
執行緒 2： 將「Jane」指派至 name
執行緒 1： 列印「Jane, thanks for visiting!」
執行緒 2： 列印「Jane, thanks for visiting!」

因此會向第一個使用者顯示第二個使用者的名稱。

一個交易資源物件 (例如：資料庫連線) 一次只能與一個交易相關聯。由於這個原因，多個執行緒不應共用一個連線，並且不應該儲存在靜態欄位中。請參閱 J2EE Specification 的第 4.2.3 節以取得更多詳細資訊。

範例 1：

public class ConnectionManager {

private static Connection conn = initDbConn();
...
}

Session Fixation 弱點會在以下情況中出現：

1.Web 應用程式驗證一個使用者時，事先沒有使現有階段作業失效，而繼續使用已經與使用者相關聯的階段作業。
2.攻擊者可奪取使用者的階段作業識別碼，所以，在使用者驗證之後，攻擊者就可以存取驗證的階段作業。

在一般情況下，攻擊者會利用 Session Fixation 弱點，在 Web 應用程式中建立一個新的階段作業，並記錄關聯的階段作業識別碼。接著，攻擊者會讓受害者使用該階段作業識別碼驗證伺服器，這樣一來，會讓攻擊者透過作用中的階段作業取得存取使用者帳戶的權限。

有些架構 (例如 Spring Security) 在建立新的階段作業時，會自動使現有階段作業無效。若不採取此行為，應用程式會容易遭受此類攻擊。

範例 1：以下範例顯示受 Spring Security 保護之應用程式的片段，其中 Session Fixation 保護已停用。

	<http auto-config="true">
        ...
        <session-management session-fixation-protection="none"/>
	</http>

即使是易受攻擊的應用程式，此處說明的特定攻擊是否會成功取決於數個受攻擊者青睞的因素：存取未受監視的公用終端機、讓已受攻擊的網路連線保持繼續運作的能力、被吸引登入公用終端機上易受攻擊應用程式的受害者。在大多數情況下，只要肯花時間，前面兩個因素是可以克服的。只要網站有趣，不難找到使用公用終端機、也有興趣登入到易受攻擊的應用程式的受害者。網站越不受歡迎，那麼使用這個公用終端機的人就會越少，這樣一來，前述攻擊成功的可能性也越低。

攻擊者攻擊 Session Fixation 弱點所面臨的最大挑戰是：誘導受害者使用攻擊者已知的階段作業識別碼來驗證易受攻擊的應用程式。在 Example 1 中，攻擊者使用直接明顯的方法並不高明，對於攻擊知名度較低的網站並不適用。但是，千萬不要過於大意，攻擊者有許多手段來突破上述攻擊的限制。攻擊者最常採用的技術包括：利用目標網站中的 Cross-Site Scripting 或 HTTP Response Splitting 弱點 [1]。透過誘使受害者向一個易受攻擊的應用程式提交惡意要求，讓應用程式將 JavaScript 或者其他程式碼反映到受害者的瀏覽器，這樣一來，攻擊者就可以建立 Cookie，使受害者重新使用受攻擊者控制的階段作業識別碼。

要特別注意的是，通常 Cookie 會與某個已知 URL 相關聯的上層網域繫結在一起。如果多個應用程式位於同一個上層網域 (例如 bank.example.com 和 recipes.example.com)，其中一個應用程式存在弱點，那麼攻擊者便可以透過此弱點設定一個 Cookie，並在其中包含已修改的階段作業識別碼，且該階段作業識別碼可以在 example.com [2] 網域上的所有應用程式中交互使用。

其他攻擊方向還包括 DNS Poisoning 和其他以網路為基礎的攻擊，攻擊者會透過重新指向對有效網站的要求，誘使攻擊者存取惡意網站。一般來說，以網路為基礎的攻擊包括：實際出現在受害者的網路上，或是控制網路上已受攻擊的機器。雖然透過遠端方式發動攻擊比較困難，但是這類攻擊不容忽視。安全性較差的階段作業管理機制 (例如在 Apache Tomcat 中的預設實作)，可以將通常儲存在 Cookie 中的階段作業識別碼也指定給 URL。這可讓攻擊者只要透過電子郵件發送惡意 URL，就可以誘使受害者使用修改過的階段作業識別碼。