Android

アプリケーションレベルの保護

アプリケーションのインストーラーを検証する

アプリケーションが公式の Google Play ストアを通じて配布されていることを確認するために、インストーラーのパッケージ名が次のとおりであることを確認してください。 com.android.vending。これはサイドチャネル配布やサードパーティソースからの不正なインストールを防ぐのに役立ちます。

アプリケーションの強制更新

Google Play でセキュリティ更新が利用可能な場合、エンドユーザーがサービスを継続して使用する前に更新を強制してください。これにより、エンドユーザーは常に必要なセキュリティ修正を含む最新バージョンを使用することが保証されます。

アプリケーションリソースを内部ストレージのみに保存する

アプリケーションリソースを外部ストレージではなく内部ストレージに保存することで、「Man-in-the-Disk（MITD）」攻撃のリスクを軽減できます。つまり、アプリケーションは android:installLocation マニフェスト属性を使用して外部ストレージに移動できないようにすべきです。

SDK がサポートする OS バージョンとの互換性

アプリケーションを SDK がサポートする OS バージョンのデバイスで動作するように設計してください。これにより、一貫性のある信頼できるエンドユーザー体験が確保されます。

デバイスのロック画面を有効にする

アプリケーションは、以下のコードスニペットを使用してデバイスが PIN、パターン、またはパスワードで保護されていることを確認することを推奨します：

KeyguardManager kgManager = (KeyguardManager) context.getSystemService(Context.KEYGUARD_SERVICE);kgManager.isDeviceSecure()

過剰な権限を防ぐ

アプリケーションは必要な Android 権限のみを宣言することを推奨します。そうしないと、攻撃者が特権情報にアクセスする可能性があります。

プラットフォームセキュリティのエクスポート属性

Android アプリケーションは、次のコンポーネントの一つ以上で構成されます：

アクティビティ
サービス
ブロードキャストレシーバー
コンテントプロバイダ

これらのコンポーネントを使用する際は、関連するリスクや攻撃経路に注意してください。アプリ間通信は一般にリスクが高いです。メインのアクティビティのみを公開することを検討してください。その他のコンポーネントには export=false を設定してください。もし他のコンポーネントを公開する必要がある場合は、カスタム権限で保護してください。

リリースバリアントでアプリケーションのデバッグを無効にする

デバッグモードを取り除くには、明示的に android:debuggable 属性を <application> 要素の false に設定してください。Android マニフェストファイルで最終 APK がデバッグ可能でないことを確認するには、次のチェックを行ってください：

aapt d xmltree <myApplication.apk> AndroidManifest.xml

最終 APK を検証した後、属性が値 0x0で存在することを確認してください。ビルドプロセスでこのチェックを自動化できます。

アプリリンクとディープリンクの評価

ディープリンクとアプリリンクはアプリケーションの攻撃対象領域を増やす可能性があります。一般的なリスクにはリンクのハイジャックや機密機能の意図しない公開が含まれます。動作は Android のバージョンによっても異なります：

Android 12（API レベル 31）より前では、アプリケーションに検証できないリンクがある場合、そのアプリケーションのすべての Android App Links の検証が行われない可能性があります。
Android 12（API レベル 31）以降では、アプリケーションは攻撃対象領域の縮小の恩恵を受けます。ターゲットアプリケーションがそのウェブインテントに含まれる特定のドメインで承認されていない限り、汎用のウェブインテントはエンドユーザーのデフォルトブラウザアプリケーションに解決されます。

すべてのディープリンクを列挙し、正しいウェブサイト関連付けを検証してください。サポートされる操作を徹底的にテストしてください。すべての入力データを信頼しないものとして扱い、常に検証を行ってください。検証により期待されるデータのみが処理されることが保証されます。

自動生成されたスクリーンショットの防止

Activity の Activity.onCreate メソッドを使用して、フォアグラウンドのスクリーンショットによる機密データの漏洩を防止します：

getWindow().addFlags(LayoutParams.FLAG_SECURE);。

また、アクティビティの onPause() メソッドを使用して、モバイルアプリケーションがバックグラウンドで実行されている間にメモリに残しておくべきでない他の機密情報をクリアすることもできます。

適切なアプリ署名

リリースビルドが Android 7.0（API レベル 24）以降では v1 および v2 スキームの両方で署名され、Android 9（API レベル 28）以降では 3 つすべてのスキームで署名されていることを確認してください。

注記
開発者が APK 内のコード署名証明書の所有者です。

APK 署名は、[SDK-Path]/build-tools/[version] にある apksigner ツールを使用して検証できます。

$ apksigner verify --verbose Desktop/example.apkVerified using v1 scheme (JAR signing): trueVerified using v2 scheme (APK Signature Scheme v2): true Verified using v3 scheme (APK Signature Scheme v3): true Number of signers: 1

アプリケーションデータのバックアップを防止する

アプリケーションデータのバックアップを防ぐには、 allowBackup 属性を false に設定してください。アプリケーションタグの AndroidManifest.xml ファイル内で行います。

<?xml version="1.0" encoding="utf-8"?><manifest xmlns:android="http://schemas.android.com/apk/res/android">    <application        android:allowBackup="false">    </application></manifest>

デフォルトでは、 android:allowBackup 属性は trueに設定されています。このフラグが trueに設定されていると、エンドユーザーはアプリケーションデータをバックアップおよび復元できます。これにはアプリケーションにとってセキュリティ上の影響がある場合があります。

バックアップ機能により、USB デバッグを有効にしたエンドユーザーはデバイスからアプリケーションデータをコピーできます。一度バックアップされると、アプリケーションデータはエンドユーザーによって読み取られる可能性があります。

設定 allowBackup="false" により、アプリケーションはバックアップおよび復元機能の両方をオプトアウトできます。

機密画面でのアクセシビリティを防ぐ

Android のアクセシビリティサービスは、障害のあるエンドユーザーがデバイスと新しい方法で対話することを可能にする強力な機能です。しかし、アクセシビリティサービスは濫用されて機密データの窃取やデバイス制御に利用されるリスクもあります。

銀行や決済アプリを標的とするマルウェアはしばしばアクセシビリティ機能を濫用します。アプリケーションはアクセシビリティアプリが機密コンテンツにアクセスする必要があるかどうかを判断すべきです。以下の手法はアクセシビリティサービスを検出し、アクセシビリティイベントによる機密データ漏洩を減らすことができます。これらのチェックは、障害のあるエンドユーザーにとってアプリを使いにくくする可能性があるため、適用時には注意してください。

アクティブなアクセシビリティサービスを検出する

現在実行中のアクティブなアクセシビリティサービスがあるかどうかを確認してください。アクセシビリティサービスが存在する場合、この手法を使用してアプリの機能を制限できます。

許可されたアクセシビリティサービスのリストを確認する

有効で実行中のアクセシビリティサービスを取得するためのシステム API が利用可能です。アクセシビリティアプリとその機能の許可リストまたはブロックリストを維持できます。望ましくないアクセシビリティサービスがバックグラウンドで実行されている場合、エンドユーザーに警告する、処理を中止する、またはそれらのサービスを無効にするようエンドユーザーに促すことができます。

ビューへのアクセシビリティアクセスを無効にする

別のアプローチとして、ビューに対するアクセシビリティアクセスを無効にすることができます。これにより、そのビューおよびそのサブビューからのアクセシビリティイベントが防止されます。

private void disableAccessibilityEvent() {
    ViewCompat.setImportantForAccessibility(this, ViewCompat.IMPORTANT_FOR_ACCESSIBILITY_NO_HIDE_DESCENDANTS)
}

EditText ビューからのアクセシビリティイベントの発生を防ぐ

デフォルトでは、システムの EditText はパスワード入力の場合、マスクされる前に入力値を短時間（例えば 1.5 秒）表示します。そのためアクセシビリティサービスは "***1"、"*****3" のようなテキストを受け取る可能性があります。以下のコードスニペットはそのような機密入力値をアクセシビリティアプリから隠す直感的な方法です。

private fun hideLastDigit() {
    transformationMethod = SecureTransformationMethod()
}

class SecureTransformationMethod : PasswordTransformationMethod() {
    override fun getTransformation(source: CharSequence?, view: View?): CharSequence {
        if (source == null) return SecureCharSequence("")
        return SecureCharSequence(source)
    }

    class SecureCharSequence(private val charSequence: CharSequence) : CharSequence {
        override val length: Int
            get() = charSequence.length

        override fun get(index: Int): Char {
            return 'x'
        }

        override fun subSequence(startIndex: Int, endIndex: Int): CharSequence {
            return SecureCharSequence(charSequence.subSequence(startIndex, endIndex))
        }
    }
}

オーバーレイ攻撃を防ぐ

Android のオーバーレイは、あるアプリケーションが別のアプリケーションの上に描画することを可能にします。ユーザー体験を向上させることができますが、フィッシング、権限昇格、データ窃取に濫用される可能性もあります。Android API 9 はタッチイベントに基づいてオーバーレイを検出するためのメソッドを導入しました： onTouch, onFilterTouchEventForSecurity、および setFilterTouchesWhenObscuredです。API 31 以降では、呼び出した各ビューに対して非システムオーバーレイから保護されます（ setHideOverlayWindows(true)）。API レベル 31 未満では、タッチイベントを渡さないオーバーレイに対して依然として脆弱である可能性があります。詳しくは Protecting against Android Overlay Attacks.

を参照してください。

専用キーボードを使用する

PIN、パスワード、または PII のような機密情報の入力にはサードパーティ製キーボードの使用は推奨されません。アプリ専用の専用キーボードを使用することを優先してください。これによりサードパーティ製キーボードによる機密入力の取得リスクが減少します。

専用キーボードが不可能な場合は、カスタマイズされた PIN パッドを優先してください。PIN パッドのレイアウトをシャッフルすることもできます。シャッフルは画面上にランダムなキー配置を生成します。これにより肩越し盗み見やアクセシビリティベースのマルウェア攻撃を軽減できます。

データ保護

通信中のデータ

アプリケーションは TLS 1.2 または TLS 1.3 を使用する必要があります。サーバーを強力な暗号スイートを使用するように構成してください。また、通信中のデータを保護するために次の対策も適用してください：

証明書ピンニングアプリケーションはサーバーとのすべての通信に対して証明書ピンニングを使用するべきです。Android 7.0 以降では、Network Security Configuration を使用してアプリケーションが通信するドメインに対する証明書ピンニングを強制できます。詳細は Network Security Config

を参照してください。

暗号化でデータを保護する

アプリケーションは、個人を特定できる情報（PII）などの機密データをサーバーに送信する際には特に注意を払う必要があります。TLS の保護に加えて機密性と認証を強制することを推奨します。

保存時のデータ アプリケーションは、アプリケーションサンドボックス内に保存されている場合でも機密データを保護する必要があります。特権マルウェアはサンドボックス内のデータにアクセスする可能性があります。機密データを保存する際には機密性、認証、デバイス結び付きのセキュリティ特性を適用してください。Android では、アプリケーションは EncryptedSharedPreference または EncryptedFile を使用してこれらの要件を満たすことができます。詳しくは.

Protecting data at rest

を参照してください。

認証

生体認証を有効にする

アプリケーションはエンドユーザーのログインに生体認証を有効にする必要があります。生体認証を使用する場合、より強固なセキュリティのために Android Keystore と生体認証の暗号オブジェクトベースの認証を使用することを推奨します。これにより生体情報が追加または削除されたときの検出にも役立ちます。

多要素認証を強制する

多要素認証（MFA）の強制は、SDK およびアプリケーションの機密操作を保護するための重要なセキュリティ対策です。MFA は、エンドユーザーが機密機能やデータにアクセスする前に複数の認証方式を提供することを要求することで追加のセキュリティ層を加えます。これにより、エンドユーザーの主要な認証要素が侵害された場合でも不正アクセスのリスクを大幅に低減できます。

暗号ガイドラインセキュリティプロバイダ将来のプラットフォーム暗号プロバイダの脆弱性から保護するために、

Google Play services updated security provider

を使用することを推奨します。

Thales TPC SDK はエンドユーザーに対して更新や通知を行う責任がないため、アプリケーションはエンドユーザーのデバイス上で Google Play services のセキュリティプロバイダが最新であることを確認する必要があります。 安全な乱数生成 アプリケーションは、機密な暗号鍵やその他のランダム値を生成するために常に SecureRandom クラスのメソッドを使用する必要があります。API レベル 29 以降では、アプリ提供のプロバイダの代わりにプラットフォームのデフォルトセキュリティプロバイダを利用するために

SecureRandom.getInstanceStrong()

を使用することを推奨します。

アプリケーションのハードニングルート化デバイスの検出.

アプリケーションを初期化する前および機密操作を実行する前に、ルーティングフレームワークやスーパーユーザーバイナリなどの妥協されたデバイス環境を検出してください。詳しくは

Common Root Detection Methods を参照してください。.

アプリケーションでのフッキングの検出

フッキングはアプリケーションプロセスにペイロードを注入します。攻撃者はこれを使用して暗号鍵や PII のような機密データを傍受したり、セキュリティ機構を調査したり、アプリケーションのフローを変更したりします。アプリケーションはフッキング試行を検出するべきです。詳しくは Hook Detection Methods.

を参照してください。

デバッガーアタッチの検出妥協されたデバイスでは、攻撃者がリリースバリアントのアプリケーションにデバッガーをアタッチすることがあります。これによりネイティブおよび Java/Kotlin バイナリのアプリケーションフローをデバッグできます。特に機密操作を実行する前に、Java/Kotlin とネイティブコードの両方でデバッガーを検出してください。詳しくは.

Debug Detection Methods

を参照してください。エミュレータの検出 Network Security Config

エミュレータは信頼性の低い環境を提供し、動的解析を可能にします。アプリケーション起動時にエミュレータの使用を検出してください。詳しくは

Emulator Detection

を参照してください。

アプリケーション改ざんの検出アプリコードへの悪意ある改ざんを防ぐために、実行時にアプリケーションの署名証明書の署名ハッシュを検証することを推奨します。攻撃者はバイナリやリソースファイルを改ざんして再署名した場合、この署名を複製できません。ただし、バイナリ内の署名証明書ハッシュを改ざんから保護するには強力な難読化が必要です。参照：Application Tamper Detection

さらに、アプリケーションは署名証明書の署名ハッシュをアプリケーションサーバーに送信することもできます。アプリケーションサーバーはクライアントからの追加リクエストを処理する前に、署名ハッシュが設定されたアプリケーションハッシュ値と一致することを検証します。

アプリケーションを難読化するアプリコードへの悪意ある改ざんを防ぐために、実行時にアプリケーションの署名証明書の署名ハッシュを検証することを推奨します。攻撃者はバイナリやリソースファイルを改ざんして再署名した場合、この署名を複製できません。ただし、バイナリ内の署名証明書ハッシュを改ざんから保護するには強力な難読化が必要です。参照：アプリケーションおよびそのすべてのコンポーネントは難読化されるべきです。これにより攻撃者がモバイルアプリケーションをリバースエンジニアリングして使用されているアルゴリズムを解読したり、秘密データを特定したりする難易度が向上します。 Thales TPC SDK はすでに.

DexGuard

を使用して難読化されていますが、バイナリパッケージと共有されたルールを適用して Thales TPC SDK の公開 API をアプリ側で難読化することも重要です。難読化の推奨事項に従い、特に次の点に注意を払うことが極めて重要です：

-flattenpackagehierachy util パッケージ名 'util' を使用することは、難読化の一貫性を確保するために推奨されます。商用の難読化ツールが利用可能です。Android に対する現在の推奨は を使用することです。難読化の詳細については、 Obfuscation Tools and Techniquesを参照してください。

安全なコーディング Android 上で機密データを消去する 暗号鍵、PII、その他の機密エンドユーザーデータなどの機密データはバイト配列として保存してください。Java では

String
や
  StringBuilder
  のようなオブジェクトの基礎となる振る舞いを変更することはできません。また、時間の経過とともにメモリに存在するコピーの数を制御することもできません。
ガベージコレクタに頼るのではなく、機密データを自分で消去することを強く推奨します。例外が発生してもデータが消去されるように、常に
  	finally
  	ブロックを使用してください。以下のコードスニペットのように：
  	byte[] password = this.getUserPassword();
  try {
}

// パスワードを使用してログインする
this.logUserIn(password);
  } finally {
    // ここで例外がキャッチされない場合でも、
  // RuntimeException が発生する可能性があり、それでもこの finally ブロックが実行されるべきです
    MemoryHelper.clearData(password);
  }
}

// バイト配列を消去するメソッドを実装する一つの方法は、MemoryHelper 内で配列の各要素を書き換えることです

class public static void clearData(byte[] baBuffer) {

if (baBuffer == null)

return;

for(i = 0; i < baBuffer.length; i++) {

baBuffer[i] = (byte)0; 安全なコーディング規則 Apple、Google、OWASP（Open Web Application Security Project）などの信頼できるソースから安全なコーディングガイドラインを収集してください。これらのガイドラインにアクセスするために Thales Handset Security Community に問い合わせることもできます。

また、静的コード解析ツール（PMD や HP Fortify など）を使用してこれらのガイドラインを強制することを推奨します。 安全なコーディング規則 Lint ツールを使用する

各機能が完成する前、および最終納品の完了前に、lint を使用してセキュリティ問題を特定して修正してください。

Android ドキュメントは lintを静的コード解析ツールとして説明しています。これはプロジェクトのソースファイルを、正確性、セキュリティ、パフォーマンス、使いやすさ、アクセシビリティ、国際化に関連する潜在的なバグや最適化の機会についてチェックします。.

前へ一般

次へiOS

最終更新 8 か月前

役に立ちましたか？