A2B攻撃とは──スマホアプリを解析して裏側のサーバーを狙う、相次ぐ情報漏えいの一因

2026年10月13日、情報通信研究機構（NICT）の脅威情報分析チーム「LETTICE」が、「A2B攻撃」という攻撃手法への注意喚起を出した。同じ日に総務省も、事業者に向けて対策の徹底を呼びかけている。

A2Bは「App-to-Backend」の略だ。すごく雑に言うと、「誰でもダウンロードできるスマホアプリを分解して、その裏でつながっているサーバーの攻め方を調べる」手口である。NICTは、国内で相次いでいる個人情報の漏えい事案の原因の一つとして、この攻撃を確認したとしている。

サマリー

そもそも「アプリの裏側」とは何か

「A2B攻撃」と聞いても、何が起きているのか分かりにくい。まずは、普段使っているスマホアプリが裏側のサーバーとどうつながっているのかを考えてみたい。

ショッピングアプリで注文履歴を開くとき、履歴のデータはスマホの中にあるわけではない。アプリはインターネットの向こうにある「バックエンドサーバー」（ログインの確認や会員情報の管理をする、裏側のコンピューター）に問い合わせて、データを受け取っている。

このアプリとサーバーのやり取りの窓口を「API」（アプリとサーバーが情報をやり取りするための決まりごと）と呼ぶ。

レストランにたとえると分かりやすい。

ふだん私たちは、注文票（アプリ）の画面に沿ってしか注文できない。でも厨房（サーバー）から見れば、届くのは「伝票」だけだ。正しい書式の伝票を自分で作れば、注文票を通さず、厨房へ直接注文を送ることもできる。

もちろん、厨房側が注文者の本人確認や権限の確認をきちんと行っていれば、不正な注文は断れる。逆に言えば、問題になるのは、届いた伝票を確かめずに受け付けてしまう厨房だ。

A2B攻撃の流れ

NICTの注意喚起によると、確認された攻撃は次の流れで進む。

graph LR
    A[Google Playから<br/>アプリを入手] --> B[アプリのプログラムを解析]
    B --> C[接続先・API・<br/>パラメータを特定]
    C --> D[サーバーごとに<br/>攻撃を組み立てる]
    D --> E[弱点を突いて<br/>情報を取得]

攻撃者はまず、Google Playの日本地域で公開されているAndroidアプリを入手する。次にそのプログラムを解析し、アプリがどのサーバーに、どんな書式で、どんな項目を送っているかを調べる。レストランのたとえで言えば、「厨房への伝票の書き方」を突き止める段階だ。

そのうえで、調べた情報をもとに、サーバーの弱点を探す問い合わせを直接送り込む。アプリの画面からはできない操作も、伝票の書き方さえ分かれば試せてしまう。

今回の攻撃で特徴的なのは、アプリの解析結果をもとに、接続先のサーバーごとに攻撃方法を変えている点だ。不特定多数のサーバーに同じ攻撃をばらまく手口とは、性質が異なる。

厄介なのは、アプリそのものに欠陥がなくても、サーバー側の確認が甘ければ情報漏えいが起こり得ることだ。

アプリ側の安全対策は、もちろん重要だ。ただ、攻撃者はアプリを通らずに、サーバーへ直接問い合わせを送ってくる。アプリが適切に作られていても、それだけでサーバーの安全が保証されるわけではない。サーバー側でも、認証・認可（相手が誰かを確かめ、その人に許された操作かを確かめること）や入力内容の検証を行う必要がある。

なお、狙われるのはログインしなくても使えるAPIだけではない。ログインした後に使えるAPIも、攻撃の対象になる場合がある。

狙われる代表的な4つの弱点

NICTによると、今回の攻撃で主に狙われているのは次の4種類の脆弱性（ソフトウェアの弱点）だ。

ただし、狙われるのはこの4つだけではない。NICTは点検すべき項目として、ログインや認証の仕組みの不備、クラウドのストレージなどの設定ミスも挙げている。

4つの中で一番イメージしやすいのがIDORだ。会員番号が「1001」の人が自分の情報を表示するとき、裏側ではサーバーに「1001番の情報をください」と問い合わせている。では、この番号を「1002」に変えたらどうなるだろうか。

もし他人の氏名やメールアドレスが返ってくるなら、サーバー側の権限確認に問題がある。サーバーが「この人に、1002番の情報を見せてよいか」を確かめていないということだ。

NICTは、番号が連番などで推測しやすい場合、大量の情報漏えいにつながるおそれがあると指摘している。権限の確認がなく、問い合わせの回数にも制限がなければ、番号を順に試すことで、多くの会員の情報を取得されるおそれがある。

なぜ今、注意喚起が出たのか

背景には、2026年秋の情報漏えいの多発がある。JPCERT/CC（日本のセキュリティ事故の情報を集めて調整する組織）は10月8日の注意喚起で、「直近2026年9月前後で国内組織における不正アクセスによる個人情報等の漏えい被害が相次いでいる」と書いている。

JPCERT/CCは同じ注意喚起の中で、確認されている手口の一つとして、一般公開しているスマートフォンアプリを解析し、APIの接続先やキーを特定する攻撃を挙げていた。

気になるのは、こうした攻撃にAIがどう関わってくるかだ。NICTも、AIによってアプリの解析や脆弱性の探索が効率化され、攻撃対象が広がる可能性を指摘している。これまで手間のかかったアプリの解析が楽になれば、狙われるアプリの数も増えうる、ということだ。

ただし、NICTの注意喚起は、今回確認した攻撃でAIが使われたとまでは書いていない。「AIが攻撃した」のではなく、「AIで攻撃の下準備が楽になる時代に、この手口が広がるおそれがある」と読むのが正確だ。

事業者に求められている対策

NICTは、Androidアプリを公開している事業者に、次の3つを早急に行うよう推奨している。

洗い出しの対象には、今のアプリが使っているAPIだけでなく、古いバージョンのAPI、サブドメイン、検証環境も含めるよう求めている。

根本的な対策として、NICTと総務省がそろって強調しているのが、「アプリは解析される前提で、サーバー側で確認する」という考え方だ。アプリの中身や伝票の書き方が知られても大丈夫なように、サーバー側で「誰が」「何を」してよいかを毎回確かめることが重要になる。

総務省は、同様の問題がAndroidアプリに限らず、iOSアプリやWebサービスでも起こりうるとしている。「うちはiPhoneアプリだけだから関係ない」とは言えない点に注意したい。

なお、ここまでの対策は、アプリを提供する事業者に向けたものだ。NICTと総務省の注意喚起には、アプリの利用者向けの対策は書かれていない。漏れるのはサーバーに保存された情報なので、利用者が手元のアプリを消せば防げる、という種類の問題ではない。

まとめ

A2B攻撃を知って改めて考えさせられるのは、スマホアプリの安全性と、その裏側にあるサーバーの安全性は別の問題だということだ。

アプリは、店の外に置かれた注文票のようなものだ。誰でも持ち帰って、書き方を調べられる。NICTも言うように、それ自体を完全に防ぐのは難しい。だからこそ、厨房に届いた伝票を、その都度きちんと確かめる必要がある。

当たり前のことに聞こえるかもしれない。ただ、NICTが確認した攻撃事例は、その当たり前が守られていないときに何が起きるかを示している。

情報ソース：