目次
メールの差し込み、帳票、通知文、CMSの表示など、テンプレートはWeb運用の各所で使われます。利用者が入力した文章を表示するつもりでも、テンプレートの原文へ連結してから評価すると、その文章が処理の命令として扱われる場合があります。
本記事は2026年10月18日にPortSwiggerとJinjaの一次資料を確認した実務解説で、特定の事件の速報ではありません。注文メールや帳票の場面は仮想例です。以下の棚卸しと試験方法は、資料を踏まえた本サイトの提案として示します。
スポンサーリンク
SSTIとXSSでは処理される場所が違う
SSTIは、信頼しない値がサーバー側のテンプレート構文として評価される問題です。一方、XSSはブラウザーで意図しないスクリプトなどが動く問題です。出力をHTML用にエスケープしていても、その前にサーバーが入力をテンプレートとして解釈していれば、別の境界を守れていません。
危険性はエンジン、設定、渡したオブジェクト、実行権限によって変わります。テンプレートを使っているだけで侵害される、特定の記号が入っただけで必ずコード実行になる、と一律には判断できません。入力がどのAPIへ、構文と値のどちらとして渡るかを追います。
出典：PortSwigger Server-side template injection。
原文への連結と値の差し込みを区別する
仮想の注文メールで、固定した文面に購入者名を値として渡す処理と、購入者名を含む文字列全体を新しいテンプレートとしてコンパイルする処理は異なります。後者では、名前の欄がテンプレートの構文を増やす場所になり得ます。
本サイトの提案は、承認したテンプレートを読み込み、名前、金額、配送先などを決められたデータ項目へ渡す方式です。テンプレートとして扱う原文を、HTTPの入力、DBの自由記述欄、外部APIの回答から組み立てないようにします。
一度DBへ保存した値も、その後の利用先で自動的に信頼できるようにはなりません。問い合わせ文やインポート済みの文章を再利用するときも、初回と同じく表示用のデータとして扱います。
スポンサーリンク
テンプレート名の選択も制限する
固定のテンプレートを使っていても、入力されたファイル名をそのまま読み込む設計には別の問題があります。利用者に指定させるのは業務上の種類だけにし、実際のテンプレートとの対応はサーバー側で管理する方法が考えられます。
たとえば注文確認と配送通知を選べる機能なら、認めた識別子だけを対応表へ通します。任意のパスや、管理者専用テンプレートを指定できないことを確認します。テンプレートを選ぶ権限と、その中へ表示する情報の権限も別に判断します。
ファイルを見つけられないときに、入力文字列をテンプレート原文とみなす救済処理は避けます。正常な選択に失敗したら、構文として再解釈するのではなく、想定したエラーで止める方針にします。
渡すオブジェクトを業務上必要な値へ絞る
テンプレートへアプリ全体の設定、DB接続、リクエスト、広い機能を持つサービスを渡すと、表示のための処理が大きな権限へ届く経路を作ります。単に変数名を隠すより、最初から必要な値だけの小さなデータへ変換する設計を優先します。
帳票には、表示を許可した項目を持つデータを渡します。メソッドの呼び出しで更新が起きるオブジェクトや、内部の秘密へたどれる参照を持つオブジェクトを、便利だからという理由で共有しないようにします。
Jinjaの公式資料も、関連するデータだけを渡し、副作用のあるメソッドを持つオブジェクトなどに注意する考え方を示しています。実際に利用するエンジンの仕様で、属性参照、関数、フィルター、拡張機能が何を許すか確認してください。
出典：Jinja SandboxedEnvironmentの安全上の考慮事項。
スポンサーリンク
利用者が文面を編集するなら別の信頼境界を作る
利用者がレイアウトそのものを編集するサービスでは、固定文面だけに限定できない場合があります。それでも、編集できることとアプリ全体の機能を使えることを同じにしないでください。必要な差し込み変数と、許可する編集機能を先に定義します。
本サイトの提案は、編集用の権限、承認の手順、実行環境、渡すデータを分けることです。使わない構文や拡張を減らし、ネットワークやファイルへ届く能力も業務上の必要性から限定します。管理者アカウントの侵害も想定すると、編集者が管理者だから無制限でよいとはなりません。
サンドボックスを使う場合も、名称だけで安全と判断しません。Jinjaは、それが完全な安全策ではなく、短いテンプレートでも大量の出力や資源消費を生む場合があると説明しています。実行時間、メモリー、出力量の制限と、失敗時の扱いを合わせて設計します。
プレビューと配信処理を同じ基準で守る
最終のメール送信を厳しくしても、プレビューだけが広い権限で評価されていれば、そこが入口になります。画面の試し表示、バックグラウンド処理、PDF作成、過去データの再発行を一覧にし、同じ種類の入力がどこで評価されるかを照合します。
プレビュー用のサンプルには、本番の顧客情報や認証情報を使わないようにします。失敗したテンプレート、変数の一覧、詳細な例外を一般の利用者へ表示すると、内部情報を渡す場合があります。利用者向けのエラーと、運用者が見る診断情報を分けます。
キャッシュも対象です。別組織のテンプレートや、承認前の版を誤って使わないかを調べます。キャッシュのキーには業務上必要な範囲と版を反映し、削除や権限変更が実際の利用へ反映される条件を決めます。
出力形式の安全性は別に確認する
テンプレートがデータを命令として解釈しなくても、出力先で危険な文字列になる可能性は残ります。HTML、JavaScript、URL、メールのヘッダーなどでは、必要な処理が異なります。サンドボックスは、あらゆる出力文脈の安全性を自動で保証しません。
HTMLの自動エスケープを使うときも、安全扱いにする機能や、生のHTMLを差し込む箇所を確認します。装飾を許す業務なら、許可するHTMLを明示した処理を別に検討します。サーバーの構文として扱わない対策と、ブラウザーへ安全に渡す対策を分けて点検してください。
無害なデータで解釈の境界を試す
検証環境では、通常の文章、テンプレートに似た記号、長い入力、欠けた項目などを用意します。値として渡した内容が、勝手に新しいテンプレートの命令として処理されず、想定する文字列として出るかを確かめます。実際の侵害につながるペイロードを本番で試す必要はありません。
利用者が原文を編集できる場合は、許した構文だけが使え、渡していない値や副作用のある機能へ届かないことを確かめます。資源制限の試験は、隔離した環境で小さな条件から始め、処理の終了と他の要求への影響を観測します。
エラーだけでは合否を決めません。エラーになる前に何が評価されたか、部分的なファイルや通知が残らないか、別の利用者の処理が止まらないかを照合します。脆弱な依存関係の更新も、この設計確認と別に継続します。
スポンサーリンク
文面の承認とデータの認可を分ける
仮想の請求書で、テンプレートの見た目が承認済みでも、別の顧客の請求情報を渡せば情報漏えいは起きます。本サイトの提案は、承認するテンプレートの版と、実行する利用者が参照できるデータを別々に確認することです。テンプレートの承認を、任意の対象を表示してよい許可として使わないようにします。
承認後に原文が変更されたら、同じ承認のまま実行しない設計も必要です。版の識別と公開状態を対応させ、プレビュー用と配信用が同じ承認済みの版を使うかを確認します。ファイルの名前が同じでも、内容が違う場合を想定してください。
翻訳や通知文の編集も同じ台帳へ入れます。文章を編集する担当者が、テンプレートの構文まで編集できる必要があるのかを整理すると、柔軟性を残したまま実行能力を減らせる場合があります。
失敗時に残る成果物を管理する
帳票の作成が途中で失敗しても、一時ファイルや作成途中の出力が残る場合があります。本サイトの提案は、成功した出力だけを利用者へ渡し、失敗した処理の一時データは、閲覧できる人と削除する条件を限定することです。例外を表示しなかったことだけで、内部情報がどこにも残らないとは判断しません。
ジョブを再試行する場合は、同じ通知を何度も送らない仕組みも別に検討します。安全性の検証のために行ったプレビューが、本当のメール配信やDBの更新へ進まないことを、テスト用の送信先で確かめます。実行能力を絞る対策と、誤操作を止める対策を一緒に試験へ含めてください。
スポンサーリンク
改修は最も広い評価の入口から始める
まず入力を原文として評価する場所を見つけ、固定テンプレートと明示的なデータへ置き換えられるかを検討します。次に、テンプレートの選択と渡すオブジェクトを絞り、最後に利用者編集が必要な範囲へ隔離と資源制限を追加します。
メールの件名だけ、帳票の一部だけ、と小さく見える入口も除外しないでください。機能の見た目の大きさと、実行時に届く権限の大きさは一致しません。表示用の値をどこまで命令として扱うかを、実装上の境界として確認することが出発点です。
参考資料
以下の一次資料を2026年10月18日に確認しました。本文の仮想例と運用手順の提案は、資料の引用とは区別しています。
