2026年10月13日、NICT（情報通信研究機構）の脅威情報分析チームLETTICEが、「A2B攻撃（App-to-Backend Attack）」という攻撃のやり方について注意をよびかけました。最近たて続けに起きている情報漏えいの原因の一つとされています。総務省も同じ日に、事業者にむけて注意をよびかけています。
この記事では、アプリやWebサービスを作る側から見て、A2B攻撃がどんなものか、どう守ればいいかを、NICTと総務省の発表にそってまとめます。
A2B攻撃とは
A2B攻撃は、だれでも手に入る公開アプリ（NICTが確認したのはAndroidアプリ）を解析して、その裏で動いているサーバー（バックエンド）をねらう攻撃です。
攻撃する人は、アプリを調べて、アプリがどのサーバーに、どんなAPI（アプリとサーバーがやりとりするしくみ）で通信しているかを知ります。そして、そのサーバーに合わせた攻撃をします。
作る側からすると、公開していないつもりのサーバーのしくみが知られてしまい、弱いところをピンポイントでねらわれることになります。
アプリに穴がなくてもねらわれる
大事なのは、アプリそのものに脆弱性がなくても、サーバー側の認証・認可や入力チェックに不備があれば、不正アクセスや個人情報の漏えいにつながるおそれがある、という点です。
総務省は、同じ問題はAndroidアプリにかぎらず、iOSアプリやWebサービスでも起こりうるとしています。また、NICTは、AIを使うことでアプリの解析や脆弱性さがしが速くなり、こうした攻撃がもっと多くのシステムに広がるおそれにも注意が必要だとしています。
ねらわれている脆弱性
NICTの注意喚起では、とくに次の脆弱性を重点的に点検するよう書かれています。
- IDOR／BOLA（認可の不備）：IDなどを書きかえるだけで、ほかの人のデータが見られてしまう
- SSRF：サーバーに、本来アクセスさせてはいけない先へリクエストを送らせてしまう
- RCE：外からサーバー上で好きなプログラムを動かされてしまう
- SQLインジェクション：入力した値で、データベースを勝手に操作されてしまう
守るためにやること（NICTの3つの対策）
NICTは、Androidアプリを公開している事業者にむけて、次の3つをお願いしています。
- 侵害の確認：公開しているAPIやサーバーを洗い出し、アクセスログなどから、あやしいアクセスや情報の不正な取得がないかを確かめる。
- 脆弱性の点検：上にあげた認可の不備、SSRF、RCE、SQLインジェクションなどの脆弱性や、設定の不備がないかを重点的に点検する。
- 暫定的な緩和策：使っていないAPIを止める、アクセスを制限する、監視を強める、認証情報を無効にして発行しなおす、など必要な対策をとる。
開発者が覚えておきたい考え方
総務省は、「アプリなど利用者側からの通信は、信頼できるものとはかぎらない」ことを前提に、アプリ側の制御だけにたよらず、サーバー側できちんと認証・認可や入力チェックをすることが大事だとしています。
NICTも、「公開アプリは解析されるもの」と考えて、バックエンドサーバーの安全を守ることが大事だとまとめています。
たとえば、アプリの画面で「自分のデータしか表示しない」ようにしていても、それだけでは守れません。サーバー側でも、リクエストしてきた人がそのデータを見てよいかを毎回確かめる必要があります。
まとめ
- A2B攻撃は、公開アプリを解析して、その裏のサーバーをねらう攻撃です。
- アプリに穴がなくても、サーバー側に不備があれば情報がもれるおそれがあります。
- 守るカギは、アプリから来る通信を信用せず、サーバー側で認証・認可と入力チェックをすることです。
- アプリやAPIを公開している人は、ログの確認、脆弱性の点検、不要なAPIの停止などを早めに進めましょう。
くわしい攻撃のしくみや、攻撃に関わるIoC（侵害指標）は、NICTの注意喚起（PDF）にのっています。
コメント