アプリ解析からAPIを攻撃！JPCERTの新報告で点検する認可とSSRF

JPCERT/CCは2026年10月21日、国内外のWebサービスを狙う攻撃インフラの調査結果を公開しました。攻撃者がAIを使って既知の脆弱性を探索し、APIを通じた攻撃を行っていたことを確認したとしています。新たに注目したいのは、公開Androidアプリの解析からバックエンドAPIを調べる活動と、SSRFを試すためとみられる仕組みが攻撃元で見つかった点です。

本稿はJPCERT/CC Eyesの10月21日付調査報告を中心に、Web開発者・サイト運営者が確認すべき境界を整理します。記事の公表日と、攻撃が行われた時期は同じではありません。国内で相次ぐ被害すべてを一つの攻撃者・ツール・侵入経路へ結び付けるものでもありません。

今回の調査で確認されたこと

報告では、APKと呼ばれるAndroidアプリの配布ファイルを解析し、APIを特定して検査する形跡が見つかりました。別の調査対象サーバーには、Flutterアプリの解析に使うBlutterやAndroid解析ツールjadxに関連するファイルもありました。また、特定の要求へHTTP 302を返すHTTPSサーバーのPythonスクリプトが示され、SSRF検査に使われた可能性が説明されています。

これらは攻撃元に残ったファイルや処理の観測です。ファイルがあるだけで、すべての標的への侵入成功や情報窃取が証明されたわけではありません。報告の別の節にあるMySQL、Jenkins、メールゲートウェイなどに関連するファイルは、今回の攻撃と直接関係しない別サーバーでの観測とされています。異なる調査対象を一つの侵入経路として描かないことが重要です。

以前に本サイトが扱ったARTEXの使用確認は、GMOサイバーセキュリティ byイエラエによる別の調査公表です。今回のJPCERT/CC報告は、APIの探索とアプリ解析を裏付ける追加の観測を含みます。ここでは特定ツール名の紹介を繰り返すのではなく、アプリからサーバーへ渡る信頼の境界を点検します。

アプリの配布物はサーバーの秘密を守る場所にならない

NICT CYNEXの10月13日付注意喚起は、公開アプリから接続先や仕様を調べ、裏側のサーバーを狙う手法をA2B攻撃（App-to-Backend Attack）と説明しています。アプリそのものに脆弱性がなくても、API側の認証・認可や入力検証の不備が情報漏えいへつながり得るという指摘です。

配布されたアプリには、通信先、データの構造、機能名、リクエストを作る処理などが含まれます。難読化やコンパイルは解析の手間を増やせても、利用者へ配った情報をサーバーだけの秘密には変えられません。「画面に出していないURL」「正規アプリだけが知るヘッダー」をアクセス許可の根拠にしていないか、設計段階から確認する必要があります。

JPCERT/CCの付録は、アプリに埋め込まれた秘密やAPI認証の仕組みが解析で明らかになるリスクを説明しています。そこで挙げられた外部研究の個別事例を、今回の国内被害企業で同じ秘密鍵が漏れたという事実へ置き換えることはできません。自社の点検では、配布物に何が含まれているかを自分たちのビルドと設定で確かめます。

署名の検証と利用者の認可を分ける

ここからは本サイトの実装・運用提案です。APIの署名が正しくても、その要求を出した利用者が他人の注文や会員情報を読んでよいとは限りません。全端末で共通する秘密が抽出可能なら、署名は正規アプリ以外からも再現される可能性があります。署名や端末識別の仕組みだけに、利用者ごとの権限確認を任せないでください。

説明用の仮想例として、注文詳細APIが注文IDを受け取る構成を考えます。ログインを確認した後、要求した利用者にその注文を見る権限があるかをサーバーで照合します。注文IDが推測しにくいこと、アプリ画面から他人のIDを選べないこと、要求が暗号化されていることは、この照合の代わりになりません。

• 一覧・詳細・検索・CSV出力のすべてでデータの所有者や組織境界を確認する
• 一般利用者から管理者用の処理へ到達できないか確かめる
• 読み取りだけでなく更新・削除・権限変更にも同じ認可を適用する
• 認証トークンの欠落・失効・形式不正を確実に拒否する
• 旧APIやアプリ画面から使わなくなった処理も対象に含める

検証は、自社が管理するテスト環境とテストアカウントで行います。別利用者・別組織の架空データを用意し、正しいトークンでも権限外の対象へアクセスできないことを確認します。成功応答の本文だけでなく、件数、存在確認、検索結果、エクスポートで情報が漏れていないかも見ます。

URL取得機能は転送先まで確認する

SSRFは、サーバーが利用者指定のURLを取得する機能などを悪用し、本来許されない宛先へ通信させる問題です。画像取り込み、URLプレビュー、外部資料の取得、Webhook検証など、Web運用で便利な機能が対象になり得ます。今回見つかった302応答の処理は、この境界を考える具体的な材料になります。

OWASPのSSRF防止チートシートは、HTTPクライアントのリダイレクト追従を無効にする対策を説明しています。本サイトでは、業務上追従が必要な場合も、初回URLだけを検査してその後を任せる設計を避け、各転送先へ同じ検証を適用することを提案します。

たとえば外部の画像URLを取り込む仮想機能で、最初の宛先が公開サイトでも、転送後に内部管理サービスへ向かう可能性を考えます。許可したプロトコル・ホスト・ポート、解決後のIP、IPv4とIPv6、接続時の宛先、転送回数を一つの処理として管理します。これは防御設計の例であり、今回の被害先で同じ機能が侵害されたという説明ではありません。

特定の取引先だけへ接続する機能なら許可リストを作りやすい一方、任意サイトを読む機能では管理が難しくなります。後者では、取得専用プロセスを分離して内部ネットワークやクラウドの管理情報へ到達できないようにし、応答サイズと時間も制限します。アプリケーションのURL検査と、ネットワーク側の送信制限を組み合わせる設計が必要です。

点検は公開APIの台帳から始める

最初の作業は、すべてのAPIへ無差別に検査要求を送ることではなく、責任者と実体の対応付けです。公開アプリの通信先と、APIゲートウェイ、リバースプロキシ、バックエンドのルート定義を照合します。古いアプリが使う旧版、検証環境、管理用のサブドメイン、委託先の処理を見落とさないようにします。

• アプリ名・配布版と接続先APIの対応を記録する
• APIごとの認証方式と必要権限を記録する
• 長期間有効な共通秘密や固定トークンの利用箇所を探す
• URL取得やファイル取り込みなど外向き通信を行う処理を特定する
• 公開をやめられる旧APIと更新が必要な実装を分ける
• 設定変更の担当者・期限・検証結果を残す

本番の秘密を調査用チャットや外部AIへそのまま渡さず、ビルド設定やソース、シークレット管理の記録を認証された経路で確認します。秘密が配布物へ含まれていた場合は、アプリから削除するだけでなく、既に配られた版を前提に失効と再発行、受け付け側の移行を設計します。

レート制限はIPアドレスだけで終わらせない

JPCERT/CCの国内組織向け注意喚起は、ログイン、パスワードリセット、検索などリスクの高い機能への個別制限や、APIごとのアクセス制御を求めています。今回の新しい調査結果を受けても、これらの基本が不要になるわけではありません。解析が効率化されれば、弱い入口を探す側の試行量に備える重要性が増します。

運用上は、送信元IPに加えてアカウント、トークン、対象リソース、機能別の負荷を対応付けます。正規の一括処理と不正な列挙を分ける基準を業務担当者と決め、拒否後の問い合わせや再試行で別の処理を圧迫しないかも見ます。レート制限は認可不備を修正するものではなく、許可してはいけない操作は1回目から拒否する必要があります。

侵害の確認と恒久修正を並行する

既に不審な操作や大量取得の疑いがある場合、認可を修正したことだけで調査を終えません。APIゲートウェイとアプリケーションのログ、認証記録、権限変更履歴、バックエンドからの外向き通信を時系列で照合します。アカウント追加やトークン発行が行われていないかも確認します。

JPCERT/CCは報告でIoCを公開していますが、既知のIPとの一致だけを侵害の判定基準にはできません。アドレスは変化し、正規利用へ戻ることもあります。照合する場合は観測時期と自社の通常通信を踏まえ、アクセス先と操作内容を合わせて判断します。攻撃者のサーバーへアクセスして独自調査する必要はありません。

ログには認証トークンや個人情報を無制限に保存せず、追跡に必要な識別情報と保護方法を決めます。記録が足りない範囲を無被害と扱わず、確認不能として残します。漏えいが疑われる資格情報は失効の対象と影響を整理し、必要に応じて組織のインシデント対応へ引き継いでください。

回帰試験に残すべき合格条件

対策を一度きりの点検で終えないために、認可とURL取得の条件を回帰試験へ残します。認可では、利用者Aが利用者Bのデータを読めないこと、一般権限で管理操作ができないこと、失効したトークンが拒否されることを確認します。正常な操作も同時に試し、業務を壊していないかを見ます。

URL取得では、管理下の試験用宛先を使い、許可外への転送が拒否されること、許可した先だけへ接続すること、巨大応答や遅い応答で処理が占有されないことを確認します。転送途中での拒否がログと監視へ反映されるかも合格条件に含めます。内部の実データを取得して成功を証明する試験は不要です。

API仕様やアプリの配布版が変わるたびに、この試験を再実行できる状態にします。担当者の記憶に頼らず、どのルートでどの権限判断が必要かをコードとテストで共有すると、旧APIの残存や新機能の確認漏れを減らせます。

今回の新事実をどう受け止めるか

今回の報告の価値は、AIという言葉だけでなく、攻撃元で確認されたアプリ解析とAPI探索の具体的な材料にあります。公開アプリを解析される前提で、サーバー側の認可、配布する秘密、URL取得先、操作記録を点検することが実務につながります。AIの利用確認は報告の観測範囲に限定し、個々の企業の侵入原因や被害規模は別に確認してください。

関連記事

本サイト：ARTEXの使用確認で何が分かった？国内企業へのAI攻撃と防御の優先順位。こちらは10月19日のGMOイエラエの調査公表を扱う記事です。本稿は10月21日のJPCERT/CCによる追加の調査報告を軸にしています。

URL取得機能の実装やWordPressでの確認を深める場合は、本サイト：AIにURLを読ませると何が危険？SSRFから内部ネットワークを守る対策も参照してください。事件の速報ではなく、取得ツールの境界と検証を扱う解説です。