Hello there, ('ω')ノ
🎯 目標：外部アプリやadbコマンドを使って、本来内部用の画面を強制的に起動する
たとえば、本来はログイン後しか見られない「管理者用の設定画面」などを、認証なしで起動できてしまう場合、これは重大な設計ミスです。
🧰 事前準備
✅ 必要な環境
- 実機またはエミュレータ（USBデバッグが有効になっていること）
adbコマンドが使えるPC（Android SDK Platform Toolsがインストールされている）- 対象アプリのパッケージ名とアクティビティ名（
com.example.app/.AdminActivityなど）
✅ 例：確認したいアクティビティ情報の確認
Drozer や adb の dumpsys コマンドを使って、対象アプリの構成情報を調べておきます：
adb shell dumpsys package com.example.app | grep Activity
🔍 ステップ①：Manifestファイルの確認（静的解析）
まずは対象アプリの AndroidManifest.xml を調査します（MobSF や jadx を使うと便利です）。
<activity android:name=".AdminActivity" android:exported="true" android:label="Admin"> <intent-filter> <action android:name="android.intent.action.VIEW" /> </intent-filter> </activity>
このように exported="true" で、インテントフィルターも定義されていれば、外部からこのアクティビティが呼び出せる可能性が高いです。
🚀 ステップ②：adbコマンドでアクティビティを起動してみる
adb shell am start -n com.example.app/.AdminActivity
成功すれば、対象アクティビティが表示されます。 ログインなどの認証を経ずに直接アクセスできてしまった場合、これは本来想定されていない使われ方（意図しない起動）です。
💥 ステップ③：Drozerでの再現（オプション）
Drozerを使うと、exportedなアクティビティ一覧の取得や起動が可能です。
run app.activity.info -a com.example.app run app.activity.start --component com.example.app com.example.app.AdminActivity
→ 成功すれば、Drozer上からも任意アクティビティを実行できたことになります。
🧠 なぜこれが危険なのか？
アプリ設計上、「内部専用の画面」や「認証後にだけ見られる画面」が外部から自由に呼び出せてしまうと：
- 認証をバイパスできてしまう
- 設定情報の閲覧や変更ができてしまう
- 管理者操作を誰でも実行できる状態になる
という非常に深刻な状態になります。
✅ 診断時のチェックポイントまとめ
| チェック項目 | 確認方法 |
|---|---|
android:exported="true" のアクティビティ |
Manifestファイルを確認（MobSFやjadx） |
| 認証処理が入っているか | Javaコード内でのチェックを確認 |
| adb や Drozer での起動が可能か | 実機テストで起動を試す |
| 実行後に異常な動作をしないか | 本来の認証を通らずに操作できてしまうか？ |
🛡️ 対策方法
| 対策 | 内容 |
|---|---|
exported="false" にする |
外部からのアクセスを遮断 |
| 認証処理を必ずアクティビティ内でも行う | インテントで呼び出されても認証必須にする |
| アクティビティの起動元を確認する | getCallingActivity() や getIntent().getPackage() などで送信元を検証 |
✅ まとめ
- 意図しないアクティビティ呼び出しは「認証バイパス」につながる重大な脆弱性
- adb や Drozer を使えば誰でも呼び出せるかどうかを簡単に検証できる
- Manifestとコード両方に目を通し、exported設定と認証処理の有無をセットでチェックすることが重要
Best regards, (^^ゞ
