AI時代のA2B攻撃対策 ―アプリ診断で確認したいAPIの安全性

Share
AI時代のA2B攻撃対策 ―アプリ診断で確認したいAPIの安全性アイキャッチ画像

アプリのセキュリティを確認するとき、接続先のAPIまで同じ範囲で確認できているでしょうか。公開アプリを解析して接続先のサーバーを狙うA2B攻撃や、AIを利用した攻撃に関する報告を受け、アプリとAPIを一体で検証する重要性が高まっています。本記事では、公開された調査結果を整理し、企業が診断の依頼内容と運用体制を見直すための観点を考えます。

A2B攻撃で問われるアプリとサーバーの関係

国立研究開発法人情報通信研究機構(NICT)の脅威情報分析チームLETTICEは、2026年10月13日、公開Androidアプリの解析結果を利用して接続先のバックエンドサーバーを攻撃する手法を、A2B攻撃(App-to-Backend Attack)として公表しました*1。アプリ本体に脆弱性がなくても、サーバー側の認証・認可や入力値の検証に不備があれば、情報漏洩につながり得るとしています。

NICTは、同様の問題がAndroidアプリに限らず、iOSアプリやWebサービスのバックエンドAPIでも発生する可能性があると指摘しています。アプリの種類にかかわらず、接続先のサーバーが不正な要求を適切に拒否できるかを確認することが重要です。

APIは、アプリがサーバーに情報の取得や処理を依頼するための窓口です。事業者が想定する画面操作だけを確認しても、その窓口に直接届く要求への安全性までは説明できません。公開したアプリから通信の仕組みを知られた場合に、サーバーがどこまで自力で不正な操作を拒否できるか。その確認が必要になります。ここで、A2B攻撃という経路と、AIという支援手段は分けて捉える必要があります。A2Bという名称が指すのは、アプリの解析情報をバックエンドへの攻撃に利用する関係です。AIの利用が確認されたかどうかは、別に証拠を確かめるべき論点です。

AIの悪用について公表資料から分かること

一般社団法人JPCERTコーディネーションセンター(JPCERT/CC)は10月15日、攻撃元サーバーの調査で、攻撃者がAIを利用して既知の脆弱性のスキャンやAPI経由の攻撃を行っていたことを確認したと報告しました*2。Androidアプリの配布ファイルであるAPKの解析と、関連APIの脆弱性を調べた痕跡も紹介しています。さらにGMOサイバーセキュリティ byイエラエ株式会社は10月19日、日本企業に対する侵害事案の攻撃元インフラで、自律型ペネトレーションテストシステムARTEXの利用を確認したと公表しました*3。同社は調査対象の範囲を限定して記述しています。

また、CrowdStrikeは10月7日、韓国の金融機関を狙った活動に関係するインフラから、ARTEXの設定ファイルやAIツールのセッション履歴などを確認したと報告しています*4。さらにCrowdStrikeは10月29日、攻撃グループ「VAPOR PANDA」がARTEXを利用し、世界の200以上の組織を標的にした活動を報告しました*5。複数の組織に対する並行した侵入活動が確認されており、AIを利用した攻撃の規模拡大を示す事例といえます。ただし、これは国内のA2B攻撃とは別の調査結果です。

これらは、AIを使った攻撃を企業が現実の対応課題として扱う根拠になります。ただし、日本の不正アクセス全体に占める割合を示す統計ではありません。また、同じツールが使われたことだけで、各報告を同一の攻撃者による活動と結び付けることもできません。企業への示唆として考えたいのは、アプリやAPIの仕様を読み解く作業にAIが使われることで、個々のシステムを調べる負担が下がる可能性です。その場合、独自の仕様であることや、接続先が目立たないことを、安全性の根拠にし続けるのは難しくなります。これは公表された観測を踏まえた本稿の考察であり、攻撃時間の短縮率や被害の増加率を実測したものではありません。

AIを利用した攻撃と、Webアプリケーションの診断・監視については、こちらの記事でも解説しています。あわせてぜひご覧ください。
「AIエージェントを悪用したECサイト攻撃 ―カード情報窃取の報告から考える対策」

診断済みという説明に確認範囲を添える

A2B攻撃への備えとして、まず確認したいのは過去の診断報告書と依頼仕様です。アプリ本体、通信先のAPI、認証後に利用できる機能のうち、どこまでが対象だったのか。対象外となった機能や、その後に追加・変更された処理が残っていないか。診断の有無に加え、確認した範囲と時点を説明できる状態にすることが出発点です。

例えば、会員が自分の予約情報を確認するサービスを考えてみます。ログインできることと、その会員が対象の予約情報を閲覧してよいことは、別の確認です。認証では利用者本人であることを確かめ、認可では、その利用者にどの操作を認めるかを判断します。この例は説明のための仮定であり、今回の被害事例を再現したものではありません。

「OWASP API Security Top 10 2023」では、「オブジェクトレベルの認可不備(Broken Object Level Authorization:BOLA)」が最も重要なリスクの一つとして挙げられています。利用者がログイン済みでも、アクセスするデータごとに権限を確認する必要があります。診断を依頼する際には、画面の動作確認だけでなく、複数の利用者や役割の間でデータへのアクセスが適切に分離されているかも、確認項目に含めたいところです。また、NICTとJPCERT/CCは、認可不備に加え、SSRFやSQLインジェクションなどの脆弱性にも注意を呼びかけています。APIの診断では、利用者ごとのアクセス権限だけでなく、入力値の検証や外部への通信処理、不正な大量アクセスへの対策も確認する必要があります。

図:アプリから業務データまでの診断と運用の確認範囲

アプリから業務データまでの診断と運用の確認範囲の図
出典:国立研究開発法人情報通信研究機構(NICT)脅威情報分析チーム LETTICE、OWASP Foundation「API1:2023 Broken Object Level Authorization」「API9:2023 Improper Inventory Management」「Logging Cheat Sheet」をもとに弊社作成。
※個別事案の再現や攻撃成功率を示す図ではありません。権限管理を中心に示し、入力値検証など他の確認項目は省略しています。

認証と認可の違いや、予約情報へのアクセス制御については、skyticketの不正アクセス事例を取り上げた記事でも解説しています。あわせてぜひご覧ください。
「skyticketで約1,464万件の情報流出 ―3つの不正アクセス経路から考えるWebサービスのセキュリティ対策」

接続先の一覧を担当部署の境界で分断しない

APIの棚卸しでは、現在のアプリが利用する接続先だけを集めても十分とは限りません。OWASPは、管理が不十分な旧バージョンや不要な公開APIをリスクとして挙げ、APIの稼働環境、バージョン、アクセスを認める範囲などの管理を推奨しています。

この指摘を実務に落とし込むなら、APIの一覧に担当者、取り扱うデータ、診断日、停止できる条件を結び付ける方法が考えられます。アプリ開発会社は接続先を知っていても、サーバー運用会社は旧版APIを止めてよいか判断できない、といった状態を避けるためです。こうした管理項目は、本稿からの運用上の提案です。委託しているシステムについても、診断の責任範囲と修正の責任範囲を突き合わせます。重要なのは、担当を決めるだけでなく、対象外や未確認の箇所が残ったときに、誰が追加確認を手配するかまで決めておくことです。新しいAPIを追加する際にも、この一覧を更新する手順を組み込めます。

監視の記録を対応の判断につなげる

予防の点検と併せて、運用中に何を記録し、どう調査するかも確認します。OWASPの「Logging Cheat Sheet」は、利用者、操作対象、操作内容、結果といったアプリケーション固有の情報が、インフラのログだけでは得られない場合があると説明しています。この観点から、利用者と対象データの関係、通常と異なる取得量、権限の拒否状況などを追跡できるか検討します。ただし、記録を増やすためにパスワードやアクセストークンをそのまま保存するのは避け、必要な情報と保護方法を設計する必要があります。

さらに、異常を検知した後の連絡先や、APIの利用制限を決める担当者を、サービス運営側と共有しておきます。停止による業務影響を誰が評価するかも事前に決めておけば、調査の着手後に責任範囲の確認から始めずに済みます。監視を契約している場合も、APIの業務上の異常まで監視対象に含まれるかを確認したいところです。

AI時代の対策を具体的な確認事項に変える

A2B攻撃とAI悪用の報告を受け、企業は公開アプリから把握できるAPIと、これまで安全性を確認してきた範囲を照合する必要があります。未確認のAPIや機能があれば、認証・認可、入力値検証などの点検を進め、運用中の監視体制も見直すことが重要です。診断を依頼する際には、アプリ本体だけでなく、接続先のAPIやバックエンドサーバーも対象に含まれているかを確認してください。公開アプリとサーバーを一体で捉え、継続的に安全性を検証することが、A2B攻撃への備えにつながります。

【関連記事】
国内で相次いだ不正アクセス事例と、AI時代に企業が確認すべき対策を紹介しています。
「国内で相次ぐ情報漏洩・不正アクセス|焼肉きんぐなど14事例とAI時代の対策」

【参考情報】

編集責任:木下

ウェビナー開催のお知らせ

最新情報はこちら


Security NEWS TOPに戻る
バックナンバー TOPに戻る