簡単に言うと？

SSTIを日常生活で例えると、「手紙の定型文に罠を仕込む」ようなものです。例えば、「○○様、お世話になっております」という定型文の○○部分に名前を入れる仕組みがあったとして、そこに特殊な命令を書き込むと、手紙を作る機械が暴走して、金庫を開けたり、他人の手紙を盗み見たりしてしまう、そんな攻撃です。
もっと身近な例では、「自動返信メールの悪用」に似ています。お問い合わせフォームに名前を入力すると「○○様、お問い合わせありがとうございます」という自動返信が来る仕組みで、名前の欄に悪意のあるコードを入力すると、メールサーバーが乗っ取られてしまうようなものです。
レストランの注文システムで例えると、「お客様の名前入りレシート」を印刷する機能があって、名前の欄に特殊な命令を入力すると、レジシステムが暴走して、売上データを盗んだり、他の客の情報を表示したりしてしまうようなものです。
Excelのマクロで例えると、セルに入力した文字を別のシートに自動コピーする機能があって、そこに特殊な式を入れると、パソコン内のファイルをすべて削除する命令が実行されてしまうようなものです。本来は便利な自動化機能が、悪用されると凶器に変わってしまうのがSSTIの怖さです。

詳しい仕組みと攻撃の流れ

SSTIの攻撃は、精密に計画された段階を経て実行されます。

第1段階の「偵察」では、攻撃者はWebアプリケーションがテンプレートエンジンを使用しているか確認します。エラーメッセージ、HTMLソースコード、レスポンスヘッダーなどから、使用されているテンプレートエンジンを特定します。`{{7*7}}`、`${7*7}`、`<%= 7*7 %>`などの簡単な式を入力し、結果が「49」と表示されれば、テンプレートエンジンが動作していることが分かります。
第2段階の「テンプレートエンジンの特定」では、各エンジン特有の構文を試すことで、正確なテンプレートエンジンとバージョンを特定します。Jinja2なら`{{config}}`、Twigなら`{{_self}}`、Freemarkerなら`${.now}`など、エンジンごとに異なる内部変数にアクセスします。
第3段階の「ペイロード開発」では、特定したテンプレートエンジンに対応した攻撃コードを作成します。例えば、Jinja2では`{{config.__class__.__init__.__globals__['os'].popen('コマンド').read()}}`のような複雑な構文で、OSコマンドを実行できます。
第4段階の「権限昇格」では、Webアプリケーションの実行権限でコマンドを実行し、より高い権限を取得します。設定ファイルの読み取り、データベース接続情報の取得、他のサービスへのアクセスなどを試みます。
第5段階の「永続化」では、バックドアの設置、新規ユーザーの作成、SSHキーの追加などにより、継続的なアクセスを確保します。
第6段階の「データ窃取と破壊」では、データベースの内容を盗み出したり、ファイルを暗号化したり、Webサイトを改ざんしたりします。
最終段階では、ログの削除や改ざんにより、攻撃の痕跡を消去します。

この攻撃が増えている背景

SSTI攻撃が急増している技術的背景として、モダンなWebフレームワークの普及があります。React、Vue.js、Angularなどのフロントエンドフレームワークと連携するため、サーバーサイドでもテンプレートエンジンの使用が増加しています。また、マイクロサービスアーキテクチャの採用により、各サービスで異なるテンプレートエンジンが使われ、管理が複雑化しています。
社会的背景として、開発スピードの要求が高まり、セキュリティよりも機能実装が優先される傾向があります。アジャイル開発やDevOpsの普及により、頻繁なリリースが行われる中で、セキュリティテストが不十分なまま本番環境にデプロイされるケースが増えています。
攻撃者側の環境も整備されています。SSTIの攻撃ツールやペイロード集がGitHubで公開され、技術力の低い攻撃者でも容易に攻撃を実行できるようになりました。また、バグバウンティプログラムの普及により、脆弱性の発見と共有が活発化しています。
さらに、クラウドネイティブアプリケーションの増加により、攻撃の影響が拡大しやすくなっています。一つのコンテナが侵害されると、Kubernetes環境全体に影響が及ぶ可能性があります。また、サーバーレス環境でもテンプレートエンジンが使用されることがあり、新たな攻撃対象となっています。
開発者教育の不足も大きな要因です。テンプレートエンジンは便利な機能として紹介されることが多く、セキュリティリスクについての認識が低い傾向があります。特に、ユーザー入力をテンプレートとして処理することの危険性が十分に理解されていません。

発生する直接的被害

リモートコード実行による完全なシステム掌握

SSTI攻撃の最も深刻な被害は、任意のコードをサーバー上で実行されることです。攻撃者はOSコマンドを自由に実行でき、ファイルの読み書き、プロセスの起動・停止、ネットワーク通信などが可能になります。実際の事例では、ECサイトのテンプレートエンジンの脆弱性を突かれ、顧客データベース全体（100万件以上）が流出し、クレジットカード情報も含まれていたため、被害総額は50億円を超えました。また、暗号資産取引所では、SSTIを経由してホットウォレットの秘密鍵が盗まれ、数十億円相当の暗号資産が流出した事例もあります。攻撃者はシステムの管理者権限を取得し、セキュリティソフトの無効化、ログの改ざん、新規管理者アカウントの作成なども行います。

機密情報とソースコードの大規模流出

SSTIを通じて、アプリケーションの設定ファイル、環境変数、ソースコード全体にアクセスされます。これには、データベースの接続情報、APIキー、暗号化キー、OAuth認証情報、管理者パスワードなどが含まれます。流出した情報は、さらなる攻撃の起点となり、関連するすべてのシステムが危険にさらされます。特にSaaSアプリケーションでは、マルチテナント環境で他の顧客のデータまで流出する可能性があります。ある事例では、CRMシステムのSSTI脆弱性により、全顧客企業の営業データ、契約情報、個人情報が流出し、複数の企業が連鎖的に被害を受けました。

サービスの完全停止と破壊的な改ざん

攻撃者はシステムを完全に破壊することも可能です。重要なファイルの削除、データベースの破壊、Webサイトの改ざんなどにより、サービスが長期間停止します。特に、バックアップシステムまで侵害された場合、復旧が極めて困難になります。2023年には、ニュースサイトがSSTI攻撃を受け、過去10年分の記事データが削除され、復旧に3か月を要した事例があります。また、攻撃者が意図的にシステムリソースを消費させ、サーバーをクラッシュさせることもあります。

発生する間接的被害

サプライチェーンへの攻撃拡大

SSTI攻撃で侵害されたシステムは、他の攻撃の踏み台として利用されます。特にB2Bサービスでは、APIを通じて接続している取引先システムへの侵入経路となります。信頼関係を悪用し、正規の通信に見せかけて攻撃を拡大させます。あるSaaSプロバイダーのSSTI脆弱性が悪用された事例では、そのサービスを利用していた200社以上の企業に被害が及び、業界全体のサプライチェーンが混乱しました。また、侵害されたサーバーからマルウェアが配布され、Webサイト訪問者にも二次被害が発生することがあります。

法的責任と規制違反による制裁

個人情報保護法、GDPR、各業界の規制に違反し、巨額の制裁金が科される可能性があります。特に、適切なセキュリティ対策を怠った過失が認定されると、責任は重くなります。日本では最大1億円、EUでは年間売上高の4%または2000万ユーロのいずれか高い方が制裁金として科される可能性があります。また、被害者からの集団訴訟、取引先からの損害賠償請求なども発生します。金融機関では、監督官庁から業務改善命令や業務停止命令を受ける可能性もあります。

復旧コストと長期的な信用失墜

SSTI攻撃からの復旧には、膨大なコストと時間がかかります。システムの完全な再構築、フォレンジック調査、セキュリティ監査、ペネトレーションテスト、コード監査などで、数千万円から数億円の費用が発生します。また、インシデント対応チームの稼働、外部専門家の雇用、被害者への補償なども必要です。信用回復には更に長い時間がかかり、顧客離れ、株価下落、新規契約の減少などにより、長期的な収益への影響は計り知れません。セキュリティ認証（ISO27001など）の取り消しや、サイバー保険の適用拒否なども起こり得ます。

被害を受けやすい組織・個人の特徴

SSTI攻撃を受けやすい組織には明確な特徴があります。まず、テンプレートエンジンを多用しているWebアプリケーション、特にCMS、ブログシステム、メール配信システム、レポート生成システムなどが高リスクです。これらは動的コンテンツ生成のためにテンプレートを多用する傾向があります。
開発体制に問題がある組織も脆弱です。セキュアコーディングの教育が不足している、コードレビューが形骸化している、セキュリティテストを実施していない、外注に依存しているなどの組織は、SSTI脆弱性を作り込みやすく、発見も遅れます。
急成長しているスタートアップやSaaS企業も要注意です。機能開発を優先し、セキュリティが後回しになりがちです。また、複数のテンプレートエンジンを併用していたり、オープンソースのテンプレートを安易に採用したりすることで、脆弱性を生み出しやすくなります。
レガシーシステムを運用している企業も危険です。古いバージョンのテンプレートエンジンには既知の脆弱性が存在し、パッチも提供されていない場合があります。
また、ユーザー生成コンテンツを扱うサービス、カスタマイズ可能なダッシュボード、多言語対応サイトなど、ユーザー入力を動的に処理する機能を持つサービスは、特に注意が必要です。

対策を簡単に言うと？

SSTI対策を日常生活で例えると、「手紙の宛名欄に住所を書かせない」ようなものです。名前だけを書く欄には名前だけを書かせ、それ以外の情報や命令は受け付けない。もし変な記号が書かれていたら、そのまま印刷せずにエラーとして処理する。これが基本的な考え方です。
料理のレシピで例えると、「材料名の欄に調理方法を書かせない」ということです。「トマト」と書くべき欄に「包丁で手を切れ」と書かれても、それを実行しない仕組みを作ることです。材料は材料、手順は手順と、明確に分けて処理することが重要です。
ATMで例えると、「金額入力欄に命令を入力させない」ようなものです。1000円と入力すべき欄に「金庫を開けろ」と入力されても、数字以外は受け付けない、または単なる文字として扱うことで、システムを守ります。
Excelで例えると、「数値入力セルに関数を入力させない」ことです。普通の数字を入れる欄に、勝手にVLOOKUPやマクロを書かれても実行しない、ただの文字として表示するだけにすることで、予期しない動作を防ぎます。入力できる内容を厳密に制限することが、SSTI対策の基本です。

すぐに実施すべき基本対策

1. ユーザー入力のテンプレート処理の完全禁止（優先度：最高、難易度：中）

ユーザーからの入力を絶対にテンプレートとして処理しないことが最重要です。テンプレートエンジンに渡す前に、すべてのユーザー入力をエスケープまたはサニタイズします。例えば、Jinja2では`{{user_input}}`ではなく`{{user_input|e}}`のようにエスケープフィルターを必ず使用します。可能な限り、静的なテンプレートのみを使用し、動的なテンプレート生成は避けます。もし動的処理が必要な場合は、許可リスト方式で厳密に制御された値のみを使用します。開発チーム全体でこのルールを徹底し、コードレビューで必ずチェックすることが重要です。

2. サンドボックスモードとセーフモードの有効化（優先度：最高、難易度：低）

多くのテンプレートエンジンには、危険な機能を制限するサンドボックスモードやセーフモードが用意されています。Jinja2のSandboxedEnvironment、Twigのsandbox extensionなどを必ず有効にします。これにより、ファイルシステムへのアクセス、危険な関数の呼び出し、任意のオブジェクトへのアクセスなどが制限されます。ただし、サンドボックスも完璧ではないため、これだけに依存せず、他の対策と組み合わせることが重要です。設定は可能な限り制限的にし、必要な機能のみを許可します。

3. 入力検証とホワイトリスト方式の実装（優先度：高、難易度：中）

すべてのユーザー入力に対して厳格な検証を実施します。特殊文字（`{}`、`$`、`<%`など）を含む入力は拒否するか、エスケープします。可能であれば、英数字のみなど、許可する文字を限定するホワイトリスト方式を採用します。正規表現による検証も有効ですが、複雑なパターンは避け、シンプルで確実な検証を行います。また、入力の長さも制限し、異常に長い入力は拒否します。フロントエンドとバックエンドの両方で検証を実施し、多層防御とします。

4. テンプレートエンジンとライブラリの更新（優先度：高、難易度：低）

使用しているテンプレートエンジンとその依存ライブラリを常に最新版に更新します。既知のSSTI脆弱性の多くは、最新版では修正されています。自動更新の仕組みを導入し、セキュリティパッチは即座に適用します。また、使用しているテンプレートエンジンのセキュリティアドバイザリを定期的に確認し、脆弱性情報を把握します。古いバージョンのサポートが終了した場合は、速やかに移行計画を立てます。

5. エラーハンドリングとログ監視（優先度：高、難易度：低）

テンプレート処理のエラーを適切に処理し、詳細なエラー情報を外部に漏らさないようにします。エラーメッセージにテンプレートエンジンの種類やバージョン情報を含めないよう注意します。すべてのテンプレート処理をログに記録し、異常なパターン（テンプレート構文を含む入力、頻繁なエラーなど）を検知する仕組みを構築します。WAF（Web Application Firewall）を導入し、SSTI攻撃のパターンをブロックすることも効果的です。

中長期的に取り組むべき対策

1. セキュアコーディング教育とガイドライン策定（投資対効果：高、実装期間：3-6か月）

開発チーム全体に対して、SSTI脆弱性に関する包括的な教育プログラムを実施します。テンプレートエンジンの仕組み、SSTI攻撃の原理、実際の攻撃事例、防御手法などを詳しく学習します。組織独自のセキュアコーディングガイドラインを策定し、テンプレート処理に関する明確なルールを定めます。定期的なワークショップや勉強会を開催し、最新の脅威情報を共有します。また、新入社員や外注先に対する教育も徹底し、組織全体のセキュリティレベルを向上させます。OWASPのガイドラインやCWE（Common Weakness Enumeration）を参考に、業界標準のベストプラクティスを採用します。

2. 静的解析とセキュリティテストの自動化（投資対効果：高、実装期間：6-9か月）

SAST（Static Application Security Testing）ツールを導入し、ソースコードレベルでSSTI脆弱性を検出します。SonarQube、Checkmarx、Fortifyなどのツールには、SSTI検出機能が含まれています。CI/CDパイプラインに統合し、コミット時やビルド時に自動的にスキャンを実行します。また、DAST（Dynamic Application Security Testing）ツールによる動的テストも実施し、実行時の脆弱性を検出します。ペンテストツールやファジングツールを使用して、様々な攻撃パターンをテストします。定期的にセキュリティ専門家による手動レビューも実施し、ツールでは検出できない脆弱性を発見します。

3. テンプレート処理のアーキテクチャ見直し（投資対効果：中、実装期間：9-12か月）

システムアーキテクチャを見直し、テンプレート処理を安全な設計に変更します。可能な限り、サーバーサイドでのテンプレート処理を減らし、クライアントサイドレンダリングや静的サイト生成に移行します。テンプレート処理が必要な場合は、専用のマイクロサービスとして分離し、限定的な権限で実行します。コンテナやサーバーレス環境を活用し、侵害された場合の影響を最小化します。また、Content Security Policy（CSP）を実装し、クライアントサイドでの不正なコード実行を防ぎます。

4. ゼロトラストセキュリティモデルの採用（投資対効果：中、実装期間：12-18か月）

テンプレート処理を含むすべてのコンポーネントに対して、ゼロトラストの原則を適用します。各リクエストを検証し、最小権限の原則に基づいてアクセスを制御します。テンプレートエンジンの実行環境を隔離し、ネットワークセグメンテーションを実施します。継続的な監視と異常検知により、SSTI攻撃の兆候を早期に発見します。また、インシデント対応計画を策定し、SSTI攻撃が発生した場合の対処手順を明確化します。定期的な訓練により、対応能力を維持・向上させます。

対策の効果を確認する方法

SSTI対策の効果を継続的に検証するため、以下の方法で定期的な確認を実施します。

セキュリティテストの定期実施により、既知のSSTIペイロードを使用して脆弱性の有無を確認します。自動化されたテストスイートを作成し、デプロイ前に必ず実行します。
コードレビューの強化では、テンプレート処理に関するコードを重点的にレビューし、危険なパターンがないか確認します。チェックリストを作成し、レビューの品質を標準化します。
ログ分析とモニタリングにより、SSTI攻撃の試行を検知します。異常なテンプレート構文、エラーの頻発、不審なアクセスパターンなどを監視します。
ペネトレーションテストを年2回以上実施し、外部の専門家による評価を受けます。最新の攻撃手法に対する耐性を確認します。
脆弱性管理プロセスにより、発見された脆弱性の修正状況を追跡し、対策の実施率を測定します。

誤解1：WAFがあれば SSTI は防げる

「WAF（Web Application Firewall）を導入していればSSTI攻撃は防げる」というのは危険な過信です。WAFは既知の攻撃パターンをブロックできますが、SSTI攻撃は非常に多様で、エンコーディングや難読化により簡単に回避される可能性があります。また、正規のテンプレート構文と悪意のある構文の区別が困難な場合もあります。正しい理解は、WAFは追加の防御層として有効ですが、根本的な対策はセキュアなコーディングとアーキテクチャ設計であるということです。

誤解2：エスケープ処理だけで十分

「HTMLエスケープを行えばSSTI攻撃を防げる」という考えは不完全です。HTMLエスケープはXSS対策には有効ですが、SSTI攻撃はサーバーサイドで実行されるため、クライアントサイドのエスケープでは防げません。また、テンプレートエンジンによっては、エスケープをバイパスする方法が存在します。正しくは、ユーザー入力をテンプレートとして処理しないことが最も重要で、エスケープは補助的な対策に過ぎません。

誤解3：最新のフレームワークなら安全

「最新のWebフレームワークを使っていれば自動的にSSTI対策されている」という考えは誤りです。確かに最新のフレームワークには多くのセキュリティ機能が含まれていますが、開発者が不適切な使い方をすれば脆弱性が生まれます。特に、カスタマイズやプラグインの追加により、新たな脆弱性が持ち込まれることもあります。フレームワークの機能を正しく理解し、セキュアに使用することが重要です。

誤解4：静的なテンプレートなら問題ない

「事前に定義された静的なテンプレートのみを使用していれば安全」という考えも、部分的にしか正しくありません。静的テンプレート自体は安全ですが、そこに渡すデータの処理方法によっては脆弱性が生まれます。また、テンプレートの継承や包含機能を悪用される可能性もあります。データとテンプレートの境界を明確にし、適切に処理することが必要です。

誤解5：内部向けシステムなら影響は限定的

「社内システムでSSTI脆弱性があっても影響は小さい」という考えは危険です。内部システムへの侵入は、より重要なシステムへの足がかりとなります。また、内部犯行のリスクもあります。さらに、VPNやリモートワークの普及により、内部と外部の境界は曖昧になっています。すべてのシステムで同等のセキュリティレベルを維持することが重要です。

SSTIに似た攻撃手法

SSTIと同様に、信頼できない入力を不適切に処理することで発生するインジェクション系の攻撃が複数存在します。これらは攻撃の原理が類似しており、対策も共通する部分があります。

OSコマンドインジェクション

OSコマンドインジェクションは、Webアプリケーションがシステムコマンドを実行する際に、ユーザー入力を不適切に処理することで発生します。SSTIがテンプレートエンジンを介してコード実行するのに対し、OSコマンドインジェクションは直接シェルコマンドを実行する点で異なりますが、最終的にサーバー上で任意のコマンドを実行できる点は共通しています。例えば、`system("ping " + user_input)`のような処理で、`; rm -rf /`のような悪意のある入力により、システムが破壊される可能性があります。SSTIも最終的にはOSコマンド実行に至ることが多く、両者は密接に関連しています。対策として、ユーザー入力の検証、エスケープ処理、パラメータ化されたコマンド実行が重要です。

SQLインジェクション

SQLインジェクションは、データベースクエリにユーザー入力を不適切に組み込むことで発生します。SSTIがアプリケーションロジックを操作するのに対し、SQLインジェクションはデータベース層を標的とする点で異なりますが、「信頼できない入力を動的に処理する」という脆弱性の根本原因は同じです。両者とも、入力検証の不備、エスケープ処理の欠如、動的なコード生成が原因となります。興味深いことに、SSTI攻撃でデータベース接続情報を取得し、その後SQLインジェクションを実行するという連携攻撃も見られます。プリペアドステートメントの使用、入力検証、最小権限の原則など、対策の考え方も共通しています。

XXE（XML外部エンティティ）攻撃

XXE攻撃は、XMLパーサーが外部エンティティを不適切に処理することで発生します。SSTIがテンプレート構文を悪用するのに対し、XXEはXMLの機能を悪用しますが、どちらも「データ」として受け取った入力を「コード」や「参照」として解釈してしまう点で類似しています。両攻撃とも、ファイルの読み取り、SSRFの実行、DoS攻撃などが可能です。また、一部のテンプレートエンジンはXMLベースの設定を使用するため、XXEとSSTIが組み合わさることもあります。外部エンティティの無効化、入力検証、セキュアなパーサーの使用など、対策も類似しています。

SSTIに関連した攻撃手法

XSS（クロスサイトスクリプティング）

XSSは、Webページに悪意のあるスクリプトを注入する攻撃ですが、SSTIと密接な関係があります。SSTIでテンプレートを操作してXSSペイロードを埋め込むことが可能です。逆に、XSS脆弱性を利用して管理画面にアクセスし、そこからSSTI攻撃を実行するケースもあります。また、両者とも不適切な出力処理が原因となることが多く、エスケープ処理の不備が共通の脆弱性となります。特に、SSTIで生成されたHTMLにXSS脆弱性が含まれることもあり、複合的な被害につながります。CSPの実装、出力エスケープ、入力検証など、対策も重複する部分が多いです。

SSRF（サーバーサイドリクエストフォージェリ）

SSRFは、サーバーから任意のURLにリクエストを送信させる攻撃ですが、SSTI攻撃の一環として頻繁に利用されます。テンプレートエンジンの機能を使って、内部ネットワークへのアクセス、クラウドメタデータの取得、外部サービスへの攻撃などが可能になります。例えば、Jinja2で`{{request.urlopen('http://internal-server/')}}`のようなコードを実行させることで、内部システムにアクセスできます。SSTIとSSRFの組み合わせは、特にクラウド環境で深刻な被害をもたらし、AWS、Azure、GCPのメタデータサービスから認証情報を盗み出すことができます。

ディレクトリトラバーサル

ディレクトリトラバーサル攻撃とSSTIは、ファイルシステムへの不正アクセスという点で関連しています。SSTI攻撃では、テンプレートエンジンの機能を使って任意のファイルを読み取ることができ、`../../../etc/passwd`のようなパスを指定して機密ファイルにアクセスします。また、テンプレートファイル自体のインクルード機能を悪用したディレクトリトラバーサルも可能です。両攻撃とも、ファイルパスの検証不備が原因となり、設定ファイル、ソースコード、秘密鍵などの流出につながります。パス正規化、アクセス制御、ホワイトリスト方式など、対策も共通しています。