すべてのアプリケーションが、マニフェスト定義でアクセス許可が明示的に割り当てられていないパブリック コンポーネントにアクセスできます。

Android アプリケーションのアクティビティ、レシーバー、およびサービスコンポーネントの exported 属性のデフォルト値は、intent-filter の有無に依存します。intent-filter が存在している場合、コンポーネントでは外部使用が意図されていることを意味しているため、exported 属性には true が設定されます。このコンポーネントは、Android プラットフォーム上の他のどのアプリケーションからもアクセスできるようになります。

例 1:intent-filter は設定されているが明示的なアクセス権限は設定されていない場合の Android アクティビティの例を次に示します。

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

システム ブロードキャストはプライベート コンポーネントに送信できます。サードパーティからの非システム ブロードキャストを受信するには、コンポーネントをパブリックにする必要があります。システム ブロードキャストと非システム ブロードキャストの両方を単一のコンポーネントで受信するように登録すると、コンポーネントの機能の一部 (システム部分) が不必要にサードパーティに公開されます。

カスタム権限を宣言する場合、権限の保護レベルを指定するための 4 つのオプションがあります: 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"/> 

Sticky ブロードキャストは、権限を設定してセキュリティを確保することはできないため、あらゆる受信者がアクセスできるようになります。これらのブロードキャストに重要なデータが含まれる、あるいは不正な受信者にアクセスする場合には、アプリケーションが危険にさらされる可能性があります。

例 1: 次のコードは、Sticky ブロードキャストを使用しています。

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

android.permission 名前空間に新しい権限を定義すると、OS の更新時に予期しない結果が発生する場合があります。新しいバージョンの OS がまったく同じ権限を定義すると、Android Package Management Service (PMS) は、ユーザーに確認することなく、アプリに対してサイレントに権限を付与するため、権限昇格攻撃のチャンスを与えることになります。

このコンポーネントは、システムからブロードキャスト メッセージを受信することのみを想定しています。他のコンポーネントからの受信は想定していないため、プライベートにする必要があります (他のコンポーネントからはアクセスできません)。

Cookie は、RFC 2109 による厳格な HTTP メカニズムです。 Cookie が file:// を含む HTTP 以外のプロトコルに対して動作するはずがありません。 それらのプロトコルの動作や適用されるセキュリティ区分化のルールは不明です。 たとえば、インターネットからローカル ディスクにダウンロードされた HTML ファイルは、ローカルにインストールされた HTML コードと同じ cookie を共有するのでしょうか?

開発者がドキュメントに記載されていない、または非表示の API を使用してアプリケーションを構築することはお勧めしません。 Google がこれらの API を今後削除または変更しないという保証がないため、使用を避ける必要があります。そのようなメソッドやフィールドを使用すると、アプリケーションが破壊されるリスクが高くなります。

このコードは、Camera オブジェクトがすでに解放された後でこのオブジェクトの使用を試みます。リソースを再取得しないまま Camera オブジェクトをさらに参照すると例外が発生し、この例外がキャッチされない場合にはアプリケーションがクラッシュする可能性があります。

例 1: 次のコードは、トグル ボタンを使用してカメラのプレビューをオン/オフしています。ユーザーがこのボタンを 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: 次のコードは、一時停止ボタンを使用してメディアの再生を切り替えています。ユーザーがこのボタンを 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();
  }
  ...
}

ハードウェアおよびデバイスの固有IDは、データを消去したり、出荷時の状態に初期化しても、変化しません。ユーザーの認可または認証で使用される一意の ID を生成する場合、データ消去や初期化に依存しないでください。

また、個人情報を伴う可能性があるUUIDをリークさせると、ユーザーのプライバシーおよびセキュリティに脅威を与えます。

Android Class Loading Hijacking の脆弱性には、次の 2 つの形態があります。

- プログラムがクラスをロードするために検索するディレクトリの名前を攻撃者が変更可能である。攻撃者は、プログラムに自分が制御するディレクトリへのパスを参照させることで、クラスが検索されるパスを明示的に制御することになります。

- クラスがロードされる環境を攻撃者が変更可能である。攻撃者はパス名の意味を暗黙的に制御することになります。

この場合は 1 つ目の状況が最も懸念されます。攻撃者は、ロードするクラスが検索されるディレクトリを制御できる可能性があります。このタイプの 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 を使用して、Optimized DEX ファイルを書き込むディレクトリを決定します。

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

このコードでは、攻撃者が Optimized DEX (ODEX) ファイルの出力ディレクトリを指定できます。その結果、悪意のあるユーザーが userOutput の値を、外部ストレージなど、攻撃者が制御するディレクトリに変更できます。これが実行された後は、出力される ODEX ファイルを悪意のある ODEX ファイルに置き換えるだけで、元のアプリケーションと同じ権限でこれを実行できるようになります。

Android アプリケーションは、デバッグ バイナリを生成するように設定できます。これらのバイナリは詳細なデバッグ メッセージを提供するため、実運用環境では使用しないでください。debuggable 属性 (<application> タグの属性) は、コンパイルされたバイナリにデバッグ情報を含めるかどうかを定義します。

デバッグ バイナリを使用すると、アプリケーションが、それ自体に関するできるだけ多くの情報をユーザーに提供します。デバッグ バイナリは、開発環境またはテスト環境で使用することを目的としており、実運用環境にデプロイするとセキュリティ リスクを引き起こす可能性があります。攻撃者はデバッグ出力から得た追加情報を利用して、フレームワークやデータベースなど、アプリケーションで使用されるリソースを標的に攻撃を仕掛けることがあります。

Zip パス トラバーサル脆弱性が発生するのは、悪意のある攻撃者が特定の Zip ファイル内の Zip ファイル エントリ名を指定できる場合です。Zip ファイル エントリ名が悪意を持って指定されると、攻撃者は対応する Zip ファイルが展開されたときに重要なシステム ファイルの内容を上書きできます。攻撃者は、../ や / などのパス トラバーサル イディオムを使用して、プログラム領域外にあるシステム ファイルにアクセスする可能性があります。Android 14 以降を対象とする Android アプリケーションは、Zip ファイルの抽出中に ../ や / などのイディオムが検出されると、デフォルトで例外を発生させることができます。このセキュリティ機能は、上書きしたり、完全に無効にしたりすることができます。

例 1: 次のコードは、Zip Entry Overwrite 保護を無効にします。

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