【検知回避・痕跡消去編】EDR Bypass／ログ消去／LOLBinsの発想と防御｜CTF思考フレームワーク #40
安全に生きたい編集部
安全に生きたい
【SSTI編】入力をテンプレートとして実行させない設計｜CTF思考フレームワーク #33
安全に生きたい編集部
名前を画面に表示するだけで、どうしてサーバー側の処理につながるの？
入力を単なる文字として表示せず、テンプレートの式として評価してしまう実装があると危険なんだ。
SSTI（Server-Side Template Injection）は、利用者の入力がサーバー側テンプレートの一部として解釈される問題です。
Jinja2やTwigなどのテンプレートエンジン自体が危険なのではなく、入力を「表示する値」ではなく「実行するテンプレート」として扱う設計が問題になります。
📚 CTF思考フレームワーク シリーズ
#33 【SSTI編】入力をテンプレートとして実行させない設計 ／ 全86記事。全シリーズ記事はこちら。
この記事の難易度
難易度：中級〜上級 ／ 読了目安：10分 ／ 学習順：#33
この記事で分かること
- 反射型XSSとSSTIの違いを理解する
- 入力をテンプレートへ連結する危険を知る
- サンドボックスだけに頼らない設計を考える
この記事で出てくる言葉
- テンプレートエンジン：HTMLやメール文面へ値を埋め込む仕組みです。
- SSTI：入力がサーバー側テンプレート式として評価される問題です。
- サンドボックス：実行できる機能を制限する仕組みですが、設計の代替ではありません。
Contents
🔍 観察フェーズ：まず何を見る？
最初から攻撃方法を探すのではなく、どの機能や設定が外から見えているかを整理するところから始めるよ。
いきなり試すんじゃなくて、まず「どこが入口になり得るか」を整理するんだね。
💡 仮説フェーズ：なぜ危険になり得る？
観察した内容から、被害につながる条件を仮説として並べるよ。
仮説1
入力が式として評価されると、想定外の情報参照や処理に発展する場合があります。
仮説2
テンプレートの権限や利用可能オブジェクトが広いほど、影響も大きくなります。
仮説3
サンドボックスは補助対策であり、入力をテンプレートとして評価しない設計が先です。
🔬 検証フェーズ：安全に確かめる
検証の目的は、実在サービスを攻撃することではなく、自分のラボで仕組みと防御の効き方を理解することだよ。
ローカルの安全なサンプルで、「固定テンプレートに値を渡す」実装と「入力をテンプレートとして組み立てる」実装を読み比べます。実サービスへの式入力は行わないでください。
許可された環境で、結果だけじゃなく「なぜそうなったか」まで確認するんだね。
⚔️ 攻撃フェーズ：成立すると何が起きる？
ここでは実サービスへの手順ではなく、成立した場合の影響を押さえよう。
影響1
攻撃者にとって利用価値のある入口や情報が増え、次の侵害につながる可能性があります。
影響2
設定や権限の範囲によっては、情報漏えい・改ざん・業務停止などへ影響が広がります。
影響3
検知や記録が不足していると、侵害の発見や原因調査が遅れます。
🛡️ 防御フェーズ：守る側はどうするか
守りは「気をつける」では終わらせず、設定・実装・監視に落とし込もう。
対策1
テンプレートは開発側が固定し、利用者入力は値としてエスケープして渡す
対策2
利用できる関数・オブジェクト・ファイルアクセスを最小化する
対策3
テンプレートエラーや不自然な式文字列の入力をログで監視する
🤝 大事なお約束
必ず守ってね
この記事で扱う確認・検証は、自分の環境、CTF、または明示的に許可された演習環境だけで行ってください。他人のサービスや端末に無断で試す行為は、不正アクセス等に該当するおそれがあります。学んだ知識は守る側で活用しましょう。
📝 まとめ
SSTIの対策は、危険な式を一つずつ禁止することではなく、利用者入力を最初からテンプレートとして実行しないことです。
