コンテンツ
- 依存関係を最新に保つ
- 許可リクエストを制限する
- ユーザーに決定させる：アプリセレクターの表示
- 外部ストレージを避ける
- Androidの新しいスコープディレクトリアクセスを使用する
- 機密性の高いユーザーデータをキャッシュしない
- 不正使用からキーを保護する
- ContentProvidersをプライベートにします
- 生体認証でユーザーを指紋認証します
- フォロー すべて ネットワークのベストプラクティス
- 注意してWebViewを使用する
- アプリのSecure Sockets Layer（SSL）を管理します
- ネットワークセキュリティ構成ファイルの作成：カスタムCAの信頼
- 必要に応じて、追加のCAを信頼します
- SMS経由で機密データを送信しない
- SafetyNet APIを使用してセキュリティの脅威から保護する
- 機密性の高いトランザクションにAndroid保護確認を使用する
- Android 10：埋め込みDEXコードを直接実行する
- まとめ
視聴者につかまるつもりなら そして 信頼できるAndroid開発者としての評判を得るには、開発者としてAndroidアプリのセキュリティを真剣に考える必要があります。
アプリが個人データを漏洩した場合、視聴者の大部分が失われる危険があります。今日のハイテクに精通したモバイルユーザーは、安全でないアプリから身を守る最善の方法は、デバイスからアプリを削除することだと理解しています。深刻なデータ侵害もメディアから次第に報告されているため、モバイルセキュリティに対してずさんなアプローチをとると、非常に悪い評判が得られる可能性があります。
リスクは高く、新しい悪意のあるアプリが常にリリースされているため、アプリがデバイスをマルウェアや悪意のあるサードパーティのコードと共有する可能性が増え続けています。
モバイルセキュリティにずさんなアプローチをとると、非常に悪い宣伝になる可能性があります。
ありがたいことに、Androidにはさまざまな組み込みのセキュリティ機能があり、ユーザーのデータをしっかりとロックすることができます。この記事では、Androidプラットフォームに組み込まれているすべての主要なプライバシー機能に加えて、プライベートなアプリケーションデータをプライベートに保つために使用できる追加のツール、テクニック、ベストプラクティスを検討します。
依存関係を最新に保つ
最近のモバイルアプリでは、複数のライブラリ、SDK、その他のさまざまな依存関係を使用することも珍しくありません。これらの依存関係の新しいリリースには、多くの場合、バグ修正、パッチ、その他のセキュリティ機能が含まれているため、アプリの開発中は最新バージョンを使用していることを確認する必要があります。
アプリを展開する前に、更新プログラムが利用できないことを確認するために、最後のチェックを1回行うこともお勧めします。
アプリでGoogle Play開発者サービスを使用している場合、ユーザーのデバイスに最新バージョンがインストールされているかどうかを確認し、必要に応じて更新をトリガーできます。
デバイスのGoogle Play Servicesが最新かどうかをテストするには、ProviderInstallerクラスのinstallIfNeeded（）メソッドを呼び出します。更新が利用可能な場合、このメソッドは認証例外をスローし、ユーザーはデバイスでGoogle Play開発者サービスを更新するように求められます。
許可リクエストを制限する
アプリが許可にアクセスできない場合、その許可に関連付けられている機密データまたは機能を誤って処理する可能性はありません。機密性の高いアクセス許可へのアクセスを制限すると、アプリがハッカーにとって魅力的でないターゲットになる可能性があるため、許可するアクセス許可をできるだけ少なくすることが重要です。
作る前に どれか 許可リクエストの場合、その許可にアクセスせずに同じ結果を達成する方法があるかどうかを検討する必要があります。たとえば、データを保存する必要がある場合、データを外部に保存するのではなく、権限を要求せずにローカルストレージにアクセスできます。これにはWRITE_EXTERNAL_STORAGE権限が必要です。
または、インテントを使用して、必要な許可を既に持っているアプリケーションにタスクを渡すことができる場合があります。たとえば、READ_CONTACTSおよびWRITE_CONTACTS権限を要求する代わりに、連絡先アプリケーションにタスクを委任できます。
インテントcontactIntent = new Intent（Intent.ACTION_INSERT）; contactIntent.setType（ContactsContract.Contacts.CONTENT_TYPE）; if（contactIntent.resolveActivity（getPackageManager（））！= null）{startActivity（contactIntent）; }
また、アプリで不要になった権限を放棄する必要があります。これにより、アプリが一度にアクセスできる機密データや機能の量を大幅に削減できます。
ユーザーに決定させる：アプリセレクターの表示
ホイールを再発明するために時間とエネルギーを無駄にするのはなぜですか？暗黙的な意図により、サードパーティのアプリケーションと連携してタスクを実行でき、アプリの必要な機能をすべて提供するために記述する必要のあるコードの量を削減できます。タスクを別のアプリケーションに渡すことで、アプリに必要な権限の数を減らすこともできます。
暗黙的な意図は時間を大幅に節約できますが、同時に ゼロ どのアプリケーションがリクエストに応答するかを制御します。安全でないまたは悪意のあるサードパーティのアプリが暗黙の意図に答えた場合、ユーザーの個人データを誤ってサードパーティに公開する可能性があります。サードパーティのアプリケーションの結果としてユーザーのプライバシーが侵害された場合、関連付けによってアプリが有罪と見なされる可能性があります。
暗黙的なインテントを発行するときは、可能な限りAndroidのアプリチューザーを表示する必要があります。
この意図に応えることができるすべてのアプリケーションのリストをユーザーに提示することにより、ユーザーが個人的に信頼するアプリケーションを選択する機会が与えられます。すべてのユーザーが賢明に選択できるという保証はありませんが、これにより、信頼できないアプリとデータを共有する可能性を減らすことができます。
インテントを発行する場合、ユーザーがこのインテントを処理できる複数のアプリケーションを持っているかどうかを確認する必要があります。互換性のある複数のアプリが利用可能であると仮定すると、createChooser（）を呼び出してstartActivity（）に渡すことでアプリチューザーを表示できます。
インテントmyIntent = new Intent（Intent.ACTION_SEND）;リスト サービスを開始するために暗黙のインテントを使用しないでください。どのサービスが暗黙のインテントに応答するかを制御することはできません。 ユーザーのデバイスに保存するデータは、他のアプリケーションからアクセスできないことを確認する必要があります-それらのアプリに明示的な承認を許可しない限り。 外部ストレージに保存されたファイルは、グローバルに読み書き可能であるため、外部ストレージに保存したデータは、他のアプリケーションからアクセスおよび変更される可能性があります。外部ストレージメディアが現在のスマートフォンまたはタブレットに接続されたままになるという保証もありません。アプリが外部ストレージに書き込む場合、潜在的に重要なユーザーデータをSDカードに保存している可能性があります。SDカードは後で削除され、誰かのデバイスに挿入されます。外部ストレージを避ける
特別な理由がない限り、データは常に内部ストレージに保存する必要があります。内部ストレージはサンドボックス化されており、デフォルトではアプリからのみアクセス可能です。また、ユーザーがアプリケーションをアンインストールすると、アプリのすべてのファイルが内部ストレージから自動的に削除されるため、機密情報を残すことを心配する必要はありません。
次のスニペットでは、内部ストレージにデータを書き込んでいます：
final String FILE_NAME = "user_data.txt"; String fileContents = "このテキストファイルには、重要なユーザーデータが含まれています"; try（BufferedWriter writer = new BufferedWriter（new FileWriter（new File（getFilesDir（）、FILE_NAME））））{writer.write（fileContents）; } catch（IOException e）{//タスク：例外の処理//}
データが特に重要な場合は、アプリにアクセスできないキー、たとえばキーストアに配置され、保存されていないパスワードで保護されているキーでファイルを暗号化することにより、Androidアプリのセキュリティを追加できますデバイス。
Androidの新しいスコープディレクトリアクセスを使用する
アプリがデバイスの外部ストレージ内の特定のディレクトリへのアクセスを必要とする場合があります。たとえば、デバイスの外部Picturesディレクトリへのアクセスを取得します。
READ_EXTERNAL_STORAGE権限をリクエストすることもできますが、これにより多くの場合、アプリは必要以上のデータにアクセスできます。アプリがアクセスできないデータを誤って処理することは不可能なので、可能な限り、アプリケーションがアクセスできる情報の量を最小限に抑えるようにしてください。
READ_EXTERNAL_STORAGE権限を要求する代わりに、特定のディレクトリへのアクセスを要求できます。この スコープディレクトリアクセス StorageManagerクラスを使用し、そのインスタンスのStorageVolume.createAccessIntent（）メソッドを呼び出してインテントを作成する必要があります。たとえば、次のスニペットでは、外部のピクチャディレクトリにアクセスしています。
StorageManager newStorageManager =（StorageManager）getSystemService（Context.STORAGE_SERVICE）; StorageVolumeボリューム= newStorageManager.getPrimaryStorageVolume（）;インテントインテント= volume.createAccessIntent（Environment.DIRECTORY_PICTURES）; startActivityForResult（intent、request_code）;
ユーザーがアプリにこの外部ディレクトリへのアクセスを許可した場合、Androidは結果コードRESULT_OKとリクエストされたディレクトリのURIを含むインテントを使用してonActivityResult（）オーバーライドを呼び出します。
機密性の高いユーザーデータをキャッシュしない
機密性の低いアプリケーションデータを処理する場合、このデータをデバイスのキャッシュに保存することでユーザーエクスペリエンスを改善できる場合があります。
1 MBを超えるキャッシュの場合、getExternalCacheDir（）を使用できます。これは、キャッシュされたコンテンツを保存できるアプリケーション固有のディレクトリへのパスを返します。
キャッシュすることに決めた場合、WRITE_EXTERNAL_STORAGEパーミッションを持つアプリケーションは潜在的にこれらのファイルに書き込むことができることに注意してください。 決して Androidアプリのセキュリティに関心がある場合は、プライベート情報または機密情報をキャッシュに保存します。
不正使用からキーを保護する
Android Keystoreシステムを使用すると、コンテナ内に暗号化キーを保存できるため、デバイスからこれらのキーを抽出することがより困難になります。
Androidキーストアは、キーマテリアルがアプリケーションプロセスに入らないようにします。したがって、アプリケーションのプロセスが危険にさらされ、攻撃者がキーにアクセスしようとしても、キーマテリアルを抽出できません。
キーストアを使用して、キーをいつどのように使用できるかを制限することもできます。たとえば、キーの使用を特定の暗号化モードに制限したり、ユーザー認証を要求したりできます。
ContentProvidersをプライベートにします
ContentProvidersは構造化されたストレージメカニズムであり、アプリケーションに対してプライベートにしたり、エクスポートを選択したりすると、他のアプリからアクセスできるようになります。
サードパーティのアプリケーションと明示的にデータを共有する必要がない限り、アプリケーションのマニフェストでandroid：exported = falseとしてマークして、すべてのContentProvidersをプライベートにする必要があります。アプリケーションがAndroid 4.1.1以前と互換性がある場合、すべてのContentProviderはデフォルトで公開されているため、プライベートContentProviderをandroid：exported = falseとしてマークすることが特に重要です。
生体認証でユーザーを指紋認証します
ユーザーにアプリの機密情報や機能へのアクセスを許可する前に、資格情報を要求して身元を確認する必要があります。
ユーザー資格情報はPINまたはパスワードの形式をとることができますが、可能な限り、たとえばユーザーの指紋を要求するなどして、生体認証を実行する方がはるかに安全です。
フォロー すべて ネットワークのベストプラクティス
デスクトップコンピューターなどの携帯性の低いデバイスとは異なり、スマートフォンやタブレットを、無料のパブリックWi-Fiなどのセキュリティ保護されていないワイヤレスネットワークに頻繁に接続します。ユーザーのプライバシーを保護するには、すべてのネットワークトランザクションに本質的に危険を伴うアプローチをとる必要があります。 特に ユーザーデータを送信するとき。
ネットワークトランザクションを実行する必要があるときはいつでも、Androidのすべてのネットワークベストプラクティスに従うことが重要です。
- サーバーでサポートされている場合は常に、HTTPではなくHTTPSを使用します。
- HTTPに対して発行された応答を含む、安全でないプロトコルからダウンロードされたデータを信頼しないでください。
- HttpsURLConnectionなどの機密データに適切なプロトコルを使用します。
- 認証が可能な場合は、サービスなどのAndroid IPCメカニズムを使用します。
- オープンソースのNogotofailネットワークセキュリティツールを使用して、既知のTLS / SSLの脆弱性と設定ミスに対してアプリをテストします。 Nogotofailには、一般的なSSL証明書検証の問題、HTTPSおよびTLS / SSLライブラリのバグ、クリアテキストの問題、SSLおよびSTARTTLSの除去の問題のテストが含まれます。詳細については、NogotofailのGitHubページをご覧ください。
- 可能な限り、APKの外部からコードをロードしないでください。送信中にネットワーク上の誰かがコードを変更する可能性が高くなります。
注意してWebViewを使用する
WebViewコンポーネントはHTMLとJavaScriptを消費する可能性があるため、WebViewを誤って使用すると、アプリケーションはクロスサイトスクリプティングなどの一般的なWebセキュリティの問題に対して脆弱になります。
WebViewsを誤って使用すると、アプリケーションは一般的なWebセキュリティの問題に対して脆弱になります。
Androidユーザーを安全に保つために、WebViewコンポーネントはデフォルトではJavaScriptを実行しません。ただし、必要に応じて、getSettings（）を使用してWebSettingsを取得し、setJavaScriptEnabled（）メソッドを実行してJavaScriptを有効にできます。
WebView myWebView =（WebView）findViewById（R.id.webview）; WebSettings webSettings = myWebView.getSettings（）; webSettings.setJavaScriptEnabled（true）;
JavaScriptを有効にする必要がある場合でも、このメソッドは提供されたJavaオブジェクトをWebViewコンポーネントに注入するため、可能な限りaddJavaScriptInterface（）の使用を避ける必要があります。 Android 4.2以前を実行しているデバイスにアプリがインストールされている場合、このメソッドによりJavaScriptがアプリケーションを操作できる可能性があります。
WebViewを使用する場合は、ユーザーが制御できないWebサイトへの移動を許可しないでください。特に、 決して ユーザーが信頼できないWebページに移動する可能性がある場合、addJavascriptInterface（）メソッドを使用します。これは、Androidアプリの大きなセキュリティリスクです。
ユーザーが信頼できないWebページに移動する可能性がある場合は、addJavascriptInterface（）メソッドを使用しないでください。
WebViewコンポーネントが個人データにアクセスする場合、clearCache（）メソッドを使用して、ローカルに保存されているファイルを定期的に削除することができます。または、no-cacheサーバー側ヘッダーを使用して、アプリが機密コンテンツをキャッシュしないようにすることができます。
アプリのSecure Sockets Layer（SSL）を管理します
SSLは、クライアントとサーバー間の暗号化通信の一般的なコンポーネントです。アプリがSSLを誤って使用している場合、悪意のある第三者がネットワーク経由で送信されているアプリケーションのデータを傍受する可能性があります。
通常、サーバーは公開キーと一致する秘密キーを含む証明書で構成されます。 SSLクライアントとサーバー間の通信の一部として、サーバーは公開鍵暗号化を使用して証明書に署名します。ただし、サードパーティが独自の証明書と秘密キーを生成する可能性があるため、クライアントは信頼する1つ以上の証明書も持っている必要があります。証明書が設定されていない場合、アプリケーションはサーバーを信頼できません。
このプロセスを簡単にするために、サーバーはよく知られた認証局（CA）からの証明書で構成されていることがよくあります。 APIレベル17の時点で、Androidは各リリースで更新される100を超えるCAをサポートします。サーバーの証明書を発行する場合、CAは秘密鍵を使用してサーバー証明書に署名します。クライアントは、Androidプラットフォームで認識され信頼されているCAによって証明書が発行されたことを確認できます。
アプリが、信頼できるCAによって発行された証明書を持つWebサーバーと通信している場合、数行のコードでリクエストを行うことができます。
URL url = new URL（ "https://www.google.com"）; HttpsURLConnection urlConnection =（HttpsURLConnection）url.openConnection（）; urlConnection.connect（）; InputStream in = urlConnection.getInputStream（）;
ただし、上記のコードで例外が発生するシナリオがいくつかあります。
- サーバー証明書を発行したCAは不明です。このシナリオでは、このCAのセットを信頼するようにHttpsURLConnectionを教えることができます。
- サーバー証明書は自己署名されています。つまり、サーバーは独自のCAとして機能しています。自己署名証明書の場合、独自のTrustManagerを作成できますが、自己署名証明書に強力なキーがあることを確認する必要があります。
- サーバー構成に中間CAがありません。多くの公開CAは、サーバー証明書に直接署名しません。 AndroidはルートCAのみを信頼するため、サーバーはルートに到達するために必要な中間体を介してサーバーCAから証明書のチェーンを送信する必要があります。サーバーチェーンに中間CAを含めるようにサーバーを構成できない場合、考えられる回避策の1つは、独自のTrustManagerを作成することです。
ネットワークセキュリティ構成ファイルの作成：カスタムCAの信頼
アプリで新しいCAまたはカスタムCAを使用する場合は、ネットワークセキュリティ設定を指定するネットワークセキュリティ構成ファイルを作成する必要があります。
ネットワークセキュリティ構成ファイルを作成するには：
- プロジェクトにXMLフォルダーがまだ含まれていない場合は、作成する必要があります。 Controlキーを押しながらプロジェクトのresフォルダーをクリックし、[新規]> [Androidリソースディレクトリ]を選択します。
- XMLディレクトリ内に新しいXMLリソースファイルを作成します。これは、ネットワークセキュリティ構成ファイルとして機能します。このファイルにnetwork_configという名前を付けています。
- ネットワーク構成ファイルを開き、次のドメインへのすべてのトラフィックがHTTPSを使用するように指定します。
これで、アプリケーションが信頼するカスタムCAのセットを指定できます。たとえば、自己署名CAを使用するホストに接続する場合、次をネットワークセキュリティ構成ファイルに追加します。
マニフェストでネットワークセキュリティ構成ファイルを宣言することを忘れないでください。
その後、信頼できるCAをプロジェクトのres / raw / trusted_casにPEMまたはDER形式で追加する必要があります。 最後に、Androidプラットフォームで認識されていない追加のCAを信頼することもできます。アプリケーションが信頼するCAの数を増やすには、複数の証明書ソースを指定する必要があります。 サーバーからアプリケーションにデータを送信する必要がある場合は、Googleクラウドメッセージング（GCM）とIPメッセージングを使用し、暗号化されていないSMSプロトコルは使用しないでください。 必要に応じて、追加のCAを信頼します
SMS経由で機密データを送信しない
また読む： Android開発：電話のかけ方、SMSの受信、ユーザーの連絡先の取得方法
また、SMSはブロードキャストインテントとして送信されるため、SMSを使用して機密性の高いコマンドを実行しないでください。つまり、READ_SMS権限を持つアプリケーションはコンテンツにアクセスできます。
SafetyNet APIを使用してセキュリティの脅威から保護する
SafetyNetは、デバイスの改ざん、悪意のあるURL、偽のユーザーなどのセキュリティの脅威からアプリを保護するために使用できる一連のサービスとAPIを提供します。
Androidは次のSafetyNet APIをサポートしています。
- SafetyNet認証API。この不正防止APIを使用すると、アプリケーションが実行されているAndroidデバイスにアクセスできるため、サーバーが純正デバイスと対話しているかどうかを判断できます。
- SafetyNetセーフブラウジングAPI。このAPIを使用して、Googleが特定のURLを既知の脅威として分類したかどうかを判断できます。
- SafetyNet reCAPTCHA API。このサービスには、スパムや悪意のあるトラフィックなどの脅威からアプリを保護するために使用できるreCAPTCHA APIが含まれています。アプリがボットと対話しているとAPIが疑う場合、CAPTCHAを提供し、受信者がアプリを使用し続ける前に解決する必要があります。
- SafetyNet Verify Apps API。アプリに機密性の高いユーザーデータが含まれている場合、このAPIを使用してデバイスのアプリの検証機能を操作し、デバイスに悪意のあるアプリケーションがないかどうかを確認できます。デバイスが安全でない場合は、アプリの機密機能をすべて無効にすることで、何らかの損害制限を実行できます。 SafetyNetは、検出した潜在的に有害なアプリをユーザーに警告しますが、ユーザーがこれらのアプリを実際にアンインストールする保証はありません。さらに、悪意のあるアプリは常にリリースされており、ハッカーは常に新しい巧妙な方法でレーダーの下に潜り込んでいます。そのため、デバイスがSafetyNetテストに合格したとしても、有害なアプリが存在しないと想定すべきではありませんデバイス。
アプリでの使用方法など、SafetyNet APIの詳細については、公式のAndroidドキュメントをご覧ください。
機密性の高いトランザクションにAndroid保護確認を使用する
アプリで支払いなどの機密性の高いトランザクションを実行する必要がある場合は、Android 9（APIレベル28）以上を実行しているデバイスでAndroid保護確認を使用できます。
ユーザーが機密性の高いトランザクションを完了しようとするたびに、Android保護された確認は、短いステートメントを受け入れるように求めるプロンプトを表示します。ユーザーがこのステートメントを承認した場合、Androidキーストアのキーを使用して署名できます。
詳細と、Android保護された確認の実装方法については、公式のAndroidドキュメントをご覧ください。
Android 10：埋め込みDEXコードを直接実行する
Android 10（APIレベル29）以降を実行しているデバイスでは、アプリのAPKファイルから埋め込みDEXコードを直接実行できます。これにより、ハッカーがローカルでコンパイルされたデバイスのコードを改ざんした場合でも攻撃を防ぐことができます。
また読む： Android Qの探索：アプリにバブル通知を追加する
この新しいセキュリティ機能を有効にするには、プロジェクトのマニフェストを開き、次の要素を要素に追加します。
次に、ARTが直接アクセスできる非圧縮DEXコードを含むAPKファイルを作成する必要があります。 build.gradleファイルを開き、次を追加します。 aaptOptions {noCompress dex} ARTがアプリの起動時にJITコンパイラを使用することに注意してください。これは、アプリケーションのパフォーマンスに影響を与える可能性があります。 この記事では、Androidアプリのセキュリティを維持するために使用できるすべてのベストプラクティス、ツール、API、およびテクニックについて説明しました。 アプリケーションのセキュリティを高めるためのアドバイスはありますか？以下のコメントでヒントを共有してください！まとめ
