「A2B攻撃」とは？アプリに脆弱性がなくても情報漏洩する理由と対策
本記事はサイバー被害を防ぐための知見の共有を目的としており、記事の内容の悪用や、不正行為、他者に損害を与える行為への利用を固く禁じます。
会員向けのAndroidアプリでは、氏名や購入履歴を事業者のサーバーで管理することが多い。その接続先に不備があれば、Androidアプリ自体に脆弱性がなくても顧客情報が漏れるおそれがある。
2026年10月13日、情報通信研究機構（NICT）の脅威情報分析チームLETTICEは、国内の情報漏洩の原因の一つとして「A2B攻撃」への注意を呼びかけた。自社でAndroidアプリを開発・公開する担当者に向け、狙われる不備と、開発・運用チームが確認する内容を整理する。
A2B攻撃はどこを狙うのか
A2BはApp-to-Backend Attackの略だ。公開されているAndroidアプリを解析し、得られた情報を悪用して接続先のサーバーを攻撃する手法を指す。ログインや会員情報の管理などを担う接続先を、バックエンドサーバーと呼ぶ。
Androidアプリとバックエンドの間では、APIという接続仕様に従って情報をやり取りする。例えば購入履歴を表示する機能なら、Androidアプリがサーバーへ取得を求め、サーバーが返したデータを画面に表示する。
LETTICEの注意喚起で確認されたのは、Google Playの日本地域で公開されているAndroidアプリの解析結果を使う攻撃だ。攻撃者はAPIの接続先や仕様を把握し、個々のサーバーに合わせて脆弱性を狙う。事業者が仕様書を公開していなくても、利用者へ配布したプログラムには通信に必要な情報が含まれる。
NICTは、iOSアプリやWebサービスのバックエンドでも同様の問題が起こる可能性を指摘している。自社が公開するソフトウェアと、その接続先を組み合わせて点検する必要がある。
どの不備が情報漏洩につながるのか
APIで利用者が誰かを確認する処理が認証、対象データや操作への権限を確認・制御する処理が認可だ。ログイン後に利用する機能にも、サーバー側の認可チェックが要る。
会員向けサービスを例に考えると、サーバーは購入履歴の取得を求めた利用者に、その履歴の参照権限があるかを判定する必要がある。この認可チェックが欠けていれば、ログイン済みの利用者に他の会員の履歴を返してしまうおそれがある。画面に本人の履歴だけを表示する制御と、サーバーでデータの取得を拒否する制御は別々に確認する。
LETTICEは、確認したA2B攻撃で主に探索・悪用の対象となった問題として、次の4種類を挙げている。
- IDOR：外から指定するデータの識別子に対する認可チェックが欠け、権限のないデータを取得・変更できる不備。データ単位の認可不備であるBOLAと重なる問題だ。
- SSRF：外部からの要求を受けたサーバーが、許可すべきでない通信を行ってしまう不備。内部システムの情報が取得されるおそれがある。
- RCE：外部からの要求で、サーバー上の不正なコードやコマンドを実行される問題。情報の窃取や改ざんにつながる。
- SQLインジェクション：入力された内容がデータベースへの不正な命令として処理される不備。保存された個人情報の取得などにつながる。
同じ注意喚起の点検項目には、認証・セッション管理やクラウドストレージの設定も含まれる。開発チームは、この4種類を確認した結果と、それ以外の設定をどこまで確認できたかを分けて記録したい。
AIで何が変わるのか
NICTは、AIを使ったプログラム解析や脆弱性探索の効率化に注意を促している。注意喚起PDFの図1にも、AIを使う解析と攻撃内容の作成が描かれている。個々のAPIに合わせた調査が効率化すると、より多くのシステムが狙われる可能性があるという指摘だ。
資料が公表しているのは、確認した手法と対策だ。使われたAI製品や、個々の被害企業との対応は示されていない。自社への影響は、公開するAPIの不備とアクセス記録から確認する。
自社では何から確認するか
最初に、公開しているAPIとサーバーを洗い出す。現行のAndroidアプリが使うものに加え、古いAPI、検証環境、管理機能、クラウド上の公開サービスも含める。開発を委託している場合は、発注側と委託先で一覧を照合し、運用を担当する部署や会社を確認する。
次に、アクセスログ・APIログ・認証ログから、侵害の有無を調べる。LETTICEは2026年8月以降、可能ならそれ以前の記録も確認するよう推奨している。特に確かめたいのは、通常の利用と異なる大量のデータ取得、権限のない会員情報の参照・変更、不審な認証トークンの発行や管理機能の利用だ。認証トークンは、認証後の要求などで利用者を確認するための情報を指す。
注意喚起に載るIoCは、不審な通信を調べる手掛かりとなる侵害指標だ。IPアドレスなどが一致した場合も、通信の日時、認証の成否、取得・変更されたデータを調べて影響を判断する。一致だけでは侵害を断定できないためだ。
不備の点検では、利用者とデータの組み合わせごとの認可チェック、認証情報の管理、入力値の検証、クラウドのアクセス設定を確認する。閲覧できるかだけでなく、更新・削除など各操作の権限も調べる。検証は所有者が許可した範囲と試験用データで行う。
PMや情シスは、確認したAPI、利用者の権限、試験した操作、結果を委託先や開発担当者に残してもらう。未実施の機能や修正待ちの問題にも担当者と対応時期を付けると、診断済みという言葉だけで確認を終えずに済む。
修正までの間、被害をどう抑えるか
修正が必要なAPIについては、業務への影響を確認しながら暫定的な制限を決める。NICTとJPCERT/CCが示す対策には、次のものがある。
- 不要なAPI・管理機能・検証環境の公開を止め、必要な機能も接続元や利用権限を制限する。
- 大量の要求や通常と異なるデータ取得を監視し、一定時間内の要求数を制限するレート制限などを設ける。
- 認証情報やトークンの漏洩・悪用が疑われる場合は無効化し、必要なものを再発行する。
- 制限だけでは被害の危険を十分に下げられない場合、該当APIや機能、必要に応じてサービスの一時停止を検討する。
恒久的な対策では、ソフトウェアの内部構造やAPI仕様を知られても、権限外の操作を拒否できるようにサーバー側を直す。修正後は、許可した操作が使えることと、許可していない操作が拒否されることを確認する。
A2B以外の経路も含めて自社の対策を見直すには、サイバー攻撃の入口と手法の整理から、認証や管理画面などの確認へ進める。
AIがソフトウェアを解析する仕組みも知りたい場合は、「REA」の解説で、解析ツールとAIエージェントの役割分担や、解析で得られる情報を確認できる。