Android

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

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

アプリケーションが公式の Google Play ストアを通じて配布されていることを確認するために、インストーラのパッケージ名が com.android.vending であることを検証するべきです。これにより、サイドチャネル経由の配布やサードパーティのソースからの不正なインストールを防止できます。

アプリの強制アップデート

Play ストアでアプリケーションのセキュリティアップデートが利用可能な場合、エンドユーザーがサービスを継続して使用する前にアプリがアップデートを強制するべきです。これにより、エンドユーザーが常に必要なセキュリティ修正を含む最新バージョンのアプリを使用することが保証されます。

アプリリソースは内部ストレージのみに保存する

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

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

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

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

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

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

過剰な権限を防ぐ

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

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

Android アプリケーションは次のいずれか、または複数のコンポーネントで構成されます：

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

これらの各コンポーネントを使用する際には、考えられるリスクや関連する攻撃に注意してください。一般的に、アプリ間通信はリスクがあります。モバイルアプリケーションはメインのアクティビティのみを公開し、他のすべてのコンポーネントには明示的に属性を持たせる設計を検討してください。 export=false。他のコンポーネントを公開する場合は、カスタム権限で保護することを検討してください。

リリースビルドでアプリのデバッグを無効にする

デバッグモードを削除するには、明示的に android:debuggable を設定する必要があります。 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.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.apk
v1 スキーム（JAR 署名）で検証済み: true
v2 スキーム（APK Signature Scheme v2）で検証済み: true v3 スキーム（APK Signature Scheme v3）で検証済み: true 署名者数: 1

アプリデータのバックアップを防ぐ

アプリデータのバックアップを防ぐには、アプリケーションタグの allowBackup 属性を設定します。 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（Android 2）ではタッチイベントに基づいてオーバーレイを検出するための 3 つの有用なメソッドが追加されました。, onTouchonFilterTouchEventForSecurity , および setFilterTouchesWhenObscured メソッドは API 9 以降で利用可能で、覆い隠されたタッチイベントを検出するために使用できます。API 31 以降では、setHideOverlayWindows(true) API が呼び出されたすべてのビューに対して、すべての非システムオーバーレイから完全に保護されます。ただし、API 31 未満の任意の API はタッチイベントを通さないオーバーレイに対して脆弱である可能性があります。詳細は 「Protecting against Android Overlay Attacks」を参照してください。.

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

ユーザーの PIN、パスワード、または個人識別情報（PII）などの機密情報を入力する際にサードパーティ製のキーボードを使用することは推奨されません。モバイルアプリケーション専用の専有キーボードを使用することが望ましいです。これにより、サードパーティのキーボードがエンドユーザーの機密入力を記録するのを防げます。

専用キーボードが不可能な場合は、パスコード用のカスタマイズされた PIN パッドを使用することが望ましいです。PIN パッドのランダムスクランブルも実装できます。PIN パッドのスクランブルは、表示上のキーのレイアウトをランダムに生成することで機能します。これにより、肩越し覗き（ショルダサーフィング）やアクセシビリティマルウェアによる攻撃を軽減できます。

データ保護

送信中のデータ

アプリケーションは TLS 1.2 または TLS 1.3 を使用する必要があります。サーバーは強力な暗号スイートを使用するよう設定されます。さらに、以下の方法が送信中のデータ保護に使用されるべきです：

証明書ピンニング

アプリケーションはサーバーとのすべての通信に対して証明書ピンニングを採用します。Android v7.0 以降では、Network Security 設定を使用して通信するすべてのドメインに対して証明書ピンニングを強制できます。詳細は Network Security Config を参照してください。

暗号化によるデータ保護

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

保存中のデータ

アプリケーションは、アプリケーションサンドボックス内に保存されている場合であっても機密データを保護する必要があります。特権を持つマルウェアは、サンドボックス内に保存された機密データにアクセスする可能性があります。アプリケーションは機密データを保存する際に機密性、認証、およびデバイス結びつきのセキュリティ特性を強制する必要があります。Android では、アプリケーションは EncryptedSharedPreference または EncryptedFile を利用できます。これらはアプリケーションサンドボックスに保存する前に機密データを扱うために必要なすべてのセキュリティ特性を満たします。保存中のデータの保護方法の詳細は、 Protecting data at rest.

を参照してください。

認証

生体認証を有効にする

アプリケーションはエンドユーザーのログインに生体認証を有効にする必要があります。生体認証を使用する場合、Android Keystore と Biometric Crypto オブジェクトに基づく認証を利用することを推奨します。これにより、より高いセキュリティが提供され、また生体認証の追加や削除が検出されることが保証されます。

多要素認証を強制する

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

暗号化に関するガイドライン

セキュリティプロバイダ将来のプラットフォーム暗号プロバイダの脆弱性に動的に対処するために、 Google Play services updated security provider

の使用を推奨します。

Thales SDK は Google Play サービスのセキュリティプロバイダを更新したり、エンドユーザーにインストールや更新を通知する責任を負わないため、アプリケーション側でエンドユーザーのデバイス上のこの Google Play サービスセキュリティプロバイダが更新されていることを確実にする必要があります。

安全な乱数生成 アプリケーションはあらゆる機密暗号キーやランダムデータ生成に対して常に SecureRandom クラスのメソッドを使用する必要があります。API レベル 29 以降では、アプリケーション提供のセキュリティプロバイダの代わりにプラットフォームのデフォルトセキュリティプロバイダを使用するために、 SecureRandom.getInstanceStrong()

API の使用が推奨されます。

アプリのハードニング

ルート化されたデバイスを検出するアプリケーションはアプリの初期化前および機密操作を行う前に、ルーティングフレームワークやスーパーユーザーバイナリなどの破損したデバイス環境を検出します。包括的なルート検出の詳細は、.

Common Root Detection Methods

を参照してください。アプリへのフッキングを検出する.

フッキングは、暗号鍵や PII データなどの機密データを傍受したり、アプリのセキュリティメカニズムを把握したり、アプリの動作を変更したりする目的で、アプリケーションプロセスのコンテキスト内で実行されるペイロードを注入するプロセスです。したがって、アプリケーションはフッキングの試みを検出する努力をすべきです。フック検出の方法の詳細は、

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

デバッガのアタッチを検出する

破損したデバイスでは、リリースバリアントのアプリにデバッガがアタッチされる可能性があります。デバッガを使用すると、攻撃者はネイティブおよび Java/Kotlin バイナリの両方のアプリのフローをデバッグできます。特に機密処理を実行する前に、Java/Kotlin およびネイティブバイナリでデバッガを検出することが重要です。デバッガ検出に関する詳細は、 Debug Detection Methods.

を参照してください。

エミュレータを検出するエミュレータはアプリを実行する際に破損した環境を提供し、攻撃者がさまざまな動的解析を行うことを可能にします。アプリの非常に早い段階でエミュレータを検出することを推奨します。エミュレータ検出の詳細は、を参照してください。

Emulator Detection

を参照してください。

アプリ改ざんを検出する

アプリのコードへの不正アクセスを防ぐために、実行時にアプリの署名証明書の署名ハッシュを検証することを推奨します。攻撃者がバイナリやリソースファイルを改ざんした後に再署名しても、この署名は再現できません。ただし、バイナリ内の署名証明書ハッシュを改変から保護するためには強力な難読化が必要です。詳細は、 Application Tamper Detectionを参照してください。

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

アプリを難読化する Application Tamper Detectionアプリケーションとそのすべてのコンポーネントは難読化されるべきです。これにより、攻撃者がモバイルアプリをリバースエンジニアリングして使用アルゴリズムを解読したり、機密データを特定したりする難易度が上がります。 Thales SDK は既に.

DexGuard

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

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

安全なコーディング Android 上での機密データの消去 暗号鍵、PII、その他のユーザー機密情報などのすべての機密データはバイト配列に格納する必要があります。Java では、String や StringBuilder のようなオブジェクトの基礎データ構造の挙動を変更することはできず、メモリ内で何回データのコピーが作られるか、時間経過でそれらに何が起きるかを制御できません。

ガベージコレクタに依存するのではなく、機密データは自分で消去することを強く推奨します。例外が実行フローを抜ける可能性があることを防ぐために、catch ブロックが使用されていない場合でも機密データを消去するために必ず finally ブロックを使用してください。以下のコードスニペットのように：
byte[] password = this.getUserPassword();
  try {
  // パスワードを使用してログインする
this.logUserIn(password);
  	} finally {
  	// ここに例外キャッチがなくても、RuntimeException が発生してこの finally ブロックが実行される可能性があります
  	//
  MemoryHelper.clearData(password);
}

// バイト配列消去メソッドを実装する 1 つの方法は、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 は Android プロジェクトのソースファイルを潜在的なバグや最適化の改善点について、正確性、セキュリティ、パフォーマンス、ユーザビリティ、アクセシビリティ、および国際化の観点でチェックする静的コード解析ツールです。

lint が実行するチェックの完全な一覧は、 lint から Android 開発者サイトで参照できます。

一般的な Android セキュリティのヒント

Android が提供するセキュリティ機能や技術を把握し、従うことを推奨します。詳細は、 Android Security Tips.

前へ一般

次へiOS

最終更新 9 か月前

役に立ちましたか？