默认情况下，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() 对象。有关更多详细信息，请参见 The "Double-Checked Locking is Broken" Declaration [1]。

在线程向其他等待 mutex 的线程发出信号后，它必须调用 pthread_mutex_unlock() 来解除锁定 mutex，然后其他线程才能开始运行。如果发出信号的线程无法解除锁定 mutex，则在第二个线程中调用 pthread_cond_wait() 函数时不会返回任何值，该线程也将无法执行。

例 1：以下代码通过调用 pthread_cond_signal() 向其他等待 mutex 的线程发出信号，但无法解除锁定 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 属性来打开文件，这样，如果文件已经存在，该操作就会失败，因此可以有效地防止上述攻击类型。然而，如果攻击者可以准确预测一系列临时文件名，那么就可以阻止应用程序打开必要的临时存储空间，从而导致拒绝服务 (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 攻击。

会话持续时间越长，攻击者危害用户帐户的机会就越大。当会话处于活动状态时，攻击者可能会强力攻击用户的密码、破解用户的无线加密密钥或者通过打开的浏览器强占会话。如果创建大量的会话，较长的会话超时时间还会阻止系统释放内存，并最终导致 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 应用程序中的线程管理，因为此时使用线程管理非常容易出错。线程管理起来很困难，并且可能还会以不可预知的方式干扰应用程序容器。即使容器没有受到干扰，线程管理通常还会导致各种难以发现的错误，如死锁、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-statement，确认用户实际上是否已经过身份验证。

应用程序通过共享存储安装应用程序，任何具有外部存储读/写权限的应用程序都可写入到该存储。 由于存在争用情况，监控文件夹的恶意应用程序可将下载的 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);

文件访问的 race condition（如已知的 time-of-check、time-of-use (TOCTOU) race condition）在以下情况中出现：

1. 程序检查某个文件的属性时，根据名称来引用文件。

2.程序稍后使用相同的文件名执行文件系统操作，并假定先前检查的属性没有改变。
示例 1：以下代码来自已安装 setuid root 的程序。该程序代表非特权用户执行某些文件操作，并使用访问检查来确保它不会使用其 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
线程 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，就可以诱使受害者使用已被修改的会话标识符。