AIリスク2026年10月22日（木）
② 日本のアプリ・API攻撃から学ぶ、サーバー側の認可
JPCERT/CCは、AIを用いたスキャンとAPIへの攻撃を報告しました。アプリから判明する情報、APIが許す操作、バックエンドの接続先をそれぞれ確認します。
本文
JPCERT/CCは10月15日、日本で確認された一連の不正アクセスの調査結果を公開しました。既知の脆弱性のスキャンにAIが使われ、APIを経由する攻撃が確認されました。攻撃者のサーバーには、APKの解析やSSRFのテストの形跡がありました。
解析ツールのBlutter、jadxに関係するファイルと、SSRFを試すPythonコードが見つかりました。攻撃者が使ったAIモデルの名前や、攻撃の全工程を自律型エージェントが実行したことは公表されていません。
- 01
公開アプリを解析
リバースエンジニアリングにより、バックエンドのURLや認証の流れを把握できます。
- 02
APIへの経路を探る
アプリ内の認証情報や、アプリを過度に信頼するAPIが見つかる可能性があります。
- 03
バックエンドを試す
SSRFや認可・設定の不備を調べ、データや内部サービスへの到達を試みます。
対応の手順：外部との境界から内部システムまで
- 01
アプリとAPIを棚卸し
本番、テスト、旧版アプリ、コンテナ、委託先のバックエンドを対象にします。
対応策を見る関連情報 1件
TWISA会員企業の対策
アプリとAPIを棚卸し
本番、テスト、旧版アプリ、コンテナ、委託先のバックエンドを対象にします。
- 02
認証情報と通信を制限
長期有効な秘密情報をアプリに入れず、リダイレクト後の宛先まで検証して内部への通信を制限します。
対応策を見る関連情報 1件
TWISA会員企業の対策
認証情報と通信を制限
長期有効な秘密情報をアプリに入れず、リダイレクト後の宛先まで検証して内部への通信を制限します。
- 03
認可を検証
権限の異なるテストアカウントで、データと操作ごとの認可をサーバー側で確認します。
対応策を見る関連情報 1件
TWISA会員企業の対策
認可を検証
権限の異なるテストアカウントで、データと操作ごとの認可をサーバー側で確認します。
- 04
ログと合わせて再検証
認可されていない要求をバックエンドが拒否することを確かめ、警報と実際の応答を照合します。
対応策を見る関連情報 1件
TWISA会員企業の対策
ログと合わせて再検証
認可されていない要求をバックエンドが拒否することを確かめ、警報と実際の応答を照合します。
アプリの版、API、キー、委託先、国境をまたぐデータの流れを整理します。
許可された業務通信のみを通し、各層で防御を行います。
- 01
公開アプリ
モバイルアプリ、API、キー
秘密情報を端末に置かないアプリのバイナリに再利用可能な認証情報がないか確認します。
- 02
APIの認可
ID、ロール、データへのアクセス
操作ごとに認可呼び出し元と対象データをサーバー側で検証します。
- 03
バックエンドの外部通信
URL取得とリダイレクト
SSRFの経路を制限最終的な接続先を検証し、内部サービスへの接続を制限します。
各層のログと通信データを集約し、監視と対応に活用します。
- 監視と検証必要に応じてAPI単位でレートを制限し、権限を越える試行や不審な外部通信を調べます。
TWISA会員のソリューション
アプリとAPIを棚卸し
本番、テスト、旧版アプリ、コンテナ、委託先のバックエンドを対象にします。
認証情報と通信を制限
長期有効な秘密情報をアプリに入れず、リダイレクト後の宛先まで検証して内部への通信を制限します。
認可を検証
権限の異なるテストアカウントで、データと操作ごとの認可をサーバー側で確認します。
ログと合わせて再検証
認可されていない要求をバックエンドが拒否することを確かめ、警報と実際の応答を照合します。
CIXでの議論につなげる
今後のCIXでは、アカウントをまたいだAPIの検証やURL取得の制御を題材にできます。アプリが解析された後も認証、データごとの認可、通信先の制限がそれぞれ機能するかという点で、第2回の多層防御の議題につながります。
情報源と関連資料
更新日：2026/10/25。