安全でない出力処理

安全でない（または不適切な）出力処理とは、大規模言語モデルが生成した出力を、後続システムに渡す前、ユーザーインターフェースに表示する前、またはバックエンドプロセスで実行する前に、検証、サニタイズ、エンコードしないことを指します。

安全でない出力処理とは

アプリケーションにLLMを統合すると、通常は生成されたテキストを受け取り、ブラウザ、データベースクエリ、システムコマンド、別のアプリケーションコンポーネントなどに渡します。安全性を検証せずにその生成コンテンツを使用すると、安全でない出力処理が発生します。

根本的な問題は、信頼にあります。開発者は、プロンプトやモデルを制御しているため、出力は予測可能で無害だと考えがちですが、必ずしもそうとは限りません。LLMは、トレーニングデータから学習したパターンに基づき、ユーザー入力の影響を受けて応答を生成します。巧妙に作成されたプロンプトによって、実行可能コード、悪意のあるスクリプト、SQLフラグメント、システムコマンドなどを含む出力がモデルから生成され、アプリケーションがそれを信頼できるデータとして処理してしまう可能性があります。

この脆弱性は、保護されていないユーザー入力によってブラウザ上でコードが実行される、クロスサイトスクリプティング（XSS）などの従来のインジェクション脆弱性に類似しています。異なるのは、この場合の「ユーザー入力」がモデルの出力である点です。この出力は、プロンプトインジェクションによって間接的に操作されることもあれば、単にモデルの応答パターンから生じることもあります。

アプリケーションがLLMの出力を、信頼できない外部入力と同様に慎重に扱わない場合、安全でない出力処理がセキュリティ上の問題となります。検証とエンコーディングを行わなければ、その出力を受け取るあらゆるシステムに脆弱性が生じる可能性があります。

安全でない出力処理が危険なのはなぜですか？

標準的なセキュリティ対策では、入力元が予測可能であることを前提としています。フォームには定義済みのフィールドがあり、APIにはスキーマがあります。ユーザー入力は既知のチャネルを通じて届きます。一方、LLMの出力は動的に生成され、敵対的なコンテンツを含む可能性のあるプロンプトの影響を受け、事実上あらゆる文字列を生成できるため、こうした前提は成り立ちません。

この予測不能性により、LLMを活用したアプリケーションでは、安全でない出力処理が特に危険になります。モデルが何千回も有効で有用な応答を生成した後、プロンプトが予期しない方向に変化したことで、スクリプトタグやシェルコマンドを含む応答を生成する可能性があります。有限のパターンマッチングや許可リストに依存するセキュリティ制御では、考えられるあらゆる出力を予測することは困難です。

LLMの出力は複数の後続システムに渡されることが多いため、攻撃対象領域も拡大します。1つの応答がブラウザに表示され、データベースに記録されたうえで、APIに渡される場合があります。各送信先にはそれぞれ固有の脆弱性があり、いずれかの時点で出力が安全でない方法で処理されると、悪用の足掛かりとなる可能性があります。

さらに、モデルの更新やファインチューニングに伴い、LLMの動作は時間の経過とともに変化する可能性があります。あるモデルバージョンでは安全だった出力が、別のバージョンでは悪用可能になることもあります。出力を本質的に信頼できないものとして扱わないアプリケーションには、条件が変化したときに初めて顕在化する潜在的なリスクがあります。

安全でない出力処理はどのように発生するのか？

安全でない出力処理は、LLMが生成する内容と、後続システムがその内容を解釈する方法との間にあるギャップを悪用します。攻撃者はプロンプトを操作してモデルに出力を生成させ、その出力がサニタイズされずに処理された場合に、受信側システムで意図しない動作を引き起こします。

信頼できない出力をアクティブな入力として使用：LLMの出力はテキスト文字列ですが、その文字列には、JavaScript、HTML、SQL、シェルコマンド、埋め込みスクリプトを含むMarkdownなどの実行可能なコンテンツが含まれる場合があります。アプリケーションがこの出力をサニタイズせずにインタープリター、シェル、レンダリングエンジンへ直接渡すと、そのコンテンツが実行されます。たとえば、<script>タグを含む応答を生成させるよう設計されたプロンプトは、その出力がエンコードされずにWebページへ挿入されると、XSSペイロードになります。
クライアントのブラウザーまたはUIにレンダリングされる出力：LLMが生成したコンテンツをブラウザーやアプリケーションインターフェースに表示すると、埋め込まれたHTMLやJavaScriptがユーザーのコンテキストで実行される可能性があります。これにより、クロスサイトスクリプティング、セッションハイジャック、認証情報の窃取、UIの改ざんが行われるおそれがあります。出力をエンコードせずにモデルの出力を直接レンダリングするチャットボット、コンテンツジェネレーター、AIアシスタントは、特にこうしたリスクにさらされます。
バックエンドでの実行と権限昇格：最も深刻なケースは、LLMの出力が実行機能を持つバックエンドシステムに到達した場合に発生します。出力がサニタイズされずにシェル、eval()関数、またはデータベースクエリに渡されると、攻撃者はリモートコード実行、データ流出、権限昇格を実現できる可能性があります。アプリケーションがその出力を実行する場合、有効なSQLインジェクション文字列やシステムコマンドを生成するよう誘導されたモデルによって、バックエンド全体が侵害されるおそれがあります。

一般的な例と実際の攻撃シナリオ

LLMを統合したアプリケーションでは、安全でない出力処理がいくつかの典型的なパターンとして現れます。

LLMの応答をエスケープせずにHTMLとしてレンダリングするカスタマーサービス用チャットボットは、XSSの攻撃経路となる可能性があります。攻撃者は、モデルの応答にスクリプトタグを含めさせるように設計したプロンプトを送信します。その応答が別のユーザーのブラウザでレンダリングされるとスクリプトが実行され、セッショントークンが盗まれたり、フィッシングサイトにリダイレクトされたりする可能性があります。

LLMの出力を使用してデータベースクエリを構築するアプリケーションも、SQLインジェクションのリスクに直面します。モデルに商品検索クエリを生成するよう指示し、攻撃者がモデルの応答に ; DROP TABLE users;-- を追加させる入力を細工した場合、その出力をパラメーター化せずにSQL文へ連結するアプリケーションは、悪意のあるコマンドを実行してしまいます。

さらに、LLMが生成したコードや構成を組み込むCI/CDパイプラインには、コマンドインジェクションの脆弱性があります。デプロイスクリプトの生成を指示されたモデルが操作され、リバースシェルコマンドを含める可能性があります。パイプラインがレビューせずにそのスクリプトを実行すると、攻撃者はビルドインフラストラクチャにアクセスできるようになります。

安全でない出力処理は、サーバーサイドリクエストフォージェリ（SSRF）を引き起こす可能性もあります。ユーザー入力に基づいてURLやAPI呼び出しを生成するLLMが欺かれ、内部ネットワークリソースへのリクエストを生成するおそれがあります。アプリケーションが検証せずにそれらのリクエストを実行すると、攻撃者が内部システムを探索したり、データを外部に持ち出したりする可能性があります。

エージェント型AIとRAGアーキテクチャのリスク

企業における最新のAI活用が拡大・高度化するにつれ、安全でない出力処理に伴うリスクも変化しています。現在、モデルは接続先のアプリ、ツール、API、データベース、エージェントに入力や指示を提供します。この接続性は悪意のある攻撃者に機会をもたらします。攻撃者は間接プロンプトインジェクションの手法を用いて自律型AIエージェントを欺き、承認されていないAPIやツールの呼び出しを実行させたり、データベースに悪意のある書き込みを行わせたり、検索拡張生成（RAG）パイプラインからデータを抽出させたりする可能性があります。

自律機能が高度化し、エージェントがビジネスクリティカルなシステムにアクセスするケースが増える中、出力が後続のシステムやツールに到達する前に、その妥当性を検証し、無害化する必要があります。定義された権限を超える出力は、制限する必要があります。

安全でない出力処理を防ぐ方法

安全でない出力処理を防ぐには、信頼できないユーザー入力と同様に、LLMの出力も厳格に扱う必要があります。以下の対策は、一般的な攻撃ベクトルによるリスクの軽減に役立ちます。

LLMの出力を信頼できない入力として扱う：モデルが生成したすべてのコンテンツに対して、ゼロトラストの姿勢を採用します。プロンプトの構成方法や適用された制約にかかわらず、出力には悪意のあるコンテンツや不正な形式のコンテンツが含まれる可能性があるものと想定してください。後続処理で使用する前に、検証とサニタイズを行います。
出力の検証とサニタイズ：LLMの出力をレンダリングまたは実行する前に、コンテキストに応じた適切なエンコーディングを適用します。ブラウザーに表示する出力はHTMLエンコードします。モデルの出力をSQL文字列に連結するのではなく、データベースクエリをパラメーター化します。出力をシステムコマンドに渡す必要がある場合は、シェルのメタ文字をエスケープします。可能な場合は許可リストを使用し、出力を想定されるパターンに制限します。
厳格なアクセス制御と最小権限のアプローチ：LLMの出力を処理するコンポーネントの権限を制限します。サービスがモデルによって生成されたコマンドを実行する場合は、実行可能なコマンドとアクセス可能なリソースを制限してください。LLM関連の処理を機密性の高いシステムから分離します。攻撃が成功した場合でも影響を限定できるよう、最小権限の原則を適用してください。
人によるレビューと出力フィルタリング：コード生成、金融取引、管理操作などのリスクが高いユースケースでは、実行前に人によるレビューを必須とします。既知の危険なパターンに一致する出力にフラグを付けるか、ブロックする自動フィルタリングを実装します。悪意がある可能性のある出力を下流システムに到達する前に検出するため、コンテンツ分類器を使用します。
ログ記録、監視、監査：LLMの出力と、アプリケーション全体でのその使用方法について、詳細なログを保持します。予期しないコマンドシーケンス、通常とは異なる出力パターン、悪用の試みを示す可能性のあるダウンストリームエラーなどの異常を監視します。ログを定期的に監査し、出力処理の制御における不備を特定します。

LLMリスクフレームワークと業界ガイダンス

安全でない出力処理は、新たなLLMセキュリティフレームワークにおいて重大な脆弱性として認識されています。OWASP Top 10 for LLMsでは、これを重大な懸念事項として挙げ、検証されていないモデル出力をバックエンド機能、ブラウザ、その他の実行可能なシステムに渡すリスクを指摘しています。

このフレームワークでは、LLMの出力を本質的に信頼できないものとして扱い、モデルが生成したコンテンツに入力検証の手法を適用するとともに、悪意のある出力の防止をプロンプトエンジニアリングやモデルの制約だけに依存しない多層防御戦略を実装することを推奨しています。

生成AIセキュリティに関する業界団体やベンダーのガイダンスも、これらの推奨事項を裏付けています。共通する主な対策として、デフォルトでの出力エンコーディング、LLMが生成したコンテンツと実行コンテキストの厳格な分離、出力の異常に対する継続的な監視が挙げられます。

LLMを本番システムに統合する組織は、セキュリティ制御をこれらのフレームワークに整合させ、安全でない出力処理を脅威モデルに組み込む必要があります。LLMの導入規模が拡大するにつれて攻撃対象領域も広がるため、プロアクティブな緩和策は高度な取り組みではなく、基本的な要件となります。

兆候とよくある間違い

アプリケーションが安全でない出力処理に対して脆弱である可能性を示すパターンがいくつかあります。

LLMの出力をデフォルトで信頼することは、最もよくある誤りです。開発者は、自分でプロンプトを作成したのだから、出力は安全だと考えがちです。しかし、これはユーザーが入力した内容がモデルの動作に及ぼす影響や、生成モデルに本質的に備わる予測不可能性を見落としています。

出力が「テキストに見える」からといってサニタイズを省略すると、そのテキストにコードやコマンドが埋め込まれていた場合、脆弱性につながります。一見すると単なるテキストに見える応答にも、後続システムで解析された際に作動するペイロードが含まれている可能性があります。

検証せずにLLMの出力を自動実行することは、重大なアンチパターンです。モデルの出力を確認せずに直接eval()、exec()、またはシェルインタープリターに渡すアプリケーションは、コード実行に直結する経路を生み出します。

出力をエンコードせずにUIやデータベースクエリへ直接埋め込むと、アプリケーションがXSSやインジェクション攻撃にさらされます。モデルの応答をエスケープせずにテンプレートへ挿入する手軽な方法は、回避可能なリスクをもたらします。

悪用の可能性を示す兆候には、下流システムで発生する予期しないエラー、通常とは異なるコマンドやクエリを示す異常なログエントリ、LLMを活用したインターフェースでの不審な動作に関するユーザー報告などがあります。これらの兆候を監視することで、安全でない出力処理の問題を早期に検出しやすくなります。

F5は安全でない出力処理にどのように対処しますか？

F5は、LLMの出力が下流システムやユーザーとやり取りするトラフィック層およびアプリケーション層に制御を適用することで、安全でない出力処理に対処します。

F5 AI Guardrailsは、F5 AI Security Platformの不可欠な要素として、AIアプリケーション、エージェント、ユーザー間のやり取りにポリシーを適用します。これには、モデルの応答がバックエンドシステムやクライアントアプリケーションに到達する前に検査する出力検証も含まれます。これにより、プロンプトインジェクション、コマンドシーケンス、予期しないデータパターンなど、悪意のある可能性があるコンテンツを含む出力を検出してブロックできます。

LLMが生成したコンテンツをレンダリングするWebアプリケーションでは、F5 Webアプリケーションファイアウォール機能が振る舞い分析とシグネチャベースの検知を適用し、XSS、インジェクション、その他のクライアント側の脆弱性を引き起こす可能性のある出力を特定します。保護対象はLLMの出力を使用するAPIにも及び、異常なペイロードを監視してスキーマ検証を適用します。

F5 Distributed Cloud Servicesは、ハイブリッドおよびマルチクラウド環境全体で保護機能を統合し、LLMワークロードの実行場所を問わず、一貫した出力処理制御を維持します。ログ記録と可視化の機能は、監査要件への対応を支援し、セキュリティチームがアプリケーションインフラストラクチャ内でのLLM出力の流れを監視できるようにします。

LLMの出力がアプリケーションに入力され、ユーザーに届くポイントに制御を配置することで、F5は、アプリケーションレベルの実装だけに依存せず、出力のサニタイズをデフォルトで適用できるよう組織を支援します。

よくあるご質問

OWASPは安全でない出力処理をどのように分類しており、なぜ他のLLMリスクと区別しているのでしょうか？

OWASPでは、安全でない出力処理を、LLMが生成した出力に対する検証、サニタイズ、処理が不十分な状態と定義しています。他のリスクとは異なり、適切な監督、統制、ガバナンスが整備されていないまま、出力が後続の処理を経てユーザーに提供されることで生じる問題を明確に指します。

AIアプリケーションでXSSを防止する際、出力エンコーディングと入力検証にはどのような違いがありますか？

AIアプリケーションでXSSを防止する際の入力検証と出力エンコーディングの違いは、入力検証がアプリケーションシステムに入力されるデータを評価するのに対し、出力エンコーディングは生成されたコンテンツをユーザーに返す際に保護する点にあります。入力検証では、アプリケーションに入力されるデータを評価し、定義済みのルールや想定される形式に適合しない入力を拒否します。出力エンコーディングでは、潜在的に危険な入力を、実行可能なコードではなくデータとして安全に表示できる形式に変換します。

安全でない出力処理を介して、間接プロンプトインジェクションがリモートコード実行（RCE）につながる仕組み

間接プロンプトインジェクションでは、モデルに提供するコンテンツに悪意のある指示を含めることで、RCEを引き起こすことができます。この指示により、モデルにコマンドや実行可能ファイルを生成させ、その出力を他のツールやシステムに渡して、正当なものとして処理させることができます。

LLMをデータベースや内部APIに接続する際、SQLインジェクションやサーバーサイドリクエストフォージェリ（SSRF）を防ぐにはどうすればよいですか？

データベースや内部APIへの接続時にSQLインジェクションやSSRFを防ぐには、コマンド、パラメーター、URL、ツール引数などのLLM出力を、実行可能な命令ではなく、信頼できないデータとして扱う必要があります。検証ソリューション、API許可リスト、パラメーター化クエリ、最小権限アクセスは、リスクの軽減に役立ちます。

LangChain Guardrails、NVIDIA NeMo Guardrails、Webアプリケーションファイアウォール（WAF）の違いは何ですか？

LangChain Guardrails、NVIDIA NeMo Guardrails、WAFは相互に補完するソリューションであり、主な違いは、エンタープライズAIシステムのそれぞれ異なる側面を保護する点にあります。LangChain Guardrailsは、LLMアプリケーションコード内のミドルウェアとして、タスクとエージェントの検証に使用されます。NVIDIA NeMo GuardrailsはLLMオーケストレーションの前段に配置され、複数ターンの対話制御とトピックの整合性を実現します。WAFはネットワークエッジに導入され、SQLインジェクション、XSS、DDoS攻撃などの脅威から保護します。