FlawOpen

flawopen.com/SSTI/समझाया गया

Server-side template injection क्या है?

CWE-1336: Server-Side Template Injectionसंदर्भ पृष्ठ
संक्षिप्त उत्तर

Server-side template injection तब होती है जब अविश्वसनीय input को data के बजाय template source के रूप में parse किया जाता है। प्रभाव engine, configuration और उपलब्ध क्षमताओं पर निर्भर है: expression evaluation से server-side code execution तक। हर SSTI से code execution नहीं होता।

असुरक्षित — input template बनाता है
# Python / Jinja2
template = f"Hello {name}!"
return render_template_string(template)

# Input: {{ 7*7 }} renders as "49"
# This confirms expression evaluation;
# impact still depends on engine access.

// Java / Freemarker
String tpl = "Welcome " + userName;
new Template("t", tpl, cfg)
    .process(model, out);
ठीक किया — input data है
# The template is a fixed string the
# developer wrote. The user value is
# passed in as a variable.
return render_template(
    "greeting.html", name=name
)

# Or with a literal template string:
return render_template_string(
    "Hello {{ name }}!", name=name
)

// Java equivalent: template from file,
// user value in the model map.

महत्वपूर्ण अंतर

हर template engine को दो inputs मिलते हैं: template और context data। Template एक program है; data वे values हैं जिन्हें वह पढ़ता है। SSTI तब होती है जब user input को data से template source की श्रेणी में जाने दिया जाता है।

यह SQL injection जैसी संरचनात्मक गलती है, जहाँ data query text में जोड़ा जाता है, और Log4Shell जैसी भी, जहाँ data log message से expression evaluator तक पहुँचा। सुधार का सिद्धांत समान है: program स्थिर रखें और अविश्वसनीय values parameter channel से दें।

कब प्रभाव में code execution हो सकता है

यदि engine template को शक्तिशाली objects या methods देता है, तो attacker संवेदनशील application क्षमताओं तक पहुँच सकता है। Code execution engine, version, configuration, sandbox और exposed data पर निर्भर है। अन्य प्रभाव data disclosure या resource exhaustion हो सकते हैं। User-controlled template source को सक्रिय logic मानें; accessible objects और rendering resources सीमित किए बिना केवल sandbox पर निर्भर न रहें।

कैसे पहचानें

{{7*7}} ${7*7} <%= 7*7 %> #{7*7}

यदि response में literal text के बजाय 49 आता है, तो input को template syntax की तरह evaluate किया गया। अधिकृत test environment में छोटे arithmetic probes evaluation पहचानने में मदद करते हैं; syntax बदलती है और अकेले engine की विश्वसनीय पहचान नहीं करती।

अक्सर पूछे जाने वाले प्रश्न

क्या यह XSS जैसा ही है?

नहीं। Client-side template injection पीड़ित के browser में चलता है और XSS का रूप हो सकता है। SSTI server के application process में evaluate होती है। प्रभाव engine और उपलब्ध क्षमताओं पर निर्भर है; कुछ configuration में server code execution संभव है, पर हर SSTI में यह अपने-आप नहीं होता।

क्या auto-escaping इसे रोकता है?

नहीं। Auto-escaping render होने वाली values को साफ करता है; यह value को template syntax की तरह parse होने से नहीं रोकता। यह output में XSS से बचाता है, template source injection से नहीं।

क्या केवल admins को template edit करने देना सुरक्षित है?

User-provided template source को executable logic मानें और default रूप से इसे मुख्य application context में process न करें। यदि जरूरी हो तो restricted templates के लिए बने engine का उपयोग करें, न्यूनतम inert data दें और CPU, memory, output size तथा समय सीमित करें। Sandbox अकेले पूरी security boundary नहीं है।

संदर्भ

यह भी देखें SSTI: कारण, प्रभाव और template injection का बचाव FreeMarker और Velocity SSTI: टेम्पलेट सुरक्षा क्या Jinja2 का render_template_string() सुरक्षित है?