Hello there, ('ω')ノ
🕵️♀️ 「不正なバックエンドAPI」とは？
ここでいう“不正”とは、必ずしも悪意あるものとは限りません。 以下のようなAPIも「セキュリティ的に危険」と判断されます：
| 種類 | 問題点の例 |
|---|---|
| 未公開API | ドキュメントにもUIにも存在しないがアクセスできる |
| 認証なしAPI | 誰でもアクセス可能な機密データエンドポイント |
| 旧バージョンAPI | セキュリティ制御が甘く脆弱性を含んでいる |
| デバッグ用API | 開発中に使ったテスト用の機能が残っている |
🧪 発見の手順（5ステップ）
✅ Step 1：SSLピンニングを解除する（前回記事）
Burp SuiteやFridaで通信を観察するには、まずSSLピン留めを解除しておく必要があります。
✅ Step 2：Burp Suiteで通信をキャプチャ
- スマホのプロキシをBurp Suiteに設定
- アプリを通常操作（ログイン、画面遷移、ボタンタップなど）
- 「HTTP history」タブで送受信されるリクエストを確認
📌 特に
POSTやGETリクエストの パス、ヘッダー、クエリパラメータ を注視！
✅ Step 3：エンドポイント一覧を洗い出す
通信履歴から、使用されているAPIのパスを一覧にまとめましょう。
/api/v1/login /api/v1/user/profile /api/v1/admin/debug-info ←これは怪しい！ /api/v1/logs
→ 見慣れない or UIに存在しないAPIがないかチェック。
✅ Step 4：パラメータを改変して再リクエスト
Burpの「Repeater」機能を使い、送信パラメータやヘッダーを書き換えて再送信します。
例：
- ユーザーIDを他人のIDに変えてレスポンスが得られるか？
- Authorizationヘッダーを削除しても使えるか？
- 存在しないAPIバージョン（例：
/api/v0/）が生きてないか？
✅ Step 5：レスポンス内容を検査
以下のような情報が返ってきたら、要注意です：
| レスポンス | 問題の可能性 |
|---|---|
| ユーザー一覧や個人情報 | 認可制御不備 |
| デバッグログや設定ファイル | 情報漏洩 |
| バージョン情報や内部構成 | 攻撃準備に悪用される可能性 |
| ステータスコード200で返る未知API | 誤って公開されているかも |
🧰 補助ツール
| ツール | 用途 |
|---|---|
| Burp Suite | 通信キャプチャ・改ざん・リプレイ |
| Frida | API呼び出しのタイミングを監視 |
| MobSF | アプリ内部に記載されたURLやAPIエンドポイントを静的抽出 |
| APKTool / jadx | アプリ内にハードコードされたURLを確認 |
🧠 実例：MobSFで検出された非公開API
診断中、MobSFで /api/admin/export-logs の存在を検出。
アプリUI上には存在せず、Burpで試したところ、ログファイルがダウンロードできてしまうAPIだった。
→ 対応：認証認可の導入＋パスの無効化
✅ まとめ
- Androidアプリが裏で使っているバックエンドAPIには、公開していない機能や開発中の残骸が含まれていることがある
- 通信を観察（Burp）、コードを静的解析（MobSF/jadx）、ランタイムで補足（Frida）することで、非公開エンドポイントの実態をつかめる
- 発見後は、パラメータ改変・未認証アクセス・権限チェック漏れを確認することが重要
- 本番環境ではアクセスせず、検証環境でのみテストを実施するようにしましょう
Best regards, (^^ゞ
