在 .NET 中，您可以使用 BinaryFormatter 类将对象转换为二进制流，该二进制流包含对象本身以及反序列化期间重建对象所需的元数据。

使用 BinaryFormatter 类可能导致不安全的反序列化场景，即攻击者可以执行任意代码，滥用应用程序逻辑，或触发拒绝服务条件。

使用 BinaryFormatter 类型有风险，不建议用于数据处理，因为它不能保证安全。

示例 1：应用程序通过在 runtimeConfig.json 文件中将配置属性 EnableUnsafeBinaryFormatterSerialization 设置为 true，允许使用不安全的 BinaryFormatter 类。

...
AppContext.SetSwitch("System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization", true);
...

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>
...

Oracle ADF Faces 组件的属性值通常只能在服务器上设置。但许多组件都允许开发人员定义可在客户端上设置的属性列表。这些组件的 unsecure 属性可以指定此列表。

目前唯一一个可在 unsecure 属性中显示的属性是 disabled，该属性允许客户端定义要启用和禁用的组件。最好不要让客户端控制只应在服务器上设置的属性值。

示例 1：以下代码显示了从用户收集密码信息并使用 unsecure 属性的 inputText 组件。

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

根据 RFC 2109，Cookie 严格意义上属于 HTTP 机制。 不应用于除 HTTP 以外的其他协议，包括 file://。 目前还不清楚它们的行为应该是什么，以及适用何种安全分隔规则。 例如，从 Internet 下载到本地磁盘的 HTML 文件是否应与本地安装的任意 HTML 代码共享相同的 Cookie？

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 文件，并使用与原始应用程序一样的权限加以执行。

当恶意行为者可以在给定 Zip 文件中指定 Zip 文件条目名称时，就会出现 Zip Path Traversal 漏洞。当恶意指定 Zip 文件条目名称时，攻击者可以在展开相应的 Zip 文件时覆盖关键系统文件的内容。攻击者可能会使用路径遍历习惯用法（例如 ../ 和 /）访问超出程序范围的系统文件。如果在 Zip 文件提取过程中检测到诸如 ../ 和 / 之类的习惯用法，针对 Android 14 及更高版本的 Android 应用程序默认情况下会抛出异常。此安全功能可能被覆盖或完全禁用。

示例 1：以下代码禁用 Zip Entry Overwrite 保护。

...
dalvik.system.ZipPathValidator.clearCallback();
...

默认情况下，ASP.NET 服务器会存储 HttpSessionState 对象、其属性及其在内存中引用的任何对象。该模型将活动会话状态限制为只利用一台计算机的系统内存所能提供的资源。为了超越这些限制来扩展容量，要频繁地为服务器配置持久会话状态信息，这样不但可以扩展容量，还允许在多台机器上来回复制以提高整体性能。为了能够维持其会话状态，服务器必须对 HttpSessionState 对象进行序列化，这就要求存储在服务器中的所有对象都是可序列化的。

为了让会话能够正确地进行序列化，应用程序以会话属性形式存储的所有对象都必须声明 [Serializable] 属性。另外，如果对象需要用自定义的序列化方法，它还必须实施一个 ISerializable 接口。

例 1：下面这个类会把自己添加到会话中，但因为它是不可序列化的，因此会话也就不能正确序列化。

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

在 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 检查模型是否通过验证。

未按正确顺序添加到中间件管道的 ASP.NET Core 中间件将无法按预期运行，从而使应用程序面临各种安全问题。

示例 1：UseCookiePolicy() 方法将 Cookie 策略中间件添加到中间件管道中，从而允许自定义 Cookie 策略。当按所示的错误顺序指定时，程序员声明的任何 Cookie 策略都将被忽略。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...

未按正确顺序添加到中间件管道的 ASP.NET Core 中间件将无法按预期运行，从而使应用程序面临各种安全问题。

示例 1：UseHttpsRedirection() 方法将 HTTPS 重定向中间件添加到中间件管道中，这样可以将不安全的 HTTP 请求重定向到安全的 HTTPS 请求。如果以所示的错误顺序指定，则在通过重定向之前列出的中间件处理请求之前不会发生有意义的 HTTPS 重定向。这样可以使应用程序处理 HTTP 请求后重定向到安全的 HTTPS 连接。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

未按正确顺序添加到中间件管道的 ASP.NET Core 中间件将无法按预期运行，从而使应用程序面临各种安全问题。

示例 1：UseHttpLogging() 方法将 HTTP 日志记录中间件添加到允许记录中间件组件的中间件管道中。当按所示的错误顺序指定时，在调用 UseHttpLogging() 之前，将不会记录添加到管道中的任何中间件。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

示例 2：UseWC3Logging() 方法将 W3C 日志记录中间件添加到允许记录中间件组件的中间件管道中。当按所示的错误顺序指定时，在调用 UseWC3Logging() 之前，将不会记录添加到管道中的任何中间件。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

通过写入、更新或删除修改数据的 ASP.NET MVC 控制器操作可能会受益于限制仅接受下列 HTTP 谓词之一：Post、Put、Patch 或 Delete。这会增加 Cross-Site Request Forgery 的难度，因为意外点击链接不会导致执行操作。

以下控制器操作默认接受任何命令，可能容易受跨站点伪装请求的影响：

public ActionResult UpdateWidget(Model model)
{
  // ... controller logic
}

如果攻击者传送的请求中包含的数据超出预期，使用拥有需要属性（标记为 [Required] 属性）和可选的属性（标记为 [Required] 属性）的模型类可能会导致问题。

ASP.NET MVC 框架将尝试捆绑请求参数到模型属性。

混合的要求而没有明确指出哪个参数为模型绑定可能表明有针对内部使用的模型属性，但是可以由攻击者控制。

以下代码定义了一种可能的模型类，其中有包含 [Required] 的属性和不包含 [Required] 的属性：

public class MyModel
{
    [Required]
    public String UserName { get; set; }

    [Required]
    public String Password { get; set; }

    public Boolean IsAdmin { get; set; }
}

如果有能更改应用程序行为的任何可选参数，那么攻击者可以通过发送一个可选参数请求来真正更改该行为。

如果攻击者传送的请求中包含的数据少于预期，使用有要求的不可为空属性的模型类（标记为 [Required] 属性）可能导致问题。

ASP.NET MVC 框架将尝试捆绑请求参数到模型属性。

如果模型有要求的不可为空属性，而攻击者没有传送需要的参数要求 -- 也就是说，攻击者使用发布中攻击 -- 那么属性将拥有默认值（通常为零），该默认值将满足 [Required] 验证属性。这可能产生不可预期的应用程序行为。

以下代码定义了一种可能的模型类，其中有要求的枚举，不可为空：

public enum ArgumentOptions
{
    OptionA = 1,
    OptionB = 2
}

public class Model
{
    [Required]
    public String Argument { get; set; }

    [Required]
    public ArgumentOptions Rounding { get; set; }
}

如果模型类有要求的属性，并且类型为父模型类的一个可选成员，如果攻击者传送的请求中包含的数据少于预期，可能会受发布中攻击的影响。

ASP.NET MVC 框架将尝试绑定要求参数到模型属性，包括子模型。

如果子模型可选 -- 也就是说，父模型有属性而没有 [Required] 属性 -- 如果攻击者没有传送子模型，那么父模型将有一个 null 值并且子模型要求的字段将不会由模型验证声明。这是发布中攻击的一种表单。

考虑以下模型类定义：

public class ChildModel
{
    public ChildModel()
    {
    }

    [Required]
    public String RequiredProperty { get; set; }
}

public class ParentModel
{
    public ParentModel()
    {
    }

    public ChildModel Child { get; set; }
}

如果攻击者没有传送针对 ParentModel.Child 属性的值，那么 ChildModel.RequiredProperty 属性将有一个未声明的 [Required]。这可能产生无法预期和不良后果。

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

示例 1：以下代码在未正确验证属性名称或值的情况下设置用户控制的 bean 属性：

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

根据 Apple 的政策，应用程序始终应向用户说明需要输入指纹的理由。如果未能做到这一点，可能会使用户感到困惑，甚至导致您的应用程序被 AppStore 拒绝。

示例 1：以下代码使用 Touch ID 验证用户，但未能提供正当理由来说明为何需要进行该验证：

    [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics localizedReason:nil
        reply:^(BOOL success, NSError *error) {
            if (success) {
                NSLog(@"Auth was OK");
            } 
    }];

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

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

void formatString(double d) {
    char c;

    scanf("%d", &c)
}