A2B攻撃とは
2026年10月13日、NICTのサイバーセキュリティネクサス（CYNEX）で活動する脅威情報分析チームLETTICEは、公開されているAndroidアプリを解析し、その結果を利用してバックエンドサーバを攻撃する手法を「A2B攻撃（App-to-Backend Attack）」と呼称し、注意喚起を公表しました。 攻撃者はGoogle Playで公開されているアプリを入手して解析し、APIのエンドポイント、パラメータ、レスポンスの構造などを調べたうえで、対象のサーバに合わせたリクエストを送って脆弱性を探索・悪用します。
注意喚起では、国内で相次いでいる情報漏洩事案の原因の1つとしてこの手法が確認されたと指摘しており、主に狙われている脆弱性としてSSRF、RCE、SQLインジェクション、IDOR（BOLA）の4種類が挙げられています。 また、AIの活用によってアプリの解析や脆弱性の探索が効率化され、より多くのシステムが攻撃対象になり得る点にも注意を促しています。
A2B攻撃は新しい攻撃手法ではない
名称は新しいものの、アプリを解析してAPIの仕様を把握し、サーバ側の脆弱性を突く手法自体は以前から広く知られています。 スマホアプリの脆弱性診断やペネトレーションテストでも、APKを逆コンパイルしてエンドポイントやパラメータを洗い出し、APIサーバを検証することは基本的な手順の1つです。
OWASP Mobile Top 10では2016年版からリバースエンジニアリングやコード改ざんがリスクとして挙げられ、OWASP API Security Top 10では2019年版から一貫してオブジェクト単位の認可不備（BOLA）が筆頭に置かれています。 今回の注意喚起の意義は、この古典的な手法が実際の被害につながっていること、そしてAIによって攻撃の規模が広がり得ることを改めて示したうえで、「A2B攻撃」という名称を与え、アプリを公開する事業者に広く認知を促した点にあります。
APIのエンドポイントが知られること自体は問題ではない
APKはGoogle Playなどから誰でも入手でき、JADXなどのデコンパイラを使えばJavaに近いソースコードとして容易に読むことができます。 アプリがAPIと通信する以上、接続先のURLやパスはアプリ内に含まれており、仮に難読化していても通信を観察すれば把握できます。
つまり、APIのエンドポイントが攻撃者に知られることは当然であり、それ自体は脆弱性ではありません。 Webアプリケーションでも、ブラウザの開発者ツールを開けばAPIの呼び出し先は誰でも確認できます。
問題になるのは、APIサーバに認可不備やインジェクション攻撃のような致命的な脆弱性が残っている場合です。 A2B攻撃への対策は「APIを隠すこと」ではなく、「APIが知られても安全であること」を目指して考える必要があります。
対策の基本①：APIサーバに致命的な脆弱性を作らない
A2B攻撃で被害を生むのは、アプリではなくAPIサーバの脆弱性です。 攻撃者は正規のアプリを経由せず、任意のリクエストをAPIへ直接送れるため、アプリの画面で入力を制限していてもサーバ側の防御にはなりません。
特に次の観点は、注意喚起の詳細資料（PDF）でも重点的な点検対象として挙げられています。
- 認可不備（IDOR/BOLA）：会員IDなどの識別子を書き換えて、他の利用者のデータを参照・変更できないか
- 認証・セッション管理の不備：トークンの偽造や不正発行、認証回避ができないか、アプリ内に固定の認証情報や秘密鍵を埋め込んでいないか
- インジェクション攻撃：SQLインジェクションやNoSQLインジェクションが成立しないか
- SSRF：URL取得や画像処理などの機能から、内部ネットワークやクラウドのメタデータにアクセスできないか
- クラウドの設定不備：ストレージやデータベースに、認証なしや本来許可されていない権限でアクセスできないか
また、現在のアプリが使っていない旧バージョンのAPIや検証環境も、過去のバージョンのアプリから接続先が見つかることがあります。 公開しているAPIとホストを棚卸しし、不要なものは停止またはアクセスを制限します。
APIサーバは、インターネットに公開されたWebシステムそのものです。 アプリの診断とは別に、APIサーバもWebアプリケーションと同じ観点で診断の対象に含めることが重要です。
対策の基本②：クリティカルな処理はクライアントで行わずサーバに寄せる
Androidアプリは、特別な対策をしていなければ改ざんが容易です。 ApktoolなどでAPKをsmaliに逆アセンブルして処理を書き換え、再ビルドして再署名すれば、改変したアプリを自分の端末で動かせます。 FridaなどのDBI（Dynamic Binary Instrumentation）ツールを使えば、実行中の処理を書き換えることもできます。
そのため、権限の判定、価格や残高の計算、購入や特典付与の可否といった、改ざんされると被害につながる処理をクライアント側に置くと、その判定は容易に回避されます。 「アプリの画面で管理機能のボタンを非表示にしている」「アプリ内で課金状態を判定している」といった実装は、APIサーバ側で同じ判定をしていなければ防御として機能しません。
クライアントは入力と表示を担う存在と捉え、重要な判断はサーバで行い、クライアントから届く値は信頼しない設計を基本にします。 サーバ側の判定が適切に実装されていれば、アプリ側の判定を回避しただけでは不正な処理は成立しません。
クライアントで重要な処理を行わざるを得ない場合の対策
ゲームのように、応答性やオフライン動作の都合から、すべての判定をサーバに寄せられないアプリもあります。 たとえばリアルタイム性の高いアクションゲームでは、操作ごとの判定をすべてサーバで行うことが現実的でない場合があります。
このような場合は、解析をやりづらくする対策と、不正が行われたことを検知する仕組みの両方を用意します。まず、クライアントの解析と改ざんに必要なコストを引き上げる対策として、次のようなものがあります。
- 難読化：難読化ツールを用いて識別子や制御フロー、文字列を難読化し、ネイティブコードを保護することで、解析に必要な時間を延ばします
- root化・改ざん・DBIツールの検知：root化された端末やエミュレータ、デバッガ、FridaなどのDBIツールの利用、APKの再署名を検知します
- Play Integrity APIの導入：Google Playから正規にインストールされたアプリか、改変されていないか、信頼できる端末で動作しているかを、Googleが提供する仕組みで確認します
Play Integrity APIの判定結果は、必ずサーバ側で検証し、リクエストと紐づけて再利用を防ぎます。 クライアント側だけで判定結果を確認すると、その確認処理自体が改ざんによって無効化されるためです。
ただし、これらの対策は解析を不可能にするものではなく、解析に必要な時間とコストを増やす手段です。 そのため、解析をやりづらくするだけでなく、不正が行われた場合にそれを検知できるようにしておくことが重要です。
ゲームであれば、ランキングやスコアの推移をサーバ側で確認し、仕様上到達し得ないスコアや、短期間での不自然なスコアの伸びを検知する方法があります。 ステージのクリア時間、獲得したアイテムや通貨の量、操作の間隔なども、通常のプレイで取り得る範囲と照らし合わせることで不正の手がかりになります。
検知した結果はランキングからの除外やアカウントへの措置につなげますが、誤検知で正規のプレイヤーを処分しないよう、複数の根拠や人による確認を組み合わせて判断します。 勝敗や資産、課金のように影響の大きい処理は、可能な範囲でサーバ側での検証も併用します。
まとめ
A2B攻撃は、スマホアプリを解析してAPIの仕様を把握し、APIサーバの脆弱性を突く攻撃です。 名称は新しいものの手法自体は以前から知られており、APIのエンドポイントが攻撃者に知られることは避けられず、それ自体は問題ではありません。
重要なのは、アプリが解析されることを前提に、APIサーバに致命的な脆弱性を残さないこと、そして改ざんされ得るクライアントにクリティカルな処理を置かず、サーバ側で判定することです。 ゲームなどクライアント側での処理が避けられない場合は、難読化、root化・改ざん検知、Play Integrity APIを組み合わせて解析コストを高め、サーバ側の検証と検知で補います。 なお、iOSアプリでもパッケージ（IPA）の解析やプロキシによる通信の解析は可能であり、WebサービスのAPIと合わせて同じ考え方が当てはまります。
スマホアプリとAPIサーバの診断に関するご相談
弊社の脆弱性診断では、スマホアプリの解析とAPIサーバの診断を組み合わせ、攻撃者と同じ視点でアプリから把握できる情報と、それを起点に成立する攻撃を検証しています。 公開中のアプリについてA2B攻撃への備えを確認したい場合や、クライアントとサーバの処理の分担を見直したい場合もご相談ください。