セキュアコーディングのテクニックカスタムパーミッションの問題

2017年10月25日発行
ピーテル・デ・クレマー著
ケーススタディ

セキュアコーディングのテクニックカスタムパーミッションの問題

2017年10月25日発行
ピーテル・デ・クレマー著
リソースを見る
リソースを見る

モバイル向けに開発する場合、アプリケーションはしばしばシステムに何らかの許可を要求しなければなりません。例えば、ユーザーの連絡先へのアクセスや、Bluetooth接続、SMSメッセージの送信などがあります。上述の許可はすべて、Androidフレームワークによって定義されたプラットフォーム許可です。

しかし、これらでは十分ではなく、アプリケーションが独自のカスタムパーミッションを定義する必要がある場合もあります。Secure Code Warrior は、SCWプラットフォーム上でのユーザのパフォーマンスなどのプライベートデータをプロファイルの一部として保存するアプリを作成します。そして、別のセキュリティトレーニングアプリ(例えばDevTrainer)が、ユーザから許可を得た場合に、このデータを使用することを許可したいと思います。これはセンシティブなデータで、ユーザは誰にも知られたくないと思っていますが、SCWAppはそれが有用であるかもしれないので、完全に隠して保護するべきではありません。そのため、ユーザがコントロールできるようにしたいと考えています。ここでカスタムパーミッションの出番です。

SCWAppがカスタムパーミッションを作成し、DevTrainerがこのパーミッションを要求し、ユーザはこれを許可するかどうかを決めることができます。これは一般的な方法で、ホワイトリストに登録されたアプリケーションへのアクセスを制限するのに適した方法です。

残念ながら、カスタムパーミッションには直感的に理解できない動作があり、セキュリティの観点からは危険なものとなっています。具体的には、カスタムパーミッションはどのアプリでもいつでも定義することができ、「先に手を打った者勝ち」となりますが、この戦略にはいくつかの結果が伴います。

以下のシナリオでは、上記で紹介した2つのアプリのプロファイルを定義します(これらのアプリはすべて、デモンストレーションのための架空のものです)。

1. SCWApp: カスタムパーミッションを定義し、そのパーミッションを使用してコンポーネントを防御するアプリです。

2.DevTrainer: このアプリはSCWAppと同じパーミッションを定義し、このパーミッションを保持することをユーザに宣言します。

これは「Peer Apps Case」と呼ばれる一般的なシナリオです。もし、DevTrainerアプリがSCWAppの単なるプラグインであれば、カスタムパーミッションを定義する必要はありません。このケースでは、SCWAppがDevTrainerより先にインストールされ、予期せぬ動作が起こらないことが前提となっています。何らかの方法でユーザがDevTrainerを先にインストールした場合、ユーザにはパーミッションの要求について知らされません。ユーザーが後からSCWAppをインストールした場合、DevTrainerには遡って許可が与えられないため、DevTrainerアプリが保護されたコンポーネントを使用しようとしても失敗します。

ここで登場するのが「Peers App Case」です。場合によっては、一方のアプリが他方のアプリより先にインストールされることを期待できないことがあります。例えば、FacebookとTwitterがお互いのコンポーネントを使用したい場合、お互いのカスタムパーミッションを定義しなければなりません。

しかし、ここからが厄介なのです。DevTrainerアプリが最初にインストールされた場合、ユーザにはカスタム・パーミッションの要求について通知されません。この時点では、ユーザに知らされていないにもかかわらず、DevTrainerはカスタムパーミッションを保持しており、セキュリティで保護されたコンポーネントにアクセスすることができます。

さらにやっかいなことになります。DevTrainerアプリは、パーミッションの保護レベルを変更することができます。Androidは防御側の保護レベルではなく、最初に定義された保護レベルを使用します。つまり、最初にインストールされたアプリが定義できるのです。つまり、DevTrainerがパーミッションレベルを通常に変更した場合、今後このパーミッションを要求するアプリは、ユーザーによる確認を必要とせず、自動的にアクセスが許可されることになります。

このシナリオは、cwac-securityのgithubにあるこの問題の説明からヒントを得ました。

先手必勝」戦略には危険な結果をもたらすものがあり、その動作を知らないと、開発者は信頼できない入力に基づいてセキュリティ上の判断を下し、意図しないアプリに機密データや保護されたサービスへのアクセスを許してしまう可能性があります。信頼できない入力によるセキュリティ上の判断を避けるための詳細については、当社のプラットフォームをご覧ください。この動作は、Android 5.0(Lollipop)で変更されました。しかし、現在、22%以上のAndroidデバイスがまだ低バージョンのAndroidを実行しているため、アプリで元の動作のリスクを軽減することが重要です。アプリの初回実行時にすでにパーミッションが定義されているかどうかを確認し、その場合は適切な対処をしてセキュリティリスクを解決してください。

頑張ってコーディングして、また来週お会いしましょう

カスタムパーミッションを定義することで、アプリはそのリソースや機能を他のアプリと共有することができます。

https://developer.android.com/guide/topics/permissions/defining.html

リソースを見る
リソースを見る

著者

ピーテル・デ・クレマー

もっと知りたい?

セキュアコーディングに関する最新の知見をブログでご紹介しています。

当社の豊富なリソースライブラリは、安全なコーディングアップスキルに対する人間的なアプローチを強化することを目的としています。

ブログを見る
もっと知りたい?

開発者主導のセキュリティに関する最新の研究成果を入手する

ホワイトペーパーからウェビナーまで、開発者主導のセキュアコーディングを始めるために役立つリソースが満載のリソースライブラリです。今すぐご覧ください。

リソース・ハブ

セキュアコーディングのテクニックカスタムパーミッションの問題

2017年10月25日発行
Pieter De Cremer 著

モバイル向けに開発する場合、アプリケーションはしばしばシステムに何らかの許可を要求しなければなりません。例えば、ユーザーの連絡先へのアクセスや、Bluetooth接続、SMSメッセージの送信などがあります。上述の許可はすべて、Androidフレームワークによって定義されたプラットフォーム許可です。

しかし、これらでは十分ではなく、アプリケーションが独自のカスタムパーミッションを定義する必要がある場合もあります。Secure Code Warrior は、SCWプラットフォーム上でのユーザのパフォーマンスなどのプライベートデータをプロファイルの一部として保存するアプリを作成します。そして、別のセキュリティトレーニングアプリ(例えばDevTrainer)が、ユーザから許可を得た場合に、このデータを使用することを許可したいと思います。これはセンシティブなデータで、ユーザは誰にも知られたくないと思っていますが、SCWAppはそれが有用であるかもしれないので、完全に隠して保護するべきではありません。そのため、ユーザがコントロールできるようにしたいと考えています。ここでカスタムパーミッションの出番です。

SCWAppがカスタムパーミッションを作成し、DevTrainerがこのパーミッションを要求し、ユーザはこれを許可するかどうかを決めることができます。これは一般的な方法で、ホワイトリストに登録されたアプリケーションへのアクセスを制限するのに適した方法です。

残念ながら、カスタムパーミッションには直感的に理解できない動作があり、セキュリティの観点からは危険なものとなっています。具体的には、カスタムパーミッションはどのアプリでもいつでも定義することができ、「先に手を打った者勝ち」となりますが、この戦略にはいくつかの結果が伴います。

以下のシナリオでは、上記で紹介した2つのアプリのプロファイルを定義します(これらのアプリはすべて、デモンストレーションのための架空のものです)。

1. SCWApp: カスタムパーミッションを定義し、そのパーミッションを使用してコンポーネントを防御するアプリです。

2.DevTrainer: このアプリはSCWAppと同じパーミッションを定義し、このパーミッションを保持することをユーザに宣言します。

これは「Peer Apps Case」と呼ばれる一般的なシナリオです。もし、DevTrainerアプリがSCWAppの単なるプラグインであれば、カスタムパーミッションを定義する必要はありません。このケースでは、SCWAppがDevTrainerより先にインストールされ、予期せぬ動作が起こらないことが前提となっています。何らかの方法でユーザがDevTrainerを先にインストールした場合、ユーザにはパーミッションの要求について知らされません。ユーザーが後からSCWAppをインストールした場合、DevTrainerには遡って許可が与えられないため、DevTrainerアプリが保護されたコンポーネントを使用しようとしても失敗します。

ここで登場するのが「Peers App Case」です。場合によっては、一方のアプリが他方のアプリより先にインストールされることを期待できないことがあります。例えば、FacebookとTwitterがお互いのコンポーネントを使用したい場合、お互いのカスタムパーミッションを定義しなければなりません。

しかし、ここからが厄介なのです。DevTrainerアプリが最初にインストールされた場合、ユーザにはカスタム・パーミッションの要求について通知されません。この時点では、ユーザに知らされていないにもかかわらず、DevTrainerはカスタムパーミッションを保持しており、セキュリティで保護されたコンポーネントにアクセスすることができます。

さらにやっかいなことになります。DevTrainerアプリは、パーミッションの保護レベルを変更することができます。Androidは防御側の保護レベルではなく、最初に定義された保護レベルを使用します。つまり、最初にインストールされたアプリが定義できるのです。つまり、DevTrainerがパーミッションレベルを通常に変更した場合、今後このパーミッションを要求するアプリは、ユーザーによる確認を必要とせず、自動的にアクセスが許可されることになります。

このシナリオは、cwac-securityのgithubにあるこの問題の説明からヒントを得ました。

先手必勝」戦略には危険な結果をもたらすものがあり、その動作を知らないと、開発者は信頼できない入力に基づいてセキュリティ上の判断を下し、意図しないアプリに機密データや保護されたサービスへのアクセスを許してしまう可能性があります。信頼できない入力によるセキュリティ上の判断を避けるための詳細については、当社のプラットフォームをご覧ください。この動作は、Android 5.0(Lollipop)で変更されました。しかし、現在、22%以上のAndroidデバイスがまだ低バージョンのAndroidを実行しているため、アプリで元の動作のリスクを軽減することが重要です。アプリの初回実行時にすでにパーミッションが定義されているかどうかを確認し、その場合は適切な対処をしてセキュリティリスクを解決してください。

頑張ってコーディングして、また来週お会いしましょう

カスタムパーミッションを定義することで、アプリはそのリソースや機能を他のアプリと共有することができます。

https://developer.android.com/guide/topics/permissions/defining.html

弊社製品や関連するセキュアコーディングのトピックに関する情報をお送りする許可をお願いします。当社は、お客様の個人情報を細心の注意を払って取り扱い、マーケティング目的で他社に販売することは決してありません。

フォームを送信するには、「Analytics」のCookieを有効にしてください。完了したら、再度無効にしてください。