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
线程 Jane”分配给 name
线程 1： print“Jane, thanks for visiting!”
线程 2： print“Jane, thanks for visiting!”

因此会向第一个用户显示第二个用户的用户名。

对于与事务相关联的资源对象（比如数据库连接），一次只能与一个事务相关联。出于这个原因，一个连接不应该被多个线程共享，并且不应该存储在静态字段中。要获取更多详细信息，请参见 J2EE 规范中的第 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 保护的应用程序的代码段，该应用程序中的会话固定保护已禁用。

	<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，就可以诱使受害者使用已被修改的会话标识符。