当同一内存地址被当作参数不止一次地调用 free() 时，会出现 Double free 错误。



针对同一个值两次调用 free()，会导致 buffer overflow。当程序使用同一参数两次调用 free() 时，程序中的内存管理数据结构会遭到破坏。这种破坏会导致程序崩溃。有时在某些情况下，还会导致两次调用 malloc() 延迟，而返回相同的指针。如果 malloc() 两次都返回同一个值，稍候程序便会允许攻击者控制整个已经写入双倍分配内存的数据，从而使程序更加容易受到 buffer overflow 的攻击。

例 1：以下代码显示了一个关于 double free 漏洞的简单例子。

	char* ptr = (char*)malloc (SIZE);
	...
	if (abrt) {
	  free(ptr);
	}
	...
	free(ptr);

Double free 漏洞的产生有两个常见（有时候这两个原因会同时发生作用）原因：

－ 错误状况及其他异常情况。

— 不清楚由程序的哪一部分负责释放内存。

虽然某些 double free 漏洞并不比上一个例子复杂多少，但是大部分漏洞都分散在上百行代码中，甚至还会出现在不同的文件中。程序员似乎特别容易受到多次释放全程变量的影响。

包含 Unicode 双向覆盖控制字符的源代码可能是内部威胁攻击的标志。可以通过 C、C++、C#、Go、Java、JavaScript、Python 和 Rust 等编程语言的供应链来利用这种攻击。Nicholas Boucher 和 Ross Anderson 已经发布了多种变体攻击，包括以下几种：Early Return、Commenting-Out 和 Stretched String。
示例 1：以下代码展示了存在于 C 源代码文件中的一种控制字符，该字符会导致 Early Return 攻击：

#include <stdio.h>

int main() {
	/* Nothing to see here; newline RLI /*/ return 0 ;
	printf("Do we get here?\n");
	return 0;
}

在Example 1 中，从右到左隔离 (RLI) Unicode 双向控制字符会导致代码如下所示：

#include <stdio.h>

int main() {
	/* Nothing to see here; newline; return 0 /*/
	printf("Do we get here?\n");
	return 0;
}

需要特别注意的是，在易受攻击的编辑器/查看器中执行代码审查的开发人员将看不到易受攻击的编译器将会处理的内容。具体来说是修改程序流的 Early Return 语句。

该库处于实验阶段，不应在生产环境中使用，除非您知道自己在做什么。

Buffer overflow 可能是人们最熟悉的一种软件安全漏洞。虽然绝大多数软件开发者都知道什么是 Buffer overflow 漏洞，但是无论是对继承下来的或是新开发的应用程序来说，Buffer overflow 攻击仍然是一种最常见的攻击形式。对于这个问题出现的原因，一方面是造成 buffer overflow 漏洞的方式有很多种，另一方面是用于防止 buffer overflow 的技术也容易出错。

在一个典型的 buffer overflow 攻击中，攻击者将数据传送到某个程序，程序会将这些数据储存到一个较小的堆栈缓冲区内。结果，调用堆栈上的信息会被覆盖，其中包括函数的返回指针。数据会被用来设置返回指针的值，这样，当该函数返回时，函数的控制权便会转移给包含在攻击者数据中的恶意代码。

虽然这种类型的堆栈 buffer overflow 在某些平台和开发组织中十分常见，但仍不乏存在其他各种类型的 buffer overflow，其中包括堆 buffer overflow 和 off-by-one 错误等。有关 buffer overflow 如何进行攻击的详细信息，许多优秀的著作都进行了相关介绍，如 Building Secure Software [1]、Writing Secure Code [2] 以及 The Shellcoder's Handbook [3]。

在代码层上，buffer overflow 漏洞通常会违反程序员的各种假设。C 和 C++ 中的很多内存处理函数都没有执行边界检查，因而可轻易地超出缓冲区所操作的、已分配的边界。即使是边界函数（如 strncpy()），使用方式不正确也会引发漏洞。对内存的处理加之有关数据段大小和结构方面所存在种种错误假设，是导致大多数 buffer overflow 漏洞产生的根源。

在这种情况下，结构不良的 format string 会导致程序访问分配的内存边界之外的值。

示例 1：以下代码会从堆栈中读取任意值，因为格式说明符的数量与传递给该函数的参数数量不一致。

void wrongNumberArgs(char *s, float f, int d) {
   char buf[1024];
   sprintf(buf, "Wrong number of %.512s");
}

Buffer overflow 可能是人们最熟悉的一种软件安全漏洞。虽然绝大多数软件开发者都知道什么是 Buffer overflow 漏洞，但是无论是对继承下来的或是新开发的应用程序来说，Buffer overflow 攻击仍然是一种最常见的攻击形式。对于这个问题出现的原因，一方面是造成 buffer overflow 漏洞的方式有很多种，另一方面是用于防止 buffer overflow 的技术也容易出错。

在一个典型的 buffer overflow 攻击中，攻击者将数据传送到某个程序，程序会将这些数据储存到一个较小的堆栈缓冲区内。结果，调用堆栈上的信息会被覆盖，其中包括函数的返回指针。数据会被用来设置返回指针的值，这样，当该函数返回时，函数的控制权便会转移给包含在攻击者数据中的恶意代码。

虽然这种类型的堆栈 buffer overflow 在某些平台和开发组织中十分常见，但仍不乏存在其他各种类型的 buffer overflow，其中包括堆 buffer overflow 和 off-by-one 错误等。有关 buffer overflow 如何进行攻击的详细信息，许多优秀的著作都进行了相关介绍，如 Building Secure Software [1]、Writing Secure Code [2] 以及 The Shellcoder's Handbook [3]。

在代码层上，buffer overflow 漏洞通常会违反程序员的各种假设。C 和 C++ 中的很多内存处理函数都没有执行边界检查，因而可轻易地超出缓冲区所操作的、已分配的边界。即使是边界函数（如 strncpy()），使用方式不正确也会引发漏洞。对内存的处理加之有关数据段大小和结构方面所存在种种错误假设，是导致大多数 buffer overflow 漏洞产生的根源。

在这里，一个不正确地构成的 format string 会导致程序错误地进行值的转换，或访问分配的内存边界之外的值。

示例 1：以下代码使用 %d 格式说明符将一个浮点转换为 f。

void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
   char buf[1024];
   sprintf(buf, "Wrong type of %d", f);
   ...
}

内部 Intent 使用内部组件定义的自定义操作。隐式意图可以促进从任何给定外部组件调用意图，而无需了解特定组件。将两者结合起来使应用程序能够从所需的应用程序上下文外部访问为特定内部使用指定的意图。

通过外部应用程序处理内部 Intent 的能力可以实现各种严重程度不等的中间人攻击，从信息泄露、拒绝服务到远程代码执行，具体取决于 Intent 指定的内部操作的能力。

示例 1：以下代码使用隐式内部 Intent。

...
val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
startActivity(imp_internal_intent_action)
...

Android Intents 用于通过提供有关给定组件执行的操作的指令将应用程序和应用程序组件绑定在一起。创建待定意图以便稍后传送 Intent。隐式意图有助于从任何给定的外部组件调用意图，使用通用名称和筛选器来确定执行。

当隐式 Intent 创建为 PendingIntent，这可能允许将 Intent 发送到在预期时间上下文之外运行的非预期组件，从而使系统容易受到拒绝服务、私人和系统信息泄露以及权限提升等攻击途径。

示例 1：以下代码使用隐式 PendingIntent。

...
val imp_intent = Intent()
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable_impintintent = PendingIntent.getService(
    this,
    0,
    imp_intent,
    flag_mut
)
...

允许在创建 PendingIntent 后修改其底层 Intent 可能会使系统容易受到攻击。这主要取决于底层 Intent 的整体功能。在大多数情况下，最佳实践是通过将 PendingIntent 标记设置为 FLAG_IMMUTABLE 来防止发生潜在问题。

示例 1：以下代码包含使用标记值 FLAG_MUTABLE 创建的 PendingIntent。

...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE

val pi_flagmutable = PendingIntent.getService(
    this,
    0,
    intent_flag_mut,
    flag_mut
)
...

Memory leak 的产生有两个常见（有时候这两个原因会同时发生作用）原因：

－ 错误状况及其他异常情况。

— 不清楚由程序的哪一部分负责释放内存。

大多数 memory leak 会导致常规软件可靠性问题，但如果攻击者能够蓄意触发 memory leak，他就可能会通过引发程序崩溃来发起一个 denial of service 攻击，或者是利用因内存低的情况 [1] 所引发的其他意外的程序行为。

例 1：如果调用 read() 后没有返回预期的字节数，以下 C 函数将会泄漏已分配的内存块的信息：

  char* getBlock(int fd) {
  char* buf = (char*) malloc(BLOCK_SIZE);
  if (!buf) {
    return NULL;
  }
  if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {
    return NULL;
  }
  return buf;
}

Memory leak 的产生有两个常见（有时候这两个原因会同时发生作用）原因：

－ 错误状况及其他异常情况。

— 不清楚由程序的哪一部分负责释放内存。

大多数 memory leak 会导致常规软件可靠性问题，但如果攻击者能够蓄意触发 memory leak，他就可能会通过引发程序崩溃来发起一个 denial of service 攻击，或者是利用因内存低的情况 [1] 所引发的其他意外的程序行为。

例 1：如果 realloc() 调用无法调整初始分配的大小，以下 C 函数会泄漏一块分配的内存。

char* getBlocks(int fd) {
  int amt;
  int request = BLOCK_SIZE;
  char* buf = (char*) malloc(BLOCK_SIZE + 1);
  if (!buf) {
    goto ERR;
  }
  amt = read(fd, buf, request);
  while ((amt % BLOCK_SIZE) != 0) {
     if (amt < request) {
        goto ERR;
     }
     request = request + BLOCK_SIZE;
     buf = realloc(buf, request);
     if (!buf) {
        goto ERR;
     }
     amt = read(fd, buf, request);
  }

  return buf;

  ERR:
  if (buf) {
    free(buf);
  }
  return NULL;
}

null 指针错误通常是由于违反一个或多个程序员假设而造成的。

大多数 null 指针问题会导致一般软件可靠性问题，但如果攻击者可能有意触发 null 指针间接引用，他们可以使用生成的异常绕过安全逻辑或使应用程序显示调试信息，这些信息在规划后续攻击时十分有用。

示例 1：在以下代码中，程序员假定系统始终会定义一个名为“cmd”的属性。如果攻击者可以控制程序的环境，从而使“cmd”处于未定义状态，则它就会在尝试调用 trim() 方法时抛出一个 null 指针异常。

String val = null;
...
cmd = System.getProperty("cmd");
if (cmd)
	val = util.translateCommand(cmd);
...
cmd = val.trim();

随着编程语言的发展，有时会弃用些一些方法，原因是：

－ 为了改进该编程语言
- 对如何有效、安全地执行操作有了更深一
步的了解
－ 某些操作的管理规则发生了变化

在某一种编程语言中，人们通常会放弃使用某些方法，转而采用更新的方法。在执行同样的任务时，新方法会采用不同的处理方式，这种方式往往比原有的方法更合理。
示例 1：以下代码根据字节数组和用于指定每个 16 位 Unicode 字符的前 8 位的值构造一个字符串对象。

...
String name = new String(nameBytes, highByte);
...

在此示例中，构造函数可能无法正确地将字节转换为字符，具体取决于使用哪个字符集对以 nameBytes 表示的字符串进行编码。由于用于编码字符串的字符集的演变，此构造函数已被弃用，取而代之的是接受用于编码字节进行转换的 charset 的名称作为其参数之一的构造函数。

并非所有函数都会因为存在安全漏洞而被弃用或被取代。然而，出现被弃用的函数通常表示周围代码已经不起作用了，有可能处于不受维护的状况。在过去很长一段时间内，人们并没有将软件安全放在首位，甚至都未曾考虑过。如果程序使用了不推荐的或过时的函数，在其附近就会潜伏着安全问题。

不使用 IsBadXXXPtr() 类的函数有多种原因。这些函数是：
1) 非线程安全的。
2) 通常与由于其探测无效内存地址而导致的崩溃有关。
3) 被错误地认为在异常条件中执行正确的错误处理。

示例 1：以下代码使用 IsBadWritePtr() 尝试避免错误的内存写入。

if (IsBadWritePtr(ptr, length))
{
    [handle error]
}

程序员原本希望使用这些函数来检测异常情况，但它们通常导致更多无法修复的问题。

在同一个类中，成员字段与方法同名会给程序员带来诸多困扰。当他想要访问某字段时却意外地调用了与之同名的方法；反之当他想要调用某一方法时却又访问了与之同名的字段。

例 1：

public class Totaller {
  private int total;
  public int total() {
    ...
  }
}

Java 中的同步处理是一个非常棘手的问题。一个 empty synchronized block 通常只标志程序员正在处理同步问题，但还没有达到预期的结果。

示例 1：

synchronized(this) { }

在 Java 语言规范的第 3.8 节中论述了美元符号，但仅将它作为用于机器产生的源代码中的标识符。

示例 1：

int un$afe;

没有使用该变量的初始值。初始化之后，变量或者被重新赋值，或者转向作用域之外。

示例 1：以下摘录的代码为变量 r 赋值，并在没有使用所赋数值的情况下，对其加以重写。

  int r = getNum();
  r = getNewNum(buf);

没有使用该变量的值。赋值之后，变量或者被重新赋值，或者超出范围之外。

示例 1：以下摘录的代码为变量 r 赋值，并在没有使用所赋数值的情况下，对其加以重写。

  r = getName();
  r = getNewBuffer(buf);

从未使用过该变量。有可能该变量只是一个残留的无用代码，但也可能该未使用的变量会指出一个 bug。

示例 1：在以下代码中，复制粘贴错误导致同一个循环迭代器 (i) 使用了两次，而变量 j 却从未使用。

  int i,j;

  for (i=0; i < outer; i++) {
    for (i=0; i < inner; i++) {
      ...

这一类函数的行为会因操作系统而异，甚至有时还会受操作系统版本的影响。函数的实现差异主要包括：

— 参数解析方式的细微差异会导致结果不一致。

— 一些函数的实现本身就包含了很大的安全风险。

— 并非所有平台上都定义了函数。