セキュアコーディングのテクニックカスタムパーミッションの問題
モバイル向けに開発する場合、アプリケーションはしばしばシステムに何らかの許可を要求しなければなりません。例えば、ユーザーの連絡先へのアクセスや、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
アプリケーション・セキュリティ・リサーチャー、R&Dエンジニア、博士号取得者
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
アプリケーション・セキュリティ・リサーチャー、R&Dエンジニア、博士号取得者
モバイル向けに開発する場合、アプリケーションはしばしばシステムに何らかの許可を要求しなければなりません。例えば、ユーザーの連絡先へのアクセスや、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
モバイル向けに開発する場合、アプリケーションはしばしばシステムに何らかの許可を要求しなければなりません。例えば、ユーザーの連絡先へのアクセスや、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
モバイル向けに開発する場合、アプリケーションはしばしばシステムに何らかの許可を要求しなければなりません。例えば、ユーザーの連絡先へのアクセスや、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
始めるためのリソース
OpenText アプリケーションセキュリティのパワー + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
セキュアコード・トレーニングのトピックと内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
始めるためのリソース
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
