テンプレートエンジンは「魔法の箱」ではない：SSTIが生むRCEの深淵

多くの開発者が、Jinja2やThymeleafを単なる「HTML生成ツール」と誤認している。だが、セキュリティアーキテクトの視点で見れば、これらは「サーバーサイドで動的に実行される、極めて強力なインタープリター」以外の何物でもない。

SSTI（Server-Side Template Injection）は、単なる入力値のバリデーション不備ではない。それは、アプリケーションが本来アクセスを許可すべきでない「実行コンテキスト」への到達権を、ユーザーに誤って委譲してしまう設計の欠陥だ。

1. なぜ「式言語」が凶器に変わるのか

テンプレートエンジンは、動的なコンテンツ生成のために独自の「式言語（Expression Language）」を持つ。これらはオブジェクトグラフを辿り、メソッドを呼び出し、時には反射（Reflection）を通じてメモリ上のあらゆるクラスにアクセスできるように設計されている。

例えば、PythonのJinja2において、ユーザー入力が直接テンプレートの一部として評価されるコードは、以下のような悪夢を招く。

脆弱な実装例：ユーザーの入力をそのままテンプレートとしてレンダリングしている
from flask import Flask, request, render_template_string

app = Flask(__name__)

@app.route(“/greet”)
def greet():
name = request.args.get(“name”)
# 警告: ユーザー入力がテンプレート文字列に直接結合されている
template = f”

Hello, {name}!

”
return render_template_string(template)

このとき、攻撃者は name パラメータに {{ self.__init__.__globals__.__builtins__['__import__']('os').popen('id').read() }} を注入する。これは、Jinja2のコンテキストからPythonの組み込み関数を辿り、OSコマンドを実行する典型的かつ致命的なペイロードだ。

2. サンドボックス回避：境界線を破る技術

最新のテンプレートエンジンは、特定のクラスやメソッドへのアクセスを制限する「サンドボックス」機能を持つことが多い。しかし、ホワイトハッカーの視点から見れば、これは「堅牢な壁」ではなく「迷路」に過ぎない。

攻撃者は、以下のステップでサンドボックスを無力化する：

探索（Exploration）： {{ [].__class__.__base__.__subclasses__() }} を用いて、メモリ上にロードされているすべてのクラスを列挙し、本来アクセス不可のはずの subprocess.Popen や file 操作に関連するクラスを見つけ出す。
脱獄（Jailbreak）： 制限された属性名（例: __globals__）がブラックリスト化されている場合、attr フィルターや文字列連結（request['__glo' + 'bals__']）を用いて、静的な解析をすり抜ける。

我々が防衛側として考慮すべきは、「どれだけ制限をかけても、メタプログラミングの深淵までは完全に封じ込められない」という現実だ。

3. 次世代の防衛アーキテクチャ：ガードレイルの設計

SSTIに対する最も強力な防御は、「入力データとコードの完全な分離」である。しかし、ビジネス要件上、どうしても動的なテンプレート生成が必要な場合、以下の「多層防衛アーキテクチャ」を実装せよ。

A. コンテキストの分離（Sandbox Isolation）

テンプレートエンジンを、OSレベルで隔離されたコンテナ（gVisor等のセキュアランタイム）内で実行し、ファイルシステムやネットワークへのアクセスを完全に制限する。

B. セキュアなテンプレート設計

Jinja2を使用する場合、SandboxedEnvironment を活用し、安全なメソッドのみをホワイトリスト化する。

from jinja2.sandbox import SandboxedEnvironment

厳格な制限をかけた環境の構築
env = SandboxedEnvironment()
危険な属性へのアクセスを禁止するポリシー
env.globals = {} # 必要最小限の関数のみを公開する
template = env.from_string(“Hello, {{ name }}”)

C. 生成AIとの統合におけるガードレイル

現在、LLMをバックエンドに持つシステムで、LLMが生成したコードをそのままテンプレートとして評価するケースが増えている。これは極めて危険だ。「LLMの出力と、テンプレートエンジンの入力の間には、必ず『構文木（AST）の検証プロセス』を介在させよ」。

生成されたテンプレート文字列が、許可されていない関数や属性にアクセスしていないか、構文解析器を通して検証するゲートウェイを設けることが、プロンプトインジェクションに対する防波堤となる。

4. 監査の視点：何を見るべきか

コード監査において、render_template や eval 系の関数をgrepするだけでは不十分だ。以下のポイントをチェックせよ。

1. データフローの追跡： 外部入力がテンプレートの「テンプレート文字列そのもの」として渡されている箇所を特定せよ（変数の値として渡すのは安全だが、テンプレートの構造自体を操作できる場合はアウトだ）。
2. 型安全性： 反射を使用しているライブラリの依存関係を確認せよ。間接的にテンプレートエンジンを呼び出すライブラリが、脆弱性を抱えている可能性がある。
3. WAFの限界： WAFによるシグネチャベースの検知は、難読化されたペイロード（Base64エンコードやUnicodeエスケープ）の前では無力だ。アプリケーション層でのバリデーションを疎かにしてはならない。

結びとして

SSTIは、アプリケーションの論理構造を根底から覆す、攻撃者にとって「最高にエレガントな」脆弱性だ。これを防ぐためには、単なるパッチ適用ではなく、「テンプレートエンジンは信頼できないデータを実行する可能性がある」という前提に立ったアーキテクチャへの刷新が必要である。

あなたが設計するシステムが、侵入者に対して「堅牢な要塞」であるか、それとも「鍵が開けっ放しの実験室」であるか。その分かれ目は、常にこの細部に宿っている。

【テクニカル・上級編】サーバーサイドテンプレートインジェクション(SSTI)の原理とRCEへの発展 – アプリケーションセキュリティ & 安全な開発防御ガイド