粘滞广播不能使用权限来保护，因此可供任何接收者访问。如果这些广播包含敏感数据或发送到恶意接收者，可能会对应用程序造成危害。

例 1：下列代码会发送粘滞广播。

...
context.sendStickyBroadcast(intent);
...

定义针对 android.permission 命名空间的新权限可能在更新 OS 时产生意想不到的后果。如果新版 OS 定义完全相同的权限，Android Package Management Service (PMS) 将默默地为应用程序授予权限，而不会询问用户是否允许发动权限提升攻击。

由于该组件只会接收来自系统的广播消息，而不是来自其他组件的消息，因此该组件应该是专用的（其他组件无法访问。）

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

某些框架（例如 AngularJS）将限制可能为指向其他站点和图像的链接设置的协议。这主要是为了阻止内联 JavaScript 运行，因为其运行可能会导致应用程序中出现其他的 cross-site scripting 漏洞。

示例 1：以下代码更改了 AngularJS 中的默认允许列表协议，以允许图像 HTML 元素允许内联 JavaScript。

myModule.config(function($compileProvider){
    $compileProvider.imgSrcSanitizationWhitelist(/^(http(s)?|javascript):.*/);
});

Strict Contextual Escaping (SCE) 是 AngularJS 应用程序中的一种机制，有助于保护应用程序免受攻击者的侵害。这可以防止不同类型漏洞发起的多个攻击矢量。最突出的是防御某些类型的 Cross-Site Scripting 攻击。在此应用程序中，明确禁用此保护机制。

示例 1：在此示例中，我们在一个模块上禁用了 SCE。

myModule.config(function($sceProvider){
  $sceProvider.enabled(false);
});

该应用程序使用启用 permessage-deflate WebSocket 扩展的代码，允许通过加密连接进行压缩。启用这种类型的压缩会使应用程序受到 CRIME 和 BREACH 类型的攻击。

示例 1：以下代码将 DangerousEnableCompression 设置为 true，从而启用“per-message-deflate”扩展：

    app.Run(async context => {
        using var websocket = await context.WebSockets.AcceptWebSocketAsync(new WebSocketAcceptContext() { DangerousEnableCompression = true });
        await websocket.SendAsync(...);
        await websocket.ReceiveAsync(...);
        await websocket.CloseAsync(WebSocketCloseStatus.NormalClosure, null, default);
    });
    

示例 2：以下代码使用 DangerousDeflateOptions 设置“per-message-deflate”扩展的选项：

    using ClientWebSocket ws = new() {
        Options = {
            CollectHttpResponseDetails = true,
            DangerousDeflateOptions = new WebSocketDeflateOptions() {
                ClientMaxWindowBits = 10,
                ServerMaxWindowBits = 10
            }
        }
    };
    

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

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

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

public class DataGlob {
   String GlobName;
   String GlobValue;

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

压缩版本的库通过减少文件大小，改善了包含 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 检查模型是否通过验证。

为了执行某些特许的操作，Microsoft ASP.NET 应用程序可能会模拟当前用户的安全上下文环境或调用他们的过程。虽然模拟上下文环境有多种用途，例如减少必要的身份 authentication 尝试总次数，但是一个拥有高度特权的程序会对整个系统的安全造成不必要的危险。如果攻击者利用程序中的另一个弱点，而程序正在另一个安全上下文环境中运行，这就会使攻击者能够执行所有未授权的操作并拥有与之对应的特权。

例 1：下面的代码举例说明了使用 WindowsIdentity.Impersonate() 方法来模拟凭证的一个典型用途。

using System.Security.Principal;
...

//Get the identity of the current user
IIdentity contextId = HttpContext.Current.User.Identity;
WindowsIdentity userId = (WindowsIdentity)contextId;

//Temporarily impersonate
WindowsImpersonationContext imp = userId.Impersonate();

//Perform tasks using the caller's security context
DoSecuritySensitiveTasks();

//Clean up and restore our old security context
impersonate.Undo();

Example 1 中的代码会模拟当前用户的安全上下文，并使用它执行一个特权操作。在调用 DoSecuritySensitiveTasks() 之后，该代码会尝试恢复原始安全上下文，但如果 DoSecuritySensitiveTasks() 抛出一个异常，则永远不会调用 Undo() 方法，此时程序将继续使用模拟的安全上下文。

未按正确顺序添加到中间件管道的 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();
...