公開アプリ解析前提でバックエンドを守る（A2B 攻撃の点検チェックリスト）

いつ使うか

• モバイルアプリ（Android に限らず iOS／Web のクライアントも同様）を公開し、裏側に会員 API・決済・個人情報があるとき
• 国内の大規模漏えい事案が続いている局面で、自社の公開 API を優先点検したいとき
• 「クライアント側で隠しているから安全」と思っている設計を見直すとき（クライアント制御は迂回される）

攻撃の要点（防御側が押さえること）

1. 攻撃者は正規の公開アプリを入手し、API 接続先・エンドポイント・パラメータ・応答構造を調べる
2. アプリを経由せず、サーバへ直接リクエストを組み立てて脆弱性を探す
3. 狙われやすいのは主に SSRF / RCE / SQL インジェクション / IDOR（BOLA）
4. AI で解析・探索が効率化されているため、「うちは目立たない」は当てにならない

手順（事業者向け 3 種）

1. 侵害の確認

• アプリが使う API、サブドメイン、旧版 API、検証環境、クラウド公開サービスまで含めて公開面を列挙する
• 2026-08 以降（可能ならそれ以前も）のアクセスログ・API ログ・認証ログを、後述 IoC や異常パターンと突合する
• 見るべき異常例: 認証なしの大量取得、連番 ID 走査、他会員情報の閲覧・変更、認証トークンの不審な発行、管理機能の利用
• ヒットしたら認証成否・取得データの範囲・認証情報の悪用有無をすぐ切り分ける

2. 脆弱性の点検（優先順）

• IDOR/BOLA: 会員 ID 等を変えるだけで他者・他テナントの情報を読める／書けるか
• 認証・セッション: トークンの不正発行・偽造・認証回避、固定クレデンシャルや鍵の露出
• SQLi / NoSQLi: 外部入力経由の DB 不正操作
• SSRF: URL 取得・画像処理・文書変換などから内部網・クラウドメタデータ・ローカルファイルへ届くか
• クラウド設定: S3 / GCS / Firestore 等が認証なしや過剰権限で届かないか
• コード実行・ファイル操作: 危険なデシリアライズ、任意ファイル書込、管理機能の不用意な公開

3. 暫定緩和

• 国外／不要な送信元の一時制限、不要 API・管理機能・検証環境の停止
• レート制限・WAF、連番 ID アクセスの監視
• 漏洩・悪用が疑われる認証情報の無効化・再発行
• すぐ直せない重大リスクは、該当 API やサービス一時停止も選択肢

恒久設計の原則

• 「アプリを介さずに API を直接叩ける」前提で、認証・認可・入力検証は 必ずバックエンド側 で行う
• クライアント難読化や「アプリにしか教えない URL」は、解析前提では防御にならない
• 自己点検の補助として、自作 APK を解析ツールや AI に渡し「どこまでエンドポイントが読めるか」を見るのは有効（攻撃者視点のリハーサル）。ただし本番キーや個人データを含むビルドは渡さない

IoC（参考・一致だけでは断定しない）

注意喚起 PDF に掲載の例（ドットは防御表記）:

• 69.10.51[.]162
• 210.149.87[.]120
• 207.241.172[.]54

注意点

• Android 固有の問題ではなく、公開クライアントがあれば同じ構図になる
• IoC 一致だけで侵害断定はできない。ログ内容と合わせて判断する
• 型で所有者チェック済み ID を表す設計は TypeScript: 所有者チェック済みをブランド型で表し、IDOR を型で防ぐ も参照

出典

• @yousukezan · 2026-10-13
• NICT プレス: nict.go.jp
• CYNEX Library（注意喚起・PDF）: cynex.nict.go.jp
• 関連観察（calloc134）: @calloc134 · 2026-10-13