ディープリンクの不正使用
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
OWASP カテゴリ: MASVS-PLATFORM: プラットフォームのインタラクション
概要
ディープリンクに関連するセキュリティ リスクは、モバイルアプリ内でシームレスなナビゲーションと操作を可能にするコア機能に起因しています。ディープリンクの脆弱性は、ディープリンクの実装または処理における弱点から発生します。こうした欠陥は、悪意のある攻撃者が悪用して特権機能やデータにアクセスし、データ侵害、プライバシー侵害、不正行為につながる可能性があります。攻撃者は、ディープリンク ハイジャックやデータ検証攻撃など、さまざまな手法によってこの脆弱性を悪用できます。
影響
適切なディープリンク検証メカニズムがない、またはディープリンクが安全でない状態で使用されていないと、悪意のあるユーザーが脆弱性のあるアプリケーションの権限コンテキスト内でホスト検証バイパス、クロスアプリ スクリプティング、リモートコード実行などの攻撃を実行するおそれがあります。アプリケーションの性質によっては、機密データや機能への不正アクセスにつながる可能性があります。
リスクの軽減
ディープリンクの不正使用を防ぐ
Android では、複数のアプリが同じディープリンク URI のインテント フィルタを登録できるように設計されています。悪意のあるアプリがアプリ向けのディープリンクをインターセプトしないようにするには、アプリケーションの AndroidManifest
内の intent-filter
に android:autoVerify
属性を実装します。これにより、ユーザーはディープリンクの処理に使用するアプリを選択できるため、意図した操作を確実に実行し、悪意のあるアプリがディープリンクを自動的に解釈するのを防ぐことができます。
Android 12 では、セキュリティを強化するために、ウェブ インテントの厳格な処理が導入されました。アプリは、Android アプリリンクまたはシステム設定でのユーザー選択のいずれかを通じて、特定のドメインからのリンクを処理するように検証する必要があります。これにより、アプリが処理すべきでないリンクをハイジャックするのを防ぐことができます。
アプリのリンク処理の検証を有効にするには、次の形式に一致するインテント フィルタを追加します(この例は、Android アプリリンクを検証するのドキュメントから抜粋したものです)。
<!-- Make sure you explicitly set android:autoVerify to "true". -->
<intent-filter android:autoVerify="true">
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<!-- If a user clicks on a shared link that uses the "http" scheme, your
app should be able to delegate that traffic to "https". -->
<data android:scheme="http" />
<data android:scheme="https" />
<!-- Include one or more domains that should be verified. -->
<data android:host="..." />
</intent-filter>
堅牢なデータ検証を実装する
ディープリンクには、さらなるアクションの実行など、ターゲット インテントに提供される追加のパラメータを含めることができます。安全なディープリンク処理の基盤は、厳格なデータ検証です。悪意のあるコードや値が正当なアプリに挿入されないように、ディープリンクからの受信データはすべて、デベロッパーが慎重に検証してサニタイズする必要があります。これは、ディープリンク パラメータの値を、想定される値のあらかじめ定義された許可リストと照合することで実装できます。
アプリは、機密情報を公開する前に、認証状態や認可など、その他の関連する内部状態を確認する必要があります。たとえば、ゲームのレベルをクリアしたときに報酬が得られる場合があります。この場合、レベルを完了しているという前提条件を検証し、完了していない場合はメイン画面にリダイレクトすることをおすすめします。
リソース
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-26 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-07-26 UTC。"],[],[],null,["# Unsafe use of deep links\n\n\u003cbr /\u003e\n\n**OWASP category:** [MASVS-PLATFORM: Platform Interaction](https://mas.owasp.org/MASVS/09-MASVS-PLATFORM)\n\nOverview\n--------\n\nThe security risks associated with deep links stem from their core capability of\nenabling seamless navigation and interaction within mobile applications. Deep\nlink vulnerabilities arise from weaknesses in the implementation or handling of\ndeep links. These flaws can be exploited by malicious actors to gain access to\nprivileged functions or data, potentially resulting in data breaches, privacy\nviolations, and unauthorized actions. Attackers can exploit these\nvulnerabilities through various techniques, such as deep link hijacking and data\nvalidation attacks.\n\nImpact\n------\n\nThe lack of a proper deep link validation mechanism, or the unsafe use of\ndeeplinks, can aid malicious users in performing attacks such as host validation\nbypass, cross-app scripting, and remote code execution within the permissions\ncontext of the vulnerable application. Depending on the nature of the\napplication, this can result in unauthorized access to sensitive data or\nfunctions.\n\nMitigations\n-----------\n\n### Prevent deep link hijacking\n\nBy design, Android allows multiple apps to register intent filters for the same\ndeep link URI. To prevent malicious apps from intercepting deep links intended\nfor your app, implement the `android:autoVerify` attribute in `intent-filter`\nwithin the application's `AndroidManifest`. This allows users to select their\npreferred app for handling deep links, ensuring the intended operation and\npreventing malicious applications from automatically interpreting them.\n\nAndroid 12 [introduced](/about/versions/12/behavior-changes-all#web-intent-resolution) stricter handling of web intents to improve security.\nApps must now be verified to handle links from specific domains, either through\nAndroid App Links or user selection in system settings. This prevents apps from\nhijacking links they shouldn't handle.\n\nTo enable link handling verification for your app, add intent filters that match\nthe following format (this example is taken from the [Verify Android App\nLinks](/training/app-links/verify-android-applinks) documentation): \n\n \u003c!-- Make sure you explicitly set android:autoVerify to \"true\". --\u003e\n \u003cintent-filter android:autoVerify=\"true\"\u003e\n \u003caction android:name=\"android.intent.action.VIEW\" /\u003e\n \u003ccategory android:name=\"android.intent.category.DEFAULT\" /\u003e\n \u003ccategory android:name=\"android.intent.category.BROWSABLE\" /\u003e\n \n \u003c!-- If a user clicks on a shared link that uses the \"http\" scheme, your\n app should be able to delegate that traffic to \"https\". --\u003e\n \u003cdata android:scheme=\"http\" /\u003e\n \u003cdata android:scheme=\"https\" /\u003e\n \n \u003c!-- Include one or more domains that should be verified. --\u003e\n \u003cdata android:host=\"...\" /\u003e\n \u003c/intent-filter\u003e\n\n### Implement robust data validation\n\nDeep links can include additional parameters that are served to the target\nintent, for example, to perform further actions. The foundation of secure deep\nlink handling is stringent data validation. All incoming data from deep links\nshould be meticulously validated and sanitized by developers to prevent\nmalicious code or values from being injected within the legitimate application.\nThis can be implemented by checking the value of any deep link parameter against\na predefined allowlist of expected values.\n\nApps should check other relevant internal states, such as authentication state,\nor authorization, before exposing sensitive information. An example might be a\nreward for completing a level of a game. In this case it's worth validating the\nprecondition of having completed the level, and redirecting to the main screen\nif not.\n\nResources\n---------\n\n- [Verify Android App Links](/training/app-links/verify-android-applinks)\n- [Handling Android App Links](/training/app-links)\n- [Web intent resolution](/about/versions/12/behavior-changes-all#web-intent-resolution)\n- [Account takeover intercepting magic link for Arrive app](https://hackerone.com/reports/855618)\n- [Deep Links \\& WebViews Exploitations Part I](https://www.justmobilesec.com/en/blog/deep-links-webviews-exploitations-part-I)\n- [Deep Links \\& WebViews Exploitations Part II](https://www.justmobilesec.com/en/blog/deep-links-webviews-exploitations-part-II)\n- [Recent suggestion of a deep link issue in Jetpack Navigation](https://swarm.ptsecurity.com/android-jetpack-navigation-go-even-deeper/)"]]