सर्व्हर-साइड टेम्पलेट इंजेक्शन पडद्यामागे कसे कार्य करते
सर्व्हर-साइड टेम्पलेट इंजेक्शन तेव्हा होते जेव्हा वापरकर्त्याचे इनपुट थेट टेम्पलेटिंग इंजिनमध्ये एम्बेड केले जाते आणि योग्य सॅनिटायझेशन किंवा आयसोलेशनशिवाय त्याचे मूल्यांकन केले जाते. यामुळे एक SSTI असुरक्षितता निर्माण होते जी आक्रमणकर्त्याला विशेषतः तयार केलेले SSTI पेलोड्स (उदाहरणार्थ, {{7*7}} जिंजा२ मध्ये), ज्याचे इंजिन मूल्यांकन करेल, ज्यामुळे सर्व्हर संदर्भात डेटा उघड करण्यापासून ते अनियंत्रित कोड कार्यान्वित करण्यापर्यंत सर्वकाही शक्य होते. वेगवेगळे टेम्पलेट इंजिन वेगवेगळे ऑब्जेक्ट्स आणि एपीआय उपलब्ध करून देत असल्यामुळे, एसएसटीआय पेलोड्स प्लॅटफॉर्मनुसार बदलतात, परंतु त्यांतील धोका एकच असतो: ते अविश्वसनीय इनपुटला अपेक्षित रेंडरिंग प्रवाहातून सुटून ॲप्लिकेशनच्या रनटाइममध्ये कार्यान्वित होऊ देतात, आणि जर यावर नियंत्रण ठेवले नाही, तर अनेकदा यामुळे संपूर्ण रिमोट कोड कार्यान्वयन किंवा लॅटरल मूव्हमेंट होऊ शकते.
जिंजा२ मधील किमान असुरक्षिततेचे उदाहरण
from flask import request, render_template_string @app.route("/hello") def hello(): name = request.args.get("name", "world") # ❌ Vulnerable: directly rendering user input return render_template_string("Hello " + name) जर वापरकर्त्याने पाठवले ?name={{7*7}}अॅप त्याचे मूल्यांकन करून, परत देईल हॅलो 49हे SSTI असुरक्षिततेचे एक उत्तम उदाहरण आहे.
ट्विगमधील किमान असुरक्षिततेचे उदाहरण
// ❌ Vulnerable Twig usage $template = $twig->createTemplate("Welcome " . $_GET['user']); echo $template->render([]); आक्रमणकर्ता SSTI पेलोड्स इंजेक्ट करू शकतो जसे की {{7*7}} कोड कार्यान्वित झाल्याचे सिद्ध करण्यासाठी. धोका: साध्या इंजेक्शनची व्याप्ती वाढून फाईल्स वाचणे, ओएस कमांड्स कार्यान्वित करणे किंवा पायाभूत सुविधांमध्ये अधिक खोलवर शिरकाव करण्यापर्यंत पोहोचू शकते.
वास्तविक जगातील शोषण: रिमोट कोड एक्झिक्यूशनला चालना देणारे SSTI पेलोड्स
एकदा SSTI असुरक्षितता अस्तित्वात आली की, हल्लेखोर संकल्पनेच्या पुराव्यासाठीच्या गणितापासून ते पूर्ण हल्ल्यापर्यंत पोहोचण्याचा प्रयत्न करतात. आरसीईवेगवेगळे टेम्पलेट इंजिन पेलोड वेगवेगळ्या प्रकारे हाताळतात.
जिंजा२ पेलोड्स
- {{7*7}} → अंकगणितीय अंमलबजावणी
- {{config.items()}} → सर्व्हर कॉन्फिग्स लीक होतात.
- {{ ”.__class__.__mro__[2].__subclasses__() }} → RCE कडे जाणारा मार्ग
वेग पेलोड
- #set($x=”7″)${x} → इंजेक्शन बायपास
- #set($a=$class.inspect(“java.lang.Runtime”)) → थेट रनटाइम ऍक्सेस
ट्विग पेलोड्स
- {{7*7}} → अंकगणित
- {{app.request.server.all}} → पर्यावरण चल
- {{_self.env.registerUndefinedFilterCallback(‘system’)}} → कोड कार्यान्वयन
हे SSTI पेलोड्स दाखवतात की वेगवेगळ्या इंजिनमधील एकच असुरक्षितता कशी वेगवेगळी परिणामे घडवून आणते. शोषणाचे मार्ग, पण ते नेहमीच धोकादायक असतात.
सर्व्हर साइड टेम्पलेट इंजेक्शन कुठे लपते CI/CD-चालित अनुप्रयोग
सर्व्हर साइड टेम्पलेट इंजेक्शन हा केवळ वेब ॲपचा धोका नाही; तो यामध्ये दिसून येतो आधुनिक CI/CD pipelines खूप. लपण्याच्या नेहमीच्या जागांमध्ये यांचा समावेश होतो:
- हेल्म चार्ट कुबरनेटीसमध्ये, जिथे टेम्पलेटची मूल्ये गतिमानपणे प्रस्तुत केली जातात
- ईमेल टेम्पलेट जे वापरकर्त्याद्वारे नियंत्रित इनपुट एकत्र जोडतात
- Dashboards जिथे क्वेरी स्ट्रिंग किंवा कॉन्फिग डेटा टेम्पलेट्समध्ये इंजेक्ट केला जातो
- डेव्हऑप्स स्क्रिप्ट्स जे टेम्पलेटिंग इंजिन वापरून HTML/मार्कडाउन तयार करतात.
उदाहरण:
# ❌ Insecure Helm values with user input configMap: appMessage: "{{ .Values.message }}" If.मूल्ये.संदेश अविश्वसनीय इनपुटमधून आल्यास, ते तुमच्या डिप्लॉयमेंटमध्ये सर्व्हर-साइड टेम्पलेट इंजेक्शन आणते. pipeline स्वतः.
सुरक्षित टेम्पलेट पॅटर्न आणि स्थिर विश्लेषणाद्वारे SSTI प्रतिबंध
SSTI असुरक्षितता कमी करण्यासाठी उत्तम कोडिंग पद्धती आणि लवकर शोध आवश्यक आहे.
सुरक्षित नमुने
- ❌ वापरू नका रेंडर_टेम्पलेट_स्ट्रिंग किंवा समतुल्य
- ✅ पूर्वनिर्धारित टेम्पलेट फाइल्स वापरा आणि सुसंपादित व्हेरिएबल्स पास करा
- ✅ उपलब्ध असल्यास सँडबॉक्स टेम्पलेट इंजिन
- ✅ रेंडर करण्यापूर्वी वापरकर्त्याच्या इनपुटची पडताळणी करा आणि त्याला एस्केप करा
असुरक्षित विरुद्ध सुरक्षित कुकी हाताळणी (संबंधित इनपुट जोखीम)
# ❌ Insecure: session cookie without flags response.set_cookie("session", token) # ✅ Secure: session cookie hardened response.set_cookie("session", token, httponly=True, secure=True, samesite="Strict") डेव्हलपर्ससाठी मिनी चेकलिस्ट
- वापरकर्त्याचे मूळ इनपुट कधीही थेट प्रस्तुत करू नका.
- समर्थित असल्यास सँडबॉक्स केलेले टेम्पलेट्स वापरा.
- सर्व टेम्पलेट व्हेरिएबल्स स्वच्छ आणि प्रमाणित करा
- सानुकूल टेम्पलेट मूल्यांकक टाळा
- यासाठी स्कॅन कोड रेंडर_टेम्पलेट_स्ट्रिंग किंवा स्ट्रिंग जोडणीचे नमुने
स्थिर विश्लेषण आणि लिंटर्स धोकादायक रचना उत्पादनापर्यंत पोहोचण्यापूर्वीच त्यांना चिन्हांकित करू शकतात.
DevSecOps मध्ये SSTI तपासण्या समाविष्ट करणे Pipelines
सर्व्हर-साइड टेम्पलेट इंजेक्शन लवकर पकडणे हे नंतर दुरुस्त करण्यापेक्षा स्वस्त आणि सुरक्षित आहे. DevSecOps टीम्सनी तपासण्या अंतर्भूत केल्या पाहिजेत. pipelines:
- Commit hooks: नाकारा commitधोकादायक कार्ये असलेले (रेंडर_टेम्पलेट_स्ट्रिंग)
- स्थिर विश्लेषकटेम्प्लेटिंग कोडमध्ये सर्वर साइड टेम्प्लेट इंजेक्शनच्या धोक्यासाठी स्कॅन करा.
- अवलंबित्व पडताळणीज्ञात SSTI असुरक्षितता असलेल्या कालबाह्य टेम्पलेट इंजिनांना ध्वजांकित करा.
- Pipeline दरवाजेSSTI तपासण्या यशस्वी होईपर्यंत ब्लॉक विलीन होतात.
SSTI पेलोड डिटेक्शनचा भाग बनवून CI/CDतुम्ही शोषण होऊ शकणाऱ्या कोडला कधीही प्रसारित होण्यापासून रोखता.
सर्व्हर-साइड टेम्पलेट इंजेक्शनला तुमच्या स्टॅकमध्ये शिरकाव करू देऊ नका
एकच सर्व्हर-साइड टेम्पलेट इंजेक्शन गणिताच्या युक्त्यांपासून सुरू होऊन परिस्थिती अधिक गंभीर होऊ शकते.{{7*7}}) ते संपूर्ण रिमोट कोड एक्झिक्यूशनपर्यंत. SSTI असुरक्षितता केवळ वेब अॅप्समध्येच नव्हे तर यामध्ये देखील आढळतात. CI/CD pipelines, हेल्म चार्ट्स आणि ईमेल टेम्पलेट्स.
की टेकवे
- वापरकर्त्याचे मूळ इनपुट कधीही टेम्पलेट्समध्ये प्रस्तुत करू नका.
- सर्व डायनॅमिक व्हेरिएबल्सची वैधता तपासा आणि त्यांना शुद्ध करा.
- वेगवेगळ्या इंजिनांमध्ये (जिंजा२, व्हेलॉसिटी, ट्विग) वेगवेगळे SSTI पेलोड असतात, पण त्या सर्वांना शस्त्रसज्ज करता येते.
- स्थिर विश्लेषण आणि फेल-फास्ट गेट्सचा वापर करा pipelines
- तुमच्या स्टॅकमधील टेम्पलेट्सचे नियमितपणे ऑडिट करा
साधने झायगेनी संघांना असुरक्षित टेम्पलेट वापर शोधण्यात, SSI असुरक्षितता रोखण्यात आणि सर्वत्र सुरक्षित पद्धती लागू करण्यात मदत करणे pipelines आणि अवलंबित्व. DevSecOps मध्ये, SSTI पेलोड्सना सर्वोच्च-स्तरीय धोका मानणे आवश्यक आहे कारण तुमच्यामध्ये एकच इंजेक्शन pipeline आमचे ॲप तुमचे संपूर्ण वातावरण धोक्यात आणू शकते.
