Server-Side Template Injection

Server-Side Template Injection

Server-Side Template Injection(SSTI)完全ガイド:仕組み・実例・攻撃方法・防御策

SSTI(サーバーサイドテンプレートインジェクション)は、Webアプリケーションのテンプレートエンジンがユーザー入力を処理する際に生じる、危険な脆弱性です。適切な入力フィルタがなければ、攻撃者はテンプレート構文を注入して、任意のコード実行、データ漏洩、サーバー乗っ取りを実行できます。この記事では、SSTIの正体と攻撃例、防止策を徹底解説します。

「テンプレートはHTMLを作るだけ? いいえ、SSTIが仕掛けられていれば、あなたのサーバーはハッカーの遊び場になります。」

🧩 SSTIとは何か?

SSTI(Server-Side Template Injection)とは、サーバー側テンプレートエンジンが、ユーザー入力をテンプレートとして評価してしまうことにより発生する脆弱性です。攻撃者はテンプレート構文(例:{{…}} や ${…})を注入し、任意のコード実行を行うことができます。

🧠 どのように悪用されるのか?

以下のような状況があると、SSTIのリスクが発生します:

  • テンプレートに直接ユーザー入力が埋め込まれている
  • テンプレートエンジンが動的に評価される
  • 開発者が{{ user_input }}のような形式で出力している

💥 結果:攻撃者は {{ 7*7 }} → 49 といった構文を注入し、テンプレートエンジンでコードを実行させられる可能性があります。

🧪 テンプレートエンジン別のSSTI例

テンプレートエンジン インジェクション構文
Jinja2 (Python) {{ 7*7 }}
Twig (PHP) {{ dump(app) }}
Velocity (Java) ${7*7}
Smarty (PHP) {$smarty.version}

👨‍💻 ハッカーの攻撃シナリオ

  1. ユーザー入力フィールドを見つける(例:メッセージ投稿欄)
  2. {{7*7}} のような構文を試す
  3. 出力が 49 であればテンプレートが評価されていることを確認
  4. 次にファイル読み込みやRCE(リモートコード実行)を狙う構文を試す
{{ config.__class__.__init__.__globals__['os'].popen('ls').read() }}

このような構文が通れば、サーバー内部のディレクトリ情報が取得されてしまいます。これは完全にシステム乗っ取りの入り口です。

☠️ SSTIの危険性

  • 💀 任意コード実行(RCE)に直結
  • 🔓 セッション情報・認証トークンの漏洩
  • 🧨 データベースのダンプやユーザー情報の取得
  • 📂 任意ファイルアクセス、リモートシェルの挿入

「SSTIは、XSSやSQLインジェクションを遥かに超える危険性を持ちます。RCE=ゲームオーバーです。」

🛠️ 実装例:脆弱な vs 安全なコード

❌ 脆弱な例(Python Flask + Jinja2)

@app.route('/greet')
def greet():
    name = request.args.get('name')
    return render_template_string("Hello {{ %s }}" % name)

✅ 安全な例

@app.route('/greet')
def greet():
    name = request.args.get('name')
    return render_template("hello.html", name=name)

テンプレートファイルとロジックを分離し、render_template_string のような動的テンプレート評価は避けましょう。

🛡️ SSTIの防止方法

  • 🔒 テンプレートに直接ユーザー入力を入れない
  • 🧼 テンプレート文字列を事前にフィルタ・サニタイズ
  • 👨‍💻 テンプレートエンジンの設定で評価関数を無効化
  • 🛑 render_template_stringを避ける
  • 🧪 セキュリティスキャナで自動チェック(Burp Suiteなど)

📌 まとめ:テンプレート処理=コード実行の可能性

SSTIは、テンプレートの中に“コード”を仕込むことで発動する攻撃です。もしサーバー側でテンプレート評価を動的にしているなら、今すぐその実装を見直しましょう。テンプレートは見た目だけではありません。評価対象にしてしまえば、あなたのシステムそのものが侵入の足がかりになります。

「ユーザーが見ているHTMLの裏側に、攻撃者のコードが動いているとしたら? それがSSTIの本質です。」

Leave a Comment

Your email address will not be published. Required fields are marked *

Recent Post

開いているポート

Open Ports(開いているポート)によるセキュリティ脆弱性と対策 Open Ports(オープンポート)は、ネットワーク上でサービスが外部と通信を行うために必要なものですが、不要なポートが開いたまま放置されていると、攻撃者にとっての入口となってしまいます。これは多くのデータ漏洩やログイン脆弱性、同時セッションハイジャックの引き金となる重大なセキュリティ脆弱性です。 この記事では、Open Portsがなぜ危険なのか、どのように悪用されるか、そして具体的な対策について解説します。 実際の企業で起きたデータ漏洩事例 2023年、某中小企業の開発環境において、ポート9200で稼働していたElasticsearchがインターネットに公開されていました。適切な認証が設定されておらず、社員や顧客の個人情報20万件が第三者に取得される事態となりました。 攻撃者はShodanを使って開いているポートを検索し、未保護のElasticsearchに接続。数分でデータを抜き取ることができたと言われています。 このように、意図せず開放されたポートが、機密データの流出に繋がるケースは後を絶ちません。

誤設定されたCORS

Misconfigured CORS(誤設定されたCORS)によるセキュリティ脆弱性と対策 CORS(Cross-Origin Resource Sharing)は、異なるドメイン間で安全にリソースを共有するための仕組みですが、設定ミス(Misconfigured CORS)があると、重大なセキュリティ脆弱性となり、データ漏洩やセッションの乗っ取り、ログイン情報の窃取に繋がるリスクがあります。 本記事では、実際の事例、攻撃方法、危険性、そして正しい設定方法について、サイバーセキュリティや同時セッションの観点から詳しく解説します。 実際の企業で起きたCORSの設定ミスによるデータ漏洩 2022年、ある大手オンラインバンキング企業が、誤ってAccess-Control-Allow-Origin: *を本番APIに設定していたため、悪意あるサードパーティサイトからAPIを通じて顧客のアカウント情報や残高情報が取得されるという事件が発生しました。

安全でないHTTPヘッダー

Insecure HTTP Headers(安全でないHTTPヘッダー)によるセキュリティ脆弱性とその対策 Webアプリケーション開発や運用において、HTTPヘッダーの適切な設定は非常に重要です。しかし、多くの開発者がこのポイントを見落としており、セキュリティ脆弱性につながることがあります。「Insecure HTTP Headers(安全でないHTTPヘッダー)」は、クロスサイトスクリプティング(XSS)やクリックジャッキング、セッションハイジャックなどのリスクを高め、結果としてデータ漏洩やログイン脆弱性を引き起こす可能性があります。 実際の企業で発生したデータ漏洩の事例 ある中堅企業のWebアプリケーションでは、X-Frame-OptionsやContent-Security-Policyといったセキュリティ用HTTPヘッダーが一切設定されていませんでした。この隙を突かれ、攻撃者はクリックジャッキングを用いてユーザーのセッションを盗み、数万件の顧客情報が漏洩するという事件が発生しました。 HTTPヘッダーの不備により、攻撃者は正規ページをiframe内に読み込み、ユーザーの入力を誘導。管理者権限での操作を強制させる「UIリダイレクション攻撃」が成功しました。 このように、HTTPレスポンスヘッダーの未設定が直接的な原因となり、大きな損失を被ることがあります。

冗長なエラーメッセージ

Verbose Error Messages(冗長なエラーメッセージ)が招くセキュリティ脆弱性 開発段階では役に立つ情報も、公開環境では重大なセキュリティ脆弱性になることがあります。中でもVerbose Error Messages(冗長なエラーメッセージ)は、攻撃者にとって貴重な情報源となり、データ漏洩やログイン脆弱性の特定に繋がるリスクがあります。 本記事では、Verbose Error Messagesの危険性と、それがどのように攻撃に悪用され、どのように対策すべきかを具体的に解説します。 現実のシナリオ:エラー表示が招いた企業の機密漏洩

welcome our Blog

Scroll to Top