Hello there, ('ω')ノ
📌 ケース1：有名カレンダーアプリの情報漏洩（2019年公開事例）
概要：
人気のカレンダーアプリが、内部で使っていたコンテンツプロバイダが外部に公開状態になっていたことで、ユーザーの予定データが他アプリから読み取れてしまった。
発見された脆弱性：
<provider android:name=".provider.EventProvider" android:authorities="com.example.calendar.provider" android:exported="true" />
→ この設定により、URIスキーム（content://）を使えば、他のアプリから予定データが取得できる状態になっていた。
診断ツールでの再現例（Drozer）：
run app.provider.query --uri content://com.example.calendar.provider/events
→ イベントのタイトル、日時、メモ、場所などが一覧で取得できた。
なぜ問題だったのか？
- ユーザー本人は何の操作もしていないのに、他アプリが勝手に予定情報を読み取れる
- パーミッションもアクセス制御もない、完全な無防備状態
本来どうすべきだった？
| 対応 | 内容 |
|---|---|
| exported=false | 外部から呼ばれる必要がないProviderは非公開に |
| permission設定 | どうしても外部公開するなら android:permission でアクセス制限 |
| 実行時チェック | checkCallingPackage() を使ってアクセス元を制限 |
📌 ケース2：ゲームアプリに仕込まれた“裏パスワード”（2020年公開事例）
概要：
あるゲームアプリの認証画面で、特定の文字列を入力するとログインをスキップできる裏機能が発見された。
if (username.equals("debug") && password.equals("admin123")) { bypassLogin(); }
→ このコードはデバッグ用に残されたもので、本番環境にも混入していた。
どんなリスクが？
- 誰でもアカウントを偽装してゲーム内の課金履歴や成績を操作可能
- 管理者モードにも入れてしまう可能性があった
- リバースエンジニアリングで簡単に見つかる構造だった（APKTool + JADX）
対応すべきだった点
| ポイント | 対応策 |
|---|---|
| デバッグコードの削除 | リリースビルド時に無効化／除去するビルドフローを徹底 |
| ソースコード難読化 | ProGuardやR8でコードを読みにくくする対策 |
| デバッグフラグ管理 | BuildConfig.DEBUG による判定を徹底 |
✅ こうした事例が教えてくれること
| 教訓 | 説明 |
|---|---|
| セキュリティは“デフォルトオープン”ではなく“デフォルトクローズ”で設計するべき | |
| デバッグや開発中のコードは、本番環境に絶対に持ち込まないこと | |
| 小さなミス（設定1つ、1行のコード）が、大きな漏洩事故に繋がること | |
| バイナリで配布されるアプリでも、内部構造は見られる前提で対策するべき |
✅ 模擬診断とつなげて考えると…
今までの演習で扱ってきたような内容（ログ出力、インテントの誤設定、exported属性の見落としなど）が、現実の脆弱性として実際に報告されていることがわかります。
つまり、実際の攻撃者が見ている視点と同じ目線で演習を行ってきたということになります。
📝 まとめ
- 実例を知ることで、「どこに目をつけて診断すべきか」が明確になる
- 脆弱性は“特別なバグ”ではなく、“ありがちな設計・実装ミス”が引き金
- 日常的なアプリ診断でも「これは他でもあったな」と気づけると、再発防止につながる
Best regards, (^^ゞ
