このコードは、Android SQLite データベースハンドラがすでに閉じられた後でこのオブジェクトの使用を試みます。データベース接続を再確立しないままハンドラをさらに参照すると例外が発生し、この例外がキャッチされない場合にはアプリケーションがクラッシュする可能性があります。

例: 次のコードは、ユーザー値を一時的にメモリにキャッシュするプログラムの一部だと考えられますが、ディスクへの変更をコミットするために 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> タグの属性) は、コンパイルされたバイナリにデバッグ情報を含めるかどうかを定義します。

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

Apache Axis 2 は、Java アプレットを介して送受信される SOAP メッセージを監視するユーティリティを開発者に提供します。SOAP Monitor には、Web サービスの呼び出しに使用されるすべての SOAP メッセージが表示されます。攻撃者はこのユーティリティを使用して、Web サービスとそのクライアント間のトラフィックを盗聴する可能性があります。

サービスがメッセージを他のサービスにリレーする場合、メッセージはリレー ポイント間で使用される最も弱いトランスポート メカニズムにさらされます。REST 自体にはセキュリティ メカニズムが含まれていないため、このサービスはメッセージの整合性と機密性をトランスポート層に依存しています。

次の設定は REST を有効にします。

<axisconfig name="AxisJava2.0">
...
    <parameter name="disableREST" locked="true">false</parameter>
...
</axisconfig>

アプリケーションが機密情報を処理し、メッセージレベルの暗号化を使用しない場合は、暗号化されたトランスポート チャネルを介した通信のみを許可する必要があります。