AccessibleObject API 允许程序员绕过由 Java 访问说明符提供的 access control 检查。特别是它让程序员能够允许反映对象绕过 Java access control，并反过来更改私有字段或调用私有方法、行为，这些通常情况下都是不允许的。

在常规 JSF 应用程序中，使用 UI 组件指定的转换器和验证器来转换和验证值。提交页面时会自动进行转换和验证。Fusion 应用程序中可创建书签的视图不会执行页面提交，因此默认情况下不会执行类似的转换或验证。

示例 1：以下配置文件代码段显示了配置为不执行 paramName URL 参数的转换或验证的可创建书签的示例视图。

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

Android 类加载劫持漏洞主要表现为以下两种形式：

- 攻击者可以更改程序在其中搜索来加载类的目录的名称，从而指向他们有控制权的某个目录的路径：攻击者明确控制了将在其中搜索类的路径。

- 攻击者可以更改用于加载类的环境：攻击者间接控制了路径名的含义。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制在其中搜索加载类的目录。这种类型的 Android Class Loading Hijacking 漏洞会在以下情况下出现：

1. 数据从不可信赖的数据源进入应用程序。



2. 数据用作一个或部分字符串，代表在其中搜索要加载的类的库目录。



3. 通过从库路径执行代码，应用程序授予攻击者在一般情况下无法获得的权限或能力。

例 1：以下代码使用用户可更改的 userClassPath，来确定在其中搜索要加载的类的目录。

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

此代码允许攻击者通过将 userClassPath 的结果修改为指向他们控制的不同路径，以提升的应用程序权限加载库并可能执行任意代码。因为程序不验证从环境读取的值，如果攻击者能够控制 userClassPath 的值，那么他们就可以欺骗应用程序指向他们控制的目录，从而使用与原始应用程序一样的权限加载他们已经定义的类。

例 2：以下代码使用用户可更改的 userOutput，来确定应将优化的 DEX 文件写入的目录。

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

此代码允许攻击者指定优化的 DEX 文件 (ODEX) 的输出目录。这样，恶意用户便可以将 userOutput 的值更改为他们控制的目录，例如外部存储。一旦达到这一目的，便可以很轻松地将输出的 ODEX 文件替换为恶意 ODEX 文件，并使用与原始应用程序一样的权限加以执行。

在 ASP.NET Web API 服务中，未经验证的输入是导致漏洞产生的首要原因之一。未经检验的输入会导致出现各种漏洞，包括 Cross-Site Scripting、Process Control、Access Control 和 SQL Injection。尽管 ASP.NET Web API 服务通常情况下不容易受到 Memory Corruption 攻击，但是如果 ASP.NET Web API 服务调用未执行数组边界检查的本地代码，攻击者就可能会利用 ASP.NET Web API 服务中的 Input Validation 缺陷发起 Buffer Overflow 攻击。

为了防止此类攻击，请执行以下操作：
1. 使用验证属性通过编程将模型绑定对象参数的参数或成员的验证检查注释为 ASP.NET Web API 服务操作。
2. 使用 ModelState.IsValid 检查模型是否通过验证。

Bean 属性的名称和值在填充任何 bean 之前都需要进行验证。Bean 填充功能允许开发人员设置 bean 属性或嵌套属性。攻击者可以利用此功能访问特殊的 bean 属性，例如 class.classLoader，此类属性将允许攻击者覆盖系统属性并可能会执行任意代码。

示例：下列代码将会设置用户控制的 bean 属性，而不会正确验证属性名称或值：

String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);

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 漏洞产生的根源。

Buffer overflow 漏洞通常出现在以下代码中：

— 依靠外部的数据来控制行为的代码。

— 受数据属性影响的代码，该数据在代码的临接范围之外执行。

— 代码过于复杂，以致于程序员无法准确预测它的行为。



以下例子分别演示了上面三种情况。

例 1.a：以下示例代码显示了简单的 buffer overflow，它通常由第一种情况所导致，即依靠外部数据来控制行为的代码。该代码使用 gets() 函数将一个任意大小的数据读取到堆栈缓冲区中。因为没有什么方法可以限制该函数读取数据的量，所以代码的安全性就依赖于用户始终输入比 BUFSIZE 少的字符数量。

	...
	char buf[BUFSIZE];
	gets(buf);
	...

例 1.b：这一例子表明模仿 C++ 中 gets() 函数的不安全行为是如此的简单，只要通过使用 >> 运算符将输入读取到 char[] 字符串中。

	...
	char buf[BUFSIZE];
	cin >> (buf);
	...

例 2：虽然本例中的代码也是依赖于用户输入来控制代码行为，但是它通过使用边界内存复制函数 memcpy() 增加了一个间接级。该函数接受一个目标缓冲区、一个起始缓冲区和要复制的字节数。虽然输入缓冲区由 read() 的边界调用填充，但是 memcpy() 复制的字节数需要由用户指定。

	...
char buf[64], in[MAX_SIZE];
printf("Enter buffer contents:\n");
read(0, in, MAX_SIZE-1);
printf("Bytes to copy:\n");
scanf("%d", &bytes);
memcpy(buf, in, bytes);
	...

注：该类型的 buffer overflow 漏洞（程序可读取数据，然后对剩余数据随后进行的内存操作中的一个数值给予信任）已在图像、音频和其他的文件处理库中频繁地出现。

例 3：这是一个关于第二种情况的例子，代码受未在本地校验的数据属性的影响。在本例中，名为 lccopy() 的函数将一个字符串作为其变量，然后返回一个堆分配字符串副本，并将该字符串的所有大写字母转化成了小写字母。因为该函数认为 str 总是比 BUFSIZE 小，所以它不会对输入执行任何边界检查。如果攻击者避开对调用 lccopy() 代码的检查，或者如果更改代码，使得程序员对 str 长度的原有假设与实际不符，那么 lccopy() 就会通过无边界调用 strcpy() 溢出 buf。

char *lccopy(const char *str) {
	char buf[BUFSIZE];
	char *p;

	strcpy(buf, str);
	for (p = buf; *p; p++) {
		if (isupper(*p)) {
			*p = tolower(*p);
		}
	}
	return strdup(buf);
}

示例 4：以下代码演示了第三种情况，代码非常复杂，无法轻松预测其行为。该代码来自通用的 libPNG 图像解码器，众多应用程序使用的都是该解码器。

该代码似乎可以安全地执行边界检查，因为它检测变量长度的大小，该变量长度会在之后用来控制 png_crc_read() 复制的数据量。然而，在测试长度前，该代码会立即对 png_ptr->mode 执行检查，如果检查失败，便会发出一个警告，然后会继续进行处理。因为 length 测试在 else if 块中进行，如果针对该代码的首次测试失败，那么就不会再测试 length，而将其盲目地用于调用 png_crc_read()，因此很容易引起堆栈 Buffer Overflow。

虽然本例中的代码不是我们所遇见的代码中最复杂的，但是它足以说明为什么要尽可能地降低执行内存操作代码的复杂度。

if (!(png_ptr->mode & PNG_HAVE_PLTE)) {
	/* Should be an error, but we can cope with it */
png_warning(png_ptr, "Missing PLTE before tRNS");
}
else if (length > (png_uint_32)png_ptr->num_palette) {
png_warning(png_ptr, "Incorrect tRNS chunk length");
png_crc_finish(png_ptr, length);
return;
}
...
png_crc_read(png_ptr, readbuf, (png_size_t)length);

例 5：本例同样演示了第三种情况，程序过于复杂，使其暴露出 buffer overflow 的问题。在这种情况下，问题出现的原因在于其中某个函数的接口不明确，而不是代码结构（同上一个例子中描述的情况一样）。

getUserInfo() 函数采用一个定义为多字节字符串的用户名和一个指向用户信息结构的指针，这一结构由该用户的相关信息填充。因为 Windows authentication 中的用户名使用 Unicode，所以 username 参数首先要从多字节字符串转换成 Unicode 字符串。然后，这个函数便会错误地将 unicodeUser 的长度以字节形式而不是字符形式传递出去。调用 MultiByteToWideChar() 可能会把 (UNLEN+1)*sizeof(WCHAR) 宽字符或者
(UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) 字节，写到 unicodeUser 数组，该数组仅分配了 (UNLEN+1)*sizeof(WCHAR) 个字节。如果 username 字符串包含了多于 UNLEN 的字符，那么调用 MultiByteToWideChar() 将会溢出 unicodeUser 缓冲区。

void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1];
	MultiByteToWideChar(CP_ACP, 0, username, -1,
    	      			unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
}

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 会导致程序在分配的内存边界之外写入数据。

示例：以下代码会溢出 c，因为 double 类型需要的空间超过分配给 c 的空间。

void formatString(double d) {
    char c;

    scanf("%d", &c)
}