SSTIとXSSの境界線を見極める：テンプレートエンジンの「裏側」で起きている惨劇

現場でコードレビューをしていると、ジュニアエンジニアが「XSS対策はサニタイズしていれば完璧」と胸を張る場面によく遭遇する。だが、現実はそう甘くない。特にJinja2（Python）やTwig（PHP）といったモダンなテンプレートエンジンを使っている場合、「出力時のエスケープ」だけでは防げない領域に踏み込んでしまうことがある。それが今回深掘りする「サーバーサイドテンプレートインジェクション（SSTI）」だ。

1. なぜSSTIは「XSSの先」にあるのか

XSSが「ブラウザ側で悪意あるスクリプトを実行させる」攻撃であるのに対し、SSTIは「サーバー側のテンプレートエンジンを操り、サーバー上の情報を奪取、あるいは任意コードを実行する」攻撃だ。

攻撃者が狙うのは、テンプレートの変数を埋め込む箇所に「生の入力」を流し込むことだ。例えば、ユーザー入力をそのまま文字列としてテンプレートに結合すると、テンプレートエンジン自体がそれを「実行すべき命令」と誤認する。

攻撃の PoC（概念実証）の危険性

例えば、PythonのJinja2でこんなコードを書いたとしよう。

脆弱な実装例
from flask import Flask, request, render_template_string

app = Flask(__name__)

@app.route(“/hello”)
def hello():
# ユーザー入力を直接レンダリングしてしまうのは自殺行為
user_name = request.args.get(‘name’)
template = f”

Hello, {user_name}

”
return render_template_string(template)

攻撃者は ?name={{77}} と送り込む。もし画面に 49 と表示されたら、そこはSSTIの入り口だ。ここから {{config.__class__.__init__.__globals__['os'].popen('ls').read()}} のように、サーバー内のファイルを列挙したり、RCE（リモートコード実行）へ直結させることも容易になる。

2. SSTIとXSSの境界：どう切り分けるか

XSSの場合: 攻撃の最終目的地は「閲覧者のブラウザ」だ。クッキーを盗む、セッションをハイジャックする。
SSTIの場合: 攻撃の目的は「サーバーの占拠」だ。テンプレートエンジンのサンドボックスを突き破り、OSコマンドを実行する。

「XSSだと思ってサニタイズ（htmlspecialchars 等）を入れたが、SSTIの脆弱性は放置されていた」というケースが最も悲惨だ。テンプレートエンジンに渡す前の「変数」として適切に処理しなければ、防御は成立しない。

3. 実務で守るための「鉄則」実装

一番の防御策は、「ユーザー入力をテンプレートエンジンの構文として扱わせない」ことだ。テンプレートファイルの中に直接変数を流し込むのではなく、テンプレート変数として渡すこと。

Python (Flask/Jinja2) のセキュアな実装

セキュアな実装例
from flask import Flask, render_template

@app.route(“/hello”)
def hello():
# ユーザー入力を「変数」として安全に引き渡す
user_name = request.args.get(‘name’, ‘Guest’)

# テンプレートファイル（hello.html）側でレンダリングする
# Jinja2はテンプレート変数として渡された値をデフォルトで自動エスケープする
return render_template(“hello.html”, name=user_name)

これだけで、たとえユーザーが {{77}} と入力しても、それは単なる文字列として表示されるだけになる。

4. インフラ・環境レベルでの防御（多層防御）

コードレベルの修正が基本だが、万が一の漏洩を防ぐため、以下の設定も推奨する。

Nginxでの入力フィルタリング（簡易的な防波堤）

特定のテンプレート構文をURLパラメータから排除する。

nginx.conf の locationブロック
{{ や }} を含むリクエストを拒否する設定（極端な例だが、特定エンドポイントには有効）
if ($query_string ~ “(\{\{|\}\})”) {
return 403;
}

クラウドIAMとサンドボックスの隔離

もしDockerコンテナで動かしているなら、非特権ユーザー（root以外）でプロセスを実行し、ファイルシステムを読み取り専用（ReadOnly）にすることが不可欠だ。

Dockerfileのベストプラクティス
RUN groupadd -r appuser && useradd -r -g appuser appuser
USER appuser
コンテナ起動時に –read-only オプションを付与する

最後に：シニアエンジニアからの助言

「テンプレートエンジンを使っていれば勝手に安全」という思い込みが、最も危ない。多くの脆弱性は、開発者が「便利さ」のためにショートカット（文字列結合でのレンダリング）を使った瞬間に生まれる。

1. 動的にテンプレート文字列を生成しない（render_template_string は極力避ける）。
2. ユーザー入力は常に「変数」としてテンプレートに引き渡す。
3. テンプレートエンジンのサンドボックスを過信せず、OSレベルの権限分離を行う。

この3つを守るだけで、君たちのアプリケーションの堅牢性は劇的に向上する。セキュリティは知識の量ではなく、こうした「違和感」をコードの細部に持ち込めるかどうかの執念で決まるんだ。明日からのコードレビューで、この視点をぜひ活かしてほしい。

【実務・中級編】サーバーサイドテンプレートインジェクション(SSTI)とXSSの境界 – アプリケーションセキュリティ & 安全な開発防御ガイド