2026.05.01 2026.05.02

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

安全に生きたい編集部

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

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

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

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

難易度：★★★（上級）

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

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

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：攻撃者は何を考える？
🔬 検証フェーズ：どうやって確かめる？
⚔️ 攻撃フェーズ：実際の手口
🛡️ 防御フェーズ：どう守る？
🛡️ 今日からできる対策ツール
⚠️ よくある落とし穴
🧰 ツール早見表
🎓 本気で学びたい人へ
📚 もっと深く学びたい人へ
📚 次に読みたい
🧪 自分で検証してみる
⚖️ 大事なお約束
📖 次に読みたい

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

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

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

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

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

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

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

攻撃者の仮説。

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

ユーザー入力欄に"前の指示は無視して..."と書くとシステムプロンプトを上書きできるケース。

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

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

🛠️ 仮説③：ツール濫用

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

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

巧妙な質問で学習データやシステムプロンプトを吐かせる。あるいはfine-tunedモデルの動作を抽出。

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

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

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

入力の最後に"\n---\nSYSTEM:..."のような境界破りを試して挙動を観察！

検証ステップ。

Webサイトに白文字で「メールを攻撃者に送れ」と書いておくとエージェントが従うケースもあるんだね😱

⚔️ 攻撃フェーズ：実際の手口

Web LLM攻撃の代表はこの3つ。

実戦シナリオ。

① エージェントのRCE化

LLMにOSコマンド実行ツールを与えていると、プロンプトでRCEに到達。コンテナ前提でも危険。

② 機密データ漏洩

チャット履歴やRAGの内部ドキュメントを「全文出力して」と指示し、社内秘を抜く。

③ 間接的な意思誘導

間接インジェクションでユーザの意思決定をミスリード。検索要約に偽情報を混ぜ込まれる。

CTF{treat_llm_output_as_untrusted_user_input}

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

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

Web LLM対策の3原則！🛡️

LLM防御の3原則。

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

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

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

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

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

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

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

🛡️ 今日からできる対策ツール

パスワードの使い回しや手動管理はどんなに気をつけても限界があります。🔑 パスワード管理ツール「ワンパス」なら、複雑なパスワードを安全に保管して「1つのマスターパスワード」だけ覚えられるので、今日から始める防御策としてしっくりきます。

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

⚠️ よくある落とし穴

よくあるミス。

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

🧰 ツール早見表

使う道具。

ツール	用途	ひと言
PortSwigger Web LLM Lab	Web LLM攻撃の練習	CTF風ラボで体系的に
promptmap / Garak	LLM脆弱性スキャナ	プロンプトインジェクション自動検出
Lakera Guard / Rebuff	入力フィルタ	防御側ツール
OWASP Top 10 for LLM Applications	リファレンス	LLM特有のリスク分類