こんにちは、ぎぐちゃんです。スマホアプリを使うと、画面の向こう側にあるサーバーへ「ログインしたい」「自分の情報を見せて」とお願いしています。サーバーは、サービスのデータを保管して返事をするコンピューターです。このアプリとサーバーのやり取りを利用して、サーバー側の弱点を探す手口が「A2B攻撃」です。

A2Bは「App-to-Backend Attack」の略。NICT（情報通信研究機構）の脅威情報分析チームLETTICEは、2026年10月13日に注意喚起を公開し、同日15時に更新しました。A2Bは特定のアプリ名や、ひとつの新しい欠陥の名前ではありません。アプリを手がかりに、裏側のサーバーを狙う攻撃の流れにつけられた呼び方です。

アプリを手がかりに、サーバーを狙う

たとえば、アプリを「お店に注文を伝える端末」、サーバーを「注文や会員情報を管理するお店の奥」と考えてみてください。アプリはサーバーに注文を伝えるための窓口を使います。この窓口が、専門用語で「API（エーピーアイ）」です。

  1. 攻撃者が、誰でも入手できるアプリの中身を調べる。
  2. アプリがどのサーバーに、どんな頼み方をしているか手がかりを集める。
  3. アプリの画面を通さず、サーバーへ直接リクエストを送り、守りの弱いところがないか試す。

アプリの画面にあるボタンや入力制限は、アプリを使う人の操作を整えるためのものです。攻撃者はその画面を経由せずにAPIへ要求を送れるため、画面側の制限だけではサーバーを守れません。認証が必要なAPIも攻撃対象になることがあり、ログインしているかだけでなく、要求された操作やデータをその利用者に許可してよいかをサーバー側で確かめる必要があります。

アプリの中身を見られただけで、すぐに情報が盗まれるわけではありません。攻撃が成立するかどうかは、サーバー側で本人確認や権限、入力内容を適切に確かめているかに左右されます。

どんな不備が狙われる？

NICTは、次のようなサーバー側の弱点が調べられていると説明しています。名前は難しいですが、起きることを簡単にするとこうなります。

  • サーバーに別の場所を見に行かせる（SSRF）：本来は外から見られない社内の情報などを、サーバー経由で取りに行かせてしまう不備です。
  • サーバーに不正な処理を実行させる（RCE）：サーバー上で、運営者が意図していないプログラムを動かされる恐れがあります。
  • データベースへの命令に入力を混ぜられる（SQLインジェクション）：入力された文字がデータベースへの命令として扱われる不備です。悪用されると、保存された情報を読まれたり書き換えられたりする恐れがあります。
  • 他人のデータを見分ける確認が足りない（IDOR）：自分の会員番号を別の番号に変えただけで、他の人の情報まで見えてしまう不備です。

最後の例は、ログインしている人かどうかだけでなく、「この人がこのデータを見てよいか」まで確認する必要があることを示しています。ログイン済みでも、他人の情報を見る権利があるとは限りません。

なぜ今、注意喚起された？

NICTは、AIを使うことでアプリの解析や弱点探しが効率化し、攻撃がより多くのシステムに広がる可能性を懸念しています。ただし、これは今後のリスクについての注意です。今回確認された個々の攻撃でAIが使われたと確認された、という意味ではありません。

サービスを運営する人は何を確認する？

まず、アプリからつながるAPIやサーバーを洗い出します。古いサービス、使っていないAPI、テスト用環境など、インターネットからアクセスできる入口も確認します。

次に、サーバーの記録を調べます。NICTは2026年8月以降のアクセスログやAPIログ、認証ログを確認し、可能であればそれ以前の記録も見るよう案内しています。短時間に大量の情報を取ろうとしていないか、番号を順番に変えて他人の情報へアクセスしていないか、認証情報や管理機能に不審な利用がないかを確認します。

弱点が見つかったら、原因となる設定やプログラムを修正し、使っているソフトウェアに修正済みの更新版があれば適用します。認証情報やAPIトークンの漏えい・悪用が疑われる場合は、それらを無効化して再発行します。

そのうえで、サーバー側で毎回「誰が使っているか」「その人にこの操作やデータへの権限があるか」を確認し、入力を安全に処理します。不要なAPIや管理機能を停止・制限することも重要です。アクセス回数の制限やWAFは、調査・修正までの被害を抑えるための補助策で、脆弱性そのものの修正に代わるものではありません。

使っているアプリを消すべき？

今回の注意喚起は、主にアプリやサービスを提供する事業者向けです。A2B攻撃は、利用者のスマホにウイルスを入れることが前提の手口ではありません。A2Bという言葉を見ただけで、使っているアプリを一斉に削除する必要があるとは言えません。

利用者は、サービス運営者からのお知らせを確認し、パスワードを使い回さないことや、多要素認証を使うこと、身に覚えのないログイン通知があれば公式窓口へ相談することができます。これらはアカウントの不正利用や漏えい後の二次被害を減らす助けになりますが、運営側のサーバーの不備による情報漏えい自体を防ぐものではありません。サーバーの調査と修正は運営者の責任です。

大切なのは、窓口を隠すことではない

アプリの中身や通信先を完全に隠すのは難しいため、「場所が知られたら終わり」という設計にはできません。攻撃者がアプリ画面を介さずAPIを直接操作できることを前提に、サーバー側で認証・権限を確認し、異常な操作に気づけるように作ることが基本です。NICTは、同じ問題がAndroidアプリだけでなく、iPhoneアプリやWebサービスのバックエンドでも起こり得ると説明しています。

参考資料

公開：2026年10月14日。攻撃の説明と対策はNICT LETTICEおよびJPCERT/CCの注意喚起に基づいています。今回確認された攻撃全体に関する説明と、個別の情報漏えい事案の原因や攻撃者に関する断定は分けています。一般向けの解説であり、個別システムの安全性を判定するものではありません。