情報漏えいを招く新手口「A2B攻撃」とは？ NICTが暴いた実態と緊急対策：Androidの「公開アプリ」を解析してバックエンドサーバを狙う（2/2 ページ）

NICTが注意喚起する「A2B攻撃」は、国内で相次ぐ情報漏えい事案の原因の一つとなる攻撃手法だ。そもそもA2B攻撃とは何なのか。攻撃の仕組みと企業が取るべき対策を解説する。

[＠IT]

緊急対策：まずは侵害の確認と被害拡大の防止を

　LETTICEは、Androidアプリケーションを公開する事業者に対して、まず自社が公開するAPIや、インターネットに公開しているサーバなどに侵害がないかどうかを確認するよう推奨する。アプリケーションが利用するAPI（旧バージョンを含めて）やサブドメイン、検証環境、クラウドサービスも含めて公開範囲を洗い出し、情報漏えい事案の判明が集中し始めた2026年8月以降のアクセスログやAPIログ、認証ログを調べる。可能であれば、それ以前のログも確認する。

　ログでは、攻撃に関連するIoC（Indicators of Compromise：侵害指標）との一致に加えて、認証なしでの集中的な情報取得や連番IDを使った情報取得、他の利用者の情報の閲覧・変更、認証トークン（APIへのアクセス時の認証・認可に使う情報）の不審な発行、管理機能の利用など、通常とは異なる操作がないかどうかを確認する。IoCが一致しても侵害が成功したとは限らないことから、ログや通信内容を基に総合的に判断する必要があるという。

　被害拡大を防ぐためには、業務への影響を考慮しながら、国外および不要なアクセス元からの通信や、不要な公開APIおよび管理機能、検証環境へのアクセスを一時的に制限する。頻繁なアクセスや連続した識別子の指定を監視し、必要に応じてレート制限（一定時間内に受け付けるリクエスト数を制限する仕組み）やWebアプリケーションファイアウォール（WAF）を適用する。

　認証トークンなどの認証情報の漏えい・悪用が疑われる場合は、無効化して再発行する。加えてAPIの認証・認可や入力検証などに不備があれば、速やかに修正する。リスクを十分に下げられない場合は、該当するAPIや機能、必要に応じてサービス全体の一時停止も検討する。

恒久対策：サーバ側の認証・認可と入力値検証を徹底

　恒久対策としては、攻撃者が利用者向けのAndroidアプリケーションを介さず、APIに直接リクエストを送信することを想定し、バックエンドサーバの設計・実装を見直す必要があるとLETTICEは説明する。例えば会員IDなどの識別子を変更することで、他者の情報を閲覧・変更できないかどうか、認証・認可に不備がないかどうか、外部入力を介してデータベースや内部ネットワークに不正アクセスできないかどうかを点検する。管理者向けの操作画面や管理用APIなどを不適切に公開していないかどうかも確認するとよいという。

　公開アプリケーションの解析を完全に防ぐことは困難だ。攻撃者に内部構造やAPIの仕様を把握されても不正アクセスを許さないように、サーバで認証・認可や入力値検証を徹底することが重要になる。

　A2B攻撃の手法は、AppleのモバイルOS「iOS」向けアプリケーションやWebサービスのAPIでも悪用される可能性がある。これらを自社で開発・提供する企業はもちろん、開発・運用を外部に委託しているユーザー企業も、APIの認証・認可などに不備がないかどうかを確認する必要がある。NICTは開発・運用の委託先やセキュリティ専門事業者に相談して、点検を進めるよう案内する。