任何应用程序都可以访问在清单定义中未明确分配访问权限的公共组件。

Android 应用程序中活动、接收者和服务组件的 exported 属性的默认值取决于是否存在 intent-filter。如果存在 intent-filter，则说明该组件供外部使用。因此应将 exported 属性设为 true。现在，Android 平台上的任何其他应用程序都可以访问该组件。

示例 1：以下是一个 Android 活动示例，该示例存在 intent-filter 且未设置明确访问权限。

 <activity android:name=".AndroidActivity"/> 

   <intent-filter android:label="activityName"/> 

    <action android:name=".someFunAction"/> 

   </intent-filter> 

    ... 

 </activity> 

此活动可能遭到恶意应用程序利用。

任何应用程序都可以访问在清单定义中未明确分配访问权限的公共组件。默认情况下，会为将 android:minSdkVersion 或 android:targetSdkVersion 设置为“16”或更低值的应用程序导出 Android 内容提供者。对于将这些属性中的任意一个设置为“17”或更高值的应用程序，默认值为“false”。

示例 1：下面是在未使用明确访问权限或导出标记的情况下声明的 Android 内容提供者示例。

 <provider android:name=".ContentProvider"/> 

Android 依靠安全提供程序建立安全的网络通信。但是，有时会在默认安全提供程序中发现漏洞。为防范这些漏洞，Google Play 服务提供了一种方法，自动更新设备安全提供程序来防范已知漏洞。通过调用 Google Play 服务方法，应用程序可以确保在安装最新更新的设备上运行，从而防范已知漏洞。

应用程序可以使用网络安全配置功能在安全声明性配置文件中自定义其网络安全设置，而无需修改应用程序代码。这些设置可以针对特定域和特定应用程序进行配置。此功能的主要功能如下所示：
- 自定义信任锚点：自定义应用程序安全连接信任的证书颁发机构 (CA)。例如，信任特定的自签名证书或限制应用程序信任的公共 CA 集。
- 仅调试覆盖：安全调试应用程序安全连接，同时避免为用户群增加风险。
- 选择退出明文通信：防止应用程序意外使用明文通信。
- 证书固定：将应用程序安全连接限制为特定证书。

在未指定接收者权限的情况下发送的广播可供任何接收者访问。如果这些广播包含敏感数据或发送到恶意接收者，可能会对应用程序造成危害。

例 1：下列代码会在未指定接收者权限的情况下发送广播。

...
context.sendBroadcast(intent);
...

系统广播可以发送到专用组件。需要将组件设为公开才能接收来自第三方的非系统广播。通过将单个组件设置为接收系统和非系统广播，会将组件的某些功能（系统部分）不必要地暴露给第三方。

声明自定义权限时，可使用以下四个选项指定权限的保护级别：normal、dangerous、signature和signature or system。Normal权限会在应用程序请求时自动授予。Dangerous权限仅在用户确认后才授予。Signature权限仅授予由与定义权限的程序包相同的开发人员密钥签名的应用程序。Signature or system权限与signature权限类似，但也会授予 Android 系统映像中的程序包。

示例 1：下面是一个使用normal保护级别声明的自定义权限示例。

 <permission android:name="custom.PERMISSION"
                     android:label="@string/label_permission"
                     android:description="@string/desc_permission"
                     android:protectionLevel="normal">
      </permission>

使用读取和写入permission声明的内容提供者将可供请求对该提供者的读取或写入权限的实体访问。但是，在许多情况下，就像文件系统上的文件一样，不应允许需要读取提供者存储的数据的实体修改数据。设置 permission 属性将无法区分数据用户和影响数据完整性的交互。

示例 1：下面是一个使用读取和写入permission声明的内容提供者示例。

 <provider android:name=".ContentProvider" android:permission="content.permission.READ_AND_WRITE_CONTENT"/> 

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

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