【テクニカル・上級編】 SSTI(Server-Side Template Injection)の悪用とサンドボックス回避 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

SSTIの深淵：テンプレートエンジンという名の「トロイの木馬」をどう解剖するか

テンプレートエンジンは、現代のWebアプリケーション開発において不可欠な抽象化レイヤーだ。しかし、開発者が「便利さ」を追求してテンプレートのコンテキストに外部入力をそのまま流し込んだ瞬間、その抽象化は攻撃者にとっての「実行環境」へと変貌する。

本稿では、SSTI（Server-Side Template Injection）という古典的だが極めて強力な攻撃ベクトルを題材に、なぜサンドボックスが容易に突破されるのか、そして我々アーキテクトが「二度とコード実行を許さない」ための防御層をどう設計すべきかを掘り下げる。

—

1. SSTIの根本原因：メタプログラミングの罠

SSTIの根本原因は、テンプレートエンジンが「データ」と「ロジック（コード）」を分離できず、攻撃者の入力された文字列をテンプレートの構文として解釈してしまう点にある。

例えば、Pythonの Jinja2 において、{{ 7 * 7 }} という入力が 49 とレンダリングされるなら、それはテンプレートエンジンがPythonの式評価を行っている証拠だ。攻撃者はここからPythonのオブジェクトモデルを辿り、__globals__ や __subclasses__ を経由して os.system などの危険な関数に到達する。

攻撃のロジック：サンドボックスの脱獄

多くのテンプレートエンジンは「安全な環境」を提供しようと試みるが、その実装の多くは「許可リスト（Allowlist）」に基づいている。しかし、Pythonのような動的言語では、オブジェクトの参照を辿れば実質的に全ての名前空間にアクセス可能だ。

以下は、Jinja2のサンドボックスを回避し、任意のコマンドを実行するための古典的かつ有効なペイロード例である。

# Jinja2環境でのRCEペイロードの構成要素
# 1. 空のリストからobjectクラスを特定
# 2. __subclasses__() を呼び出して読み込まれている全てのクラスを列挙
# 3. osモジュールを持つクラスを探し出し、それを悪用する
{{ ''.__class__.__mro__[1].__subclasses__()[400]('ls -la', shell=True, stdout=-1).communicate() }}

この「400」というインデックスは、環境によって変わる。熟練の攻撃者は、ターゲットのライブラリ構成に合わせてこのインデックスを動的に探索するスクリプトを走らせる。これが、単なる静的なシグネチャ検知では防げない理由だ。

—

2. 構造的防御：アーキテクチャによる分離

WAFでのフィルタリング（{{ や __ をブロックする）は、もはや猫とネズミの追いかけっこに過ぎない。真の防御は、テンプレートエンジンを「信頼できないコードを実行する環境」から隔離することにある。

1. 最小権限原則の徹底（コンテナ分離）

テンプレートレンダリングプロセスを、メインのWebアプリケーションプロセスから完全に切り離せ。サイドカーパターンやマイクロサービス化を行い、レンダリング専用のコンテナには、ネットワークアクセス権限やファイルシステムへの書き込み権限を一切与えない。

2. コンテキスト認識型のエンコーディング

テンプレートエンジン側でのサニタイズを頼りにしてはいけない。入力データは、テンプレートに渡される前に「何者であるか」を明確に定義された型（DTO: Data Transfer Object）に変換し、エスケープ処理を強制せよ。

# 推奨される設計: 入力をテンプレートに渡す前の厳格なバリデーション
from pydantic import BaseModel, constr

class UserProfile(BaseModel):
    # 型を厳格に定義し、テンプレート内での式評価を防ぐ
    username: constr(regex=r'^[a-zA-Z0-9]+$') 
    bio: str

def render_profile(user_input):
    # 検証済みデータのみをテンプレートへ渡す
    data = UserProfile(**user_input)
    return template_engine.render('profile.html', user=data)

—

3. 生成AI時代の新たな脅威：プロンプトインジェクションとの融合

現在、LLMをバックエンドに組み込んだアプリケーションが増加しているが、ここで新たなSSTIの形態が生まれている。LLMが生成したテキストがそのままテンプレートエンジンに渡される場合、LLMへのプロンプトインジェクションが、そのままSSTIへと発展するリスクがある。

ガードレイルの設計:
LLMからの出力をテンプレートに挿入する場合、必ず以下のような「サンドボックス出力フィルター」を通す必要がある。

構造化データ化: LLMにJSON形式での出力を強制し、テンプレート側ではそのJSONをパースするのみとする（テンプレートエンジンの式評価機能を無効化する）。
テンプレートエンジンの設定変更: Jinja2であれば SandboxedEnvironment を使用し、さらに unsafe_methods を明示的に禁止する設定を行う。

from jinja2.sandbox import SandboxedEnvironment

# 外部入力を扱うための安全な環境設定
env = SandboxedEnvironment()
# 危険なメソッドへのアクセスを遮断
env.globals.update({'os': None, 'sys': None}) 

def safe_render(template_str, context):
    template = env.from_string(template_str)
    return template.render(context)

—

結びに：ペネトレーションテスターの視点

我々レッドチームがクライアントのシステムを評価する際、最も重点を置くのは「どこで開発者が”賢さ”を発揮しすぎてしまったか」という点だ。テンプレートエンジンを柔軟に使いこなすことは、技術的にはエレガントかもしれない。しかし、セキュリティの観点では、その「柔軟性」こそが最大のアタックサーフェスになる。

インシデントハンドリングの現場では、SSTIはしばしばWebシェルへの直行便となる。アーキテクトとして守るべきは、テンプレートの構文を制御することではない。「テンプレートが何を評価できるか」というスコープを、物理的に、あるいはプロセスレベルで物理的に絞り込むことだ。

コードは書かないこと、それが最強の防御である。しかし、書かなければならないのなら、その実行環境を「檻」の中に閉じ込める勇気を持つことだ。それが、高度な攻撃からシステムを守る唯一の道である。