默认情况下，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 中创建临时文件。而多数函数都很容易受到各种攻击。
示例 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 属性来打开文件，这样，如果文件已经存在，该操作就会失败，因此可以有效地防止上述攻击类型。然而，如果攻击者可以准确预测一系列临时文件名，那么就可以阻止应用程序打开必要的临时存储空间，从而导致拒绝服务 (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 及其他同步错误等。

几乎每一个对软件系统的严重攻击都是从违反程序员的假设开始的。攻击后，程序员的假设看起来既脆弱又拙劣，但攻击前，许多程序员会在午休时间为自己的种种假设做很好的辩护。

在代码中，很容易发现两个令人怀疑的假设：“一是这个函数调用不可能出错；二是即使出错了，也不会对系统造成什么重要影响。”因此当程序员忽略条件时，这其实就表明了他们是基于上述假设进行的操作。

例 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 块看上去繁琐，但使用一个“简约”的 catch 块捕获高级别的异常类（如 Exception），可能会混淆那些需要特殊处理的异常，或是捕获了不应在程序中这一点捕获的异常。本质上，捕获范围过大的异常与“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. 在异常离开当前页之前，未能对其进行适当地处理。

几乎每一个对软件系统的严重攻击都是从违反程序员的假设开始的。攻击后，程序员的假设看起来既脆弱又拙劣，但攻击前，许多程序员会在午休时间为自己的种种假设做很好的辩护。

代码中两个容易识破的可疑假设是：“该操作从不会失败”和“如果该操作失败了也没关系”。如果程序员没有抓住某个操作抛出的异常，则间接地表明了他们是基于这些假设进行的操作。