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，就可以誘使受害者使用修改過的階段作業識別碼。