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

不建议开发人员使用未记录或隐藏的 API 构建其应用程序。 由于无法保证 Google 未来不会删除或更改这些 API，因此应避免使用它们，并且使用此类方法或字段具有破坏应用程序的较高风险。

在 Camera 对象释放后，代码试图使用该对象。在未重新获取 Camera 对象的情况下任何对该资源的进一步引用都将抛出异常。如果未捕获该异常，可能会导致应用程序崩溃。

示例 1：以下代码使用切换按钮来打开和关闭照相机预览。用户轻按该按钮后，照相机预览停止，并释放照相机资源。但是，如果再按一次该按钮，将调用之前释放的 Camera 对象中的 startPreview()。

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

在媒体对象释放后，代码试图使用该对象。在未重新获取媒体对象的情况下任何对该资源的进一步引用都将抛出异常。如果未捕获该异常，可能会导致应用程序崩溃。

示例 1：以下代码使用暂停按钮来切换媒体播放。用户轻按该按钮后，当前歌曲或视频就会暂停，并将释放照相机资源。但是，如果再按一次该按钮，将调用之前释放的媒体资源中的 start()。

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

当 Android SQLite 数据库处理器关闭后，代码仍试图使用它。在未重新建立数据库连接的情况下，对处理器的任何进一步引用都将抛出异常。如果未捕获该异常，可能会导致应用程序崩溃。

示例 1：以下代码可能来自将用户值暂时缓存在内存中、但可调用 flushUpdates() 将这些变化提交到磁盘中的程序。该方法会在将更新写入数据库后正确关闭数据库处理器。然而，当再次调用 flushUpdates() 时，数据库对象会在重新初始化之前被再次引用。

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

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

Android 应用程序可以配置为生成调试二进制代码。这些二进制文件可提供详细的调试消息，不应在生产环境中使用。<application> 标签的 debuggable 属性定义编译后的二进制文件是否应包含调试信息。

使用调试二进制文件会导致应用程序向用户提供尽可能多的关于其自身的信息。调试二进制文件旨在用于开发或测试环境，如果部署到生产环境中可能会带来安全风险。攻击者可以利用其从调试输出中获得的附加信息，对应用程序所用的框架、数据库或其他资源发动攻击。

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

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

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

压缩版本的库通过减少文件大小，改善了包含 JavaScript 文件的应用程序的页面加载时间。压缩指删除不必要的空白、注释、分号、括号、缩短本地变量的名称以及删除无法访问的代码的过程。

例 1：下列 ASPX 代码包含 Microsoft jQuery 库的未压缩版本：

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

在 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();
...

将证书验证模式设置为 None 会禁用整个证书验证过程，这会使应用程序面临中间人攻击风险。切勿在生产环境中使用此模式。

Cookie 通常用于存储有关用户的重要信息，例如个人信息、身份验证令牌及其活动历史记录。如果采用明文形式存储此信息，任何有权访问应用程序交互所使用的计算机的用户都能访问 Cookie 中存储的信息。更糟糕的是，如果允许攻击者任意修改 Cookie 中存储的数据，他们将可以篡改提供给应用程序的信息，还可能更改应用程序行为谋利。

在许多情况下，应用程序可根据使用它的上下文以编程方式验证来自 Cookie 的输入，但 ASP.NET 验证框架提供了一种绝佳方法，既可以保护 Cookie 内容，又能够确认 Cookie 未被意外修改。如果没有这种方法，将很难且通常不可能以高度可信的方式确定所有输入都经过验证。

可以将 ASP .NET 应用程序配置为生成调试二进制文件。这些二进制文件可提供详细的调试消息，不应在生产环境中使用。<compilation> 标签的 debug 属性定义编译后的二进制文件是否应包含调试信息。

使用调试二进制文件会导致应用程序向用户提供尽可能多的关于其自身的信息。调试二进制文件旨在用于开发或测试环境，如果部署到生产环境中可能会带来安全风险。攻击者可以利用其从调试输出中获得的附加信息，对应用程序所用的框架、数据库或其他资源发动攻击。