2026.05.01 2026.05.14

【Web LLM編】プロンプトインジェクションと統合アプリの新攻撃面｜CTF思考フレームワーク #20

安全に生きたい編集部

📖 この記事はシリーズの一部です

「CTF思考フレームワーク」　Web脆弱性編　#20 / 公開中 10記事　→　シリーズ一覧を見る →

注意：この記事で扱う内容は、必ずCTF・自分の検証環境・許可された診断範囲でのみ確認してください。実在するLLM統合アプリ・エージェント・社内ボットに対して無断で試すことは、不正アクセスや業務妨害につながる恐れがあります。

Webサービスに組み込まれたLLM（チャットボット、要約、検索拡張）は、まったく新しい攻撃面を運んできました。プロンプトインジェクション、Indirect Injection、ツール呼び出しの悪用…2023年以降、OWASP Top 10 for LLMが整備されるほど成熟してきた分野です🤖

LLMは便利だけど、「ユーザーの言葉」と「指示」を区別できないのが本質的な弱点。そこを突かれます。

難易度：★★★（中級〜上級）

LLM統合アプリ特有の新攻撃面。プロンプトインジェクションは2025年の主役級脅威🤖

LLM統合アプリは「言語モデルが指示を勝手に実行する」新攻撃面を持ってるんだ🤖

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：攻撃者は何を考える？
🔬 検証フェーズ：どうやって確かめる？
⚔️ 攻撃フェーズ：CTFで見る典型パターン
🛡️ 防御フェーズ：どう守る？
🔑 あわせて見直したい基本対策
⚠️ よくある落とし穴
🧰 ツール早見表
🎓 本気で学びたい人へ
📚 もっと深く学びたい人へ
📚 次に読みたい
🧪 自分で検証してみる
⚖️ 大事なお約束

👀 観察フェーズ：まず何を見る？

まずアプリがどんなツールをLLMに与えてるかを観察！メール送信、DB検索、ファイル読込などが要注意🔍

LLM搭載アプリで一番危険なのは「外部由来のテキストをLLMが読む」設計。メール、Webページ、ファイル…それ全部「指示として解釈」される可能性があります。

チャット・要約・コーディング支援など、外部入力(Web、メール、PDF、画像)をモデルに食わせている箇所はインジェクションの入り口です👀

モデルって「文の途中の指示」をシステム命令として読んじゃうからね…😨

🤔 仮説フェーズ：攻撃者は何を考える？

Web LLM攻撃の典型は4ジャンル。

💬 仮説①：直接プロンプトインジェクション

ユーザー入力欄に、システム指示を上書きしようとする文章を入れることで、LLMの応答方針やツール利用判断が意図しない方向に誘導されるケースです。

📨 仮説②：間接インジェクション

LLMが取り込むメール・Webページ・PDFに隠し指示を埋め込み、後で「ユーザーの依頼」のように実行させる。

🛠️ 仮説③：ツール濫用

LLMに与えたsend_email()やfetch_url()を攻撃者の意図で呼ばせる。エージェント時代の主要リスク。

📉 仮説④：データ漏洩・モデル抽出

LLMアプリの設計や権限管理が不十分だと、システムプロンプト、内部情報、RAGで参照した機密文書などが意図せず出力される恐れがあります。

LLM攻撃の鍵は「LLMから見て、信頼できる指示と信頼できない指示の区別がつかない」点。アーキテクチャレベルで分離する必要があります。

「LLMは入力を絶対に信じない」前提で守らないとダメなんだね💡

🔬 検証フェーズ：どうやって確かめる？

CTFやローカル検証環境では、入力の末尾にシステム指示風の文字列を加えた場合に、モデルがそれを命令として扱ってしまうかを観察！実サービスへは絶対に投げない🧪

WebページやPDFに、人間には目立ちにくい形で埋め込まれた外部由来テキストも、エージェントがそのまま処理してしまうケースがあるんだね😱

⚔️ 攻撃フェーズ：CTFで見る典型パターン

Web LLMで起こりうる問題はこの3つ。

ここでは実サービスに対して試せる手順ではなく、CTFやローカル検証環境でよく出る「考え方」だけを整理します。具体的な検証は、必ず自分の環境・CTF問題・許可されたラボ内で行ってください。

① エージェントによるコード実行リスク

LLMにOSコマンド実行などの強力なツールを与えていると、外部由来テキストの指示によって意図しないコマンドが実行される恐れがあります。コンテナ前提でも、隔離設定が甘いと被害が広がります。

② 機密データへのアクセスリスク

チャット履歴やRAGで参照される内部ドキュメントを本来のアクセス権限を超えて出力させる恐れがあります。ドキュメント側のアクセス制御とLLMの利用権限を一致させる必要があります。

③ 間接的な意思誘導

間接インジェクションにより、検索要約や回答に外部由来の偽情報が混入する恐れがあります。出力をそのまま意思決定に使うと、ユーザーが誘導されるリスクが生じます。

CTF{treat_llm_output_as_untrusted_user_input}

結論：「LLMの入力も出力も、すべて信頼できないユーザー入力として扱う」。Webアプリ視点では、LLMはユーザーと同等の存在です。

特に、LLMの出力をそのままHTML表示・SQL・API呼び出し・メール送信・ファイル操作に渡さないことが重要です。LLMの前後に、権限チェック・出力検証・人間承認を置きます。

🛡️ 防御フェーズ：どう守る？

Web LLM対策の3原則！🛡️

🛂 すべての入力を「データ」として扱う

ユーザー入力・取得した文書を明確にデータ枠として渡し、システムプロンプトと混ぜない。Anthropicや各社のベストプラクティス。

🔐 ツールを最小権限・人間承認

送金・削除・送信などの破壊的操作は人間の確認を挟む。LLMが単独で実行できるツールは読み取り系に限定。

👁️ 出力ガードレールと監視

モデル出力を機密キーワードや不審操作で検査。異常レスポンスはブロック＆ログ。

📚 RAGはドキュメント単位でアクセス制御

検索拡張生成では、ユーザーが本来アクセスできる文書だけを検索対象にします。LLMに渡す前の検索段階で、権限・部署・プロジェクト単位のアクセス制御を必ず適用します。

🧾 ツール実行前にポリシーチェック

LLMがメール送信・削除・外部API呼び出しなどを行う前に、操作内容・対象・権限・リスクをアプリ側で検証します。LLMの判断だけで高リスク操作を実行しない設計にします。

「LLM＝信頼できないユーザー」として境界設計するのが正解だね💪

🔑 あわせて見直したい基本対策

Web LLMの直接対策ではありませんが、セキュリティ全体を見直す際に、パスワードの使い回しも同時に改善しておくと安心です。パスワード管理ツールを使って、サービスごとに異なるパスワードを管理しましょう。

※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。

⚠️ よくある落とし穴

システムプロンプトに機密情報（APIキー、内部URL）を直接書く。
LLMの応答をそのまま innerHTML で描画。
RAGで参照するドキュメントに対する事前サニタイズなし。
ツール呼び出しを全部Auto実行（Human-in-the-loopなし）。
「プロンプトで縛れば安全」と思い込み、構造的分離を怠る。
メール要約・PDF処理で外部由来テキストを「同等の信頼度」でLLMに食わせる。

🧰 ツール早見表

ツール・資料	用途	ひと言
OWASP Top 10 for LLM Applications	リファレンス	LLM特有のリスク分類の標準
PortSwigger Web LLM Lab	許可された学習環境	CTF風ラボで体系的に学ぶ
Lakera Guard / Rebuff	入力フィルタ・出力検査	防御側ガードレールツール
各社プロバイダのベストプラクティス	設計指針	Anthropic、OpenAI、GoogleのSafety文書
Human-in-the-loop設計	破壊的操作の制御	送信・削除・送金は人間承認を必須に