スマートフォンのアプリを利用する際、私たちは画面に表示される機能や操作のしやすさに注目しがちです。しかし、アプリが安全に動作するためには、その裏側で情報を処理するサーバや、データをやり取りする仕組みも適切に守られていなければなりません。
2026年10月、情報通信研究機構（NICT）が注意喚起を行った「A2B攻撃」は、こうしたアプリの裏側にあるシステムを狙う攻撃手法です。
アプリそのものにウイルスを仕込むのではなく、正規のアプリを解析し、接続先のサーバに存在する弱点を探して攻撃する点に特徴があります。
スマートフォン向けのサービスを提供する企業はもちろん、クラウドサービスや業務システムを利用する企業にとっても、無関係とはいえない問題です。
この記事では、A2B攻撃の仕組みや狙われる脆弱性、企業が取り組むべき対策について解説します。
A2B攻撃とは何か
A2B攻撃とは、スマートフォンアプリなどを手掛かりに、その接続先であるバックエンドのサーバやAPIを調査し、脆弱性を狙う攻撃手法です。NICTが2026年10月に注意喚起を公表したことで、国内でも注目されています。
アプリではなく、その裏側にあるサーバを狙う
一般的なサイバー攻撃というと、偽のメールで利用者をだましてパスワードを盗んだり、端末にマルウェアを感染させたりする手法を思い浮かべるかもしれません。
A2B攻撃は、これらとは少し異なります。
スマートフォンのアプリは、会員情報の表示や商品の購入、予約の登録などを行う際、インターネットを通じてサーバと通信しています。アプリは画面を表示するだけでなく、サーバに処理を依頼し、その結果を受け取る役割も担っています。
A2B攻撃では、この通信の仕組みに着目します。攻撃者がアプリのプログラムを解析し、接続先のサーバや通信に使用するAPIを特定したうえで、サーバ側の脆弱性を探すのです。
そのため、アプリが正規のものであり、利用者のスマートフォンがマルウェアに感染していなくても、サーバ側の対策が不十分であれば被害につながる可能性があります。
なぜ正規のアプリが攻撃の手掛かりになるのか
スマートフォンのアプリは、利用者の端末上で動作するプログラムです。アプリの内部構造や通信先などを、技術的な手法によって調べられる場合があります。
例えば、アプリがどのサーバに接続しているのか、どのような情報を送信しているのか、どのAPIを呼び出しているのかといった情報です。
開発者が通信の仕組みを公開していなくても、アプリを解析することで手掛かりが得られる場合があります。
もちろん、通信先が分かっただけで不正アクセスが成功するわけではありません。サーバ側で適切な認証やアクセス制御が行われていれば、不正な要求を拒否できます。
問題になるのは、アプリからの通信を処理するサーバに、認証や認可の不備、入力値の検証不足などの弱点が残っているケースです。
A2B攻撃はどのような流れで行われるのか
A2B攻撃を理解するには、スマートフォンアプリとサーバの関係を具体的に考えると分かりやすくなります。
例えば、会員情報を確認できるショッピングアプリがあるとします。このアプリは、利用者がログインすると、サーバから会員情報を取得して画面に表示します。
攻撃者は、この仕組みを手掛かりにサーバへの攻撃を試みます。
正規のアプリを解析する
まず、攻撃者はアプリのプログラムを調べ、サーバとの通信に関する情報を収集します。
接続先のURLやAPIの呼び出し方、送信するデータの形式などが、調査の手掛かりになります。
サーバのAPIに直接アクセスする
通信の仕組みが分かると、アプリの画面を操作することなく、APIに直接リクエストを送ることが可能な場合があります。
ここで重要なのは、正規のアプリを経由していないリクエストであっても、サーバ側が適切に検証しなければならないという点です。
アプリの画面で操作を制限していても、サーバ側で同じ制限を確認していなければ、不正な操作を許してしまう可能性があります。
サーバ側の脆弱性を探す
攻撃者は、APIの認証や認可、入力値の処理などに不備がないかを調べます。
例えば、ログイン済みの利用者が自分以外の会員情報を取得できないか、想定していないデータを送信すると異常な処理が実行されないか、といった点です。
情報漏えいや不正操作につながる
サーバ側に悪用可能な脆弱性があれば、会員情報の閲覧やデータの改ざん、不正なコード実行などにつながるおそれがあります。
ただし、実際にどのような被害が発生するかは、対象システムの構成や脆弱性の種類によって異なります。アプリを解析しただけで、必ずサーバへの侵入が成功するわけではありません。
A2B攻撃で狙われる主な脆弱性
A2B攻撃で注意したいのは、攻撃の名称そのものよりも、バックエンドのシステムに存在する具体的な脆弱性です。
今回のような攻撃では、従来から知られている脆弱性が悪用される可能性があります。
SSRF：サーバに意図しないアクセスをさせる
SSRFは、サーバが外部のURLなどを取得する機能を悪用し、本来アクセスさせるべきではない接続先にリクエストを送らせる脆弱性です。
設定によっては、外部から直接アクセスできない内部システムや、クラウド環境の管理用エンドポイントなどが危険にさらされる可能性があります。
接続先の制限や、ネットワークの分離などを組み合わせた対策が必要です。
SQLインジェクション：データベースの処理を悪用される
SQLインジェクションは、入力値の扱いに不備がある場合に、攻撃者が意図しないSQL文を実行させる脆弱性です。
悪用されると、データベースに保存された情報の漏えいや改ざんなどにつながるおそれがあります。
対策としては、プレースホルダを利用した安全なSQLの実行や、適切な入力処理などが重要です。
IDOR・BOLA：他人のデータにアクセスできてしまう
IDORやBOLAは、利用者が本来アクセスできないデータを取得・操作できてしまう、アクセス制御上の問題です。
例えば、会員Aが自分の注文履歴を確認するAPIがあり、リクエストに会員番号が含まれているとします。
サーバがログイン状態だけを確認し、要求された会員番号が本人のものかどうかを検証していなければ、会員Aが別の会員の注文履歴を閲覧できてしまう可能性があります。
このような問題は、アプリのログイン画面が正常に動作していても発生します。データにアクセスするたびに、サーバ側で適切な権限確認を行う必要があります。
RCE：サーバ上で不正なコードを実行される
RCEは、攻撃者がサーバ上で任意のコードを実行できてしまう脆弱性です。
悪用された場合、システムへの侵入やデータの窃取、サービスの停止など、深刻な被害につながる可能性があります。
ソフトウェアの脆弱性修正に加え、実行権限の制限やネットワークの分離など、多層的な防御が求められます。
なぜ今、A2B攻撃への注意が必要なのか
A2B攻撃で利用される技術の多くは、以前から知られているものです。アプリを解析して通信先を調べたり、APIの脆弱性を探したりすること自体が、最近になって初めて可能になったわけではありません。
それでも、今回の注意喚起をきっかけに、アプリの裏側にあるシステムの安全性を改めて確認する必要があります。
APIを利用するサービスが増えている
現在、多くのWebサービスや業務システムは、APIを通じてデータをやり取りしています。
スマートフォンアプリだけでなく、Webサイト、クラウドサービス、外部の業務システムなども、APIを利用して連携しています。
こうした仕組みは、サービスの利便性や開発効率を高める一方、APIの設計やアクセス制御に不備があれば、攻撃の入口になる可能性があります。
AIによって脆弱性の調査が効率化される可能性がある
もう一つ注目したいのが、AIの活用です。
プログラムの解析やAPIの仕様の整理、脆弱性の候補の抽出といった作業は、AIによって効率化できる可能性があります。専門知識を持つ攻撃者がAIを活用すれば、調査に必要な時間や手間を減らせる場合もあります。
ただし、AIを使えば誰でも簡単にサーバへ侵入できるというわけではありません。実際の攻撃が成立するかどうかは、対象システムの脆弱性や設定、アクセス制御などに左右されます。
重要なのは、攻撃側の調査能力が高まる可能性を踏まえ、既存のシステムに弱点が残っていないかを確認することです。
企業が取り組むべきA2B攻撃への対策
A2B攻撃への対策として、アプリの解析を完全に防ごうとするだけでは十分ではありません。
アプリの内部構造が調べられたとしても、不正なリクエストをサーバ側で拒否できるようにすることが重要です。
APIごとに認証と認可を確認する
まず確認したいのが、APIの認証・認可です。
認証は、利用者が誰であるかを確認する仕組みです。一方、認可は、その利用者が特定のデータを閲覧したり、操作したりする権限を持っているかを確認する仕組みです。
ログインできているからといって、すべてのデータにアクセスできてよいわけではありません。
会員情報や注文履歴、社内データなどを扱うAPIでは、要求されたデータや操作に対して適切な権限があるかを、サーバ側で確認する必要があります。
公開しているAPIを棚卸しする
企業が運用するシステムには、現在使用しているAPIだけでなく、古いアプリ向けのAPIや、開発時に作成した検証用のエンドポイントが残っている場合があります。
利用されていないAPIであっても、外部からアクセスできる状態であれば、リスクになる可能性があります。
公開しているAPIを洗い出し、不要なものを停止するとともに、必要なAPIについては脆弱性診断や設定の確認を行うことが大切です。
WAFだけに頼らず、サーバ側の対策を行う
WAFなどのセキュリティ製品は、不審な通信や攻撃パターンを検知・遮断するうえで役立ちます。
しかし、正規のAPIを利用して、権限の範囲を超えたデータ取得を試みるような攻撃は、通信の内容だけでは判別が難しい場合があります。
そのため、WAFなどの境界防御に加え、アプリケーション側でのアクセス制御や入力値の検証、ログの監視などを組み合わせる必要があります。
アクセスログから不審な動きを把握する
APIのアクセスログを適切に記録・監視することも重要です。
例えば、短時間に大量のデータを取得するアクセスや、異なる会員番号への連続したリクエスト、通常とは異なるAPIの呼び出しなどは、調査すべき兆候になる場合があります。
ただし、こうしたアクセスが必ず攻撃であるとは限りません。通常の利用状況を把握したうえで、不自然な動きを検知できる仕組みを整えることが重要です。
スマホアプリを使っていない企業も無関係ではない
A2B攻撃という名称から、スマートフォンアプリを開発する企業だけが対象だと思うかもしれません。しかし、注意すべきなのは、アプリそのものよりも、その裏側で動くシステムの脆弱性です。
例えば、顧客管理システムや予約システム、オンライン販売サイト、業務用SaaSなど、APIを利用してデータをやり取りするサービスは幅広く存在します。
自社で開発したシステムだけでなく、外部の開発会社に構築を委託したシステムや、クラウド上で利用しているサービスについても、どの範囲を誰が管理しているのかを確認しておく必要があります。
特に中小企業では、システムの開発と保守を外部に委託しているケースも少なくありません。その場合、委託先に任せきりにするのではなく、脆弱性診断の実施状況や、セキュリティ上の問題が見つかった場合の対応方法を把握しておくことが大切です。
まとめ：アプリの安全性だけでなく、バックエンドの防御も重要
A2B攻撃は、正規のスマートフォンアプリを解析し、その接続先であるサーバやAPIの脆弱性を狙う攻撃手法です。
アプリが正常に動作していても、サーバ側の認証・認可に不備があれば、情報漏えいや不正操作につながる可能性があります。
企業が取り組むべきなのは、アプリの解析を完全に防ぐことではありません。APIのアクセス制御を徹底し、公開しているシステムの脆弱性を把握し、不審なアクセスを検知できる体制を整えることです。
スマートフォンアプリやクラウドサービスが企業活動に深く組み込まれている現在、その裏側にあるサーバやAPIの安全性を確認することも、重要なセキュリティ対策の一つといえるでしょう。
NICTによる注意喚起の詳細は、公式ページで確認できます。
最後までお読みいただきありがとうございました。当ブログは日常のICTの困りごとを解決するためのノウハウを発信しているサイトです。トップページもご覧ください。
