SSTI（Server-Side Template Injection、サーバーサイドテンプレートインジェクション）は、Webアプリケーションが使う「テンプレートエンジン」が、ユーザーの入力を本来のデータとしてではなく、テンプレートの構文そのものとして解釈してしまう脆弱性です。Jinja2（Python）&#x30FBTwig（PHP）&#x30FBFreeMarker&#x30FBVelocity（Java）&#x30FBEJS（Node.js）など、サーバーサイドのテンプレートエンジンの多くは、{{ }}や${ }のような記法で囲んだ部分を「式」として評価し、結果を画面に埋め込みます。

たとえば「ようこそ、{{ name }}さん！」というテンプレートがあり、nameにユーザーが入力した値を渡すと、通常は入力した文字列がそのまま埋め込まれます。ところが実装に問題があると、ユーザーが入力した文字列自体が「テンプレートの一部」として扱われてしまうことがあります。たとえば名前欄に{{7*7}}と入力すると、画面に「7*7」ではなく「49」と表示される——これは、エンジンが文字列ではなく式として評価している証拠です。この{{7*7}}は、実際のバグバウンティ報告書でも、SSTIの存在を確認する最初の一手として非常によく使われる、業界で広く知られた合い言葉（canary）です。

{{7*7}}で確認できるのは「式が評価されている」という事実だけです。しかし本物の攻撃では、ここから一気に深刻な被害に発展します。Jinja2であれば{{ self.__init__.__globals__... }}のような構文でPythonの内部オブジェクトをたどり、最終的にOSコマンドを実行する関数（os.popen等）に到達できることが知られています。

本話のラボは、実際&#x306BPythonやJavaScriptのテンプレートエンジンを動かしているわけではありません。eval()やnew Function()を使えば、ユーザーが入力した文字列を一瞬で「実行」できてしまいますが、それはまさに今学んでいる脆弱性そのものを、訪問者であるあなたのブラウザの中に作ってしまうことになります。

そこで本話のラボでは、四則演算と決められたプロパティへのアクセスだけを解釈する、自作の小さな「式パーサー」を実装しました。文字列を1文字ずつ読み取り、数字・演算子・識別子をトークンに分解し、決まった文法規則（再帰下降法）に従って組み立てる、という方法です。evalやFunctionを一度も呼ばずに、{{7*7}}を本当に計算して「49」を返すことができます。

架空の掋示板「やさい掋示板」には、表示名を入力すると「ようこそ、○○さん！」と表示する歡迎バナー機能があります。この機能は、入力された文字列をテンプレート文字列にそのまま連結してからテンプレートエンジンに渡しているため、name欄に{{ }}を含めると、その部分が新しいテンプレート構文として評価されます。

SSTIの根本原因は、「テンプレートの構文（文字列そのもの）」と「テンプレートに渡すデータ」を混ぜてしまうことにあります。

• 構文とデータを分ける：テンプレート文字列自体は定数として固定し、ユーザー入力は必ず「値」として渡す（構文の一部にしない）
• サンドボックス実行環境：Jinja2のSandboxedEnvironmentなど、危険な属性アクセスを事前に制限するオプションを有効化する
• ロジックレスなテンプレートエンジン：Mustacheのように、式評価を一切行わず単純な値の差し替えだけに専化したエンジンを選ぶ
• 入力検証&#x30FBWAF：{{や${のようなテンプレート構文を含む入力を検出する（補助的な対策）

第3話では、テンプレートエンジンがユーザー入力を構文として評価してしまうSSTIを体験しました。次回はパディングオラクル攻撃という、「成功／失敗」だけの情報から暗号を解く手法を扱います。