Kako ubrizgavanje šablona na strani servera funkcioniše iza kulisa
Ubrizgavanje šablona na strani servera se dešava kada se korisnički unos direktno ugradi u mehanizam šablona i procijeni bez odgovarajuće sanitizacije ili izolacije. Ovo stvara SSTI ranjivost koja omogućava napadaču da ubrizga posebno kreirane SSTI korisne podatke (na primjer, {{7*7}} u Jinja2), što će mehanizam za obradu podataka procijeniti, omogućavajući sve, od otkrivanja podataka do proizvoljnog izvršavanja koda u kontekstu servera. Budući da različiti mehanizmi za predloške otkrivaju različite objekte i API-je, SSTI korisni opterećenja se razlikuju ovisno o platformi, ali dijele istu opasnost: dopuštaju da nepouzdani unos pobjegne iz očekivanog toka renderiranja i izvrši se u okruženju aplikacije, što često dovodi do potpunog udaljenog izvršavanja koda ili lateralnog premještanja ako se ne provjeri.
Minimalni ranjivi primjer u Jinja2
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) Ako korisnik pošalje ?name={{7*7}}, aplikacija će to procijeniti i vratiti Zdravo 49To je tipična SSTI ranjivost.
Minimalni ranjivi primjer u Twig-u
// ❌ Vulnerable Twig usage $template = $twig->createTemplate("Welcome " . $_GET['user']); echo $template->render([]); Napadač može ubrizgati SSTI korisne podatke kao što su {{7*7}} da se dokaže izvršenje koda. Opasnost: jednostavno ubrizgavanje može eskalirati do čitanja datoteka, izvršavanja OS naredbi ili dubljeg prodiranja u infrastrukturu.
Praktični iskorištavanja: SSTI korisni opterećenja koja pokreću udaljeno izvršavanje koda
Kada se pojavi SSTI ranjivost, napadači pokušavaju da pređu sa matematičkog dokaza koncepta na potpunu... RCERazličiti sistemi predložaka različito obrađuju korisne terete.
Jinja2 korisni tereti
- {{7*7}} → aritmetičko izvršavanje
- {{config.items()}} → curi konfiguracije servera.
- {{ ”.__class__.__mro__[2].__subclasses__() }} → put do RCE-a
Brzinski korisni tereti
- #set($x=”7″)${x} → premosnica ubrizgavanja
- #set($a=$class.inspect(“java.lang.Runtime”)) → direktan pristup tokom izvođenja
Twig korisni tereti
- {{7*7}} → aritmetika
- {{app.request.server.all}} → varijable okruženja
- {{_self.env.registerUndefinedFilterCallback(‘system’)}} → izvršavanje koda
Ovi SSTI korisni podaci pokazuju kako ista ranjivost u različitim motorima dovodi do različitih iskorištavanje puteva, ali su uvijek opasni.
Gdje se krije ubrizgavanje šablona na strani servera CI/CD-Pokrenute aplikacije
Ubrizgavanje šablona na strani servera nije rizik samo za web aplikaciju; ono se pojavljuje u moderan CI/CD pipelines previše. Tipična mjesta za skrivanje uključuju:
- Helm charts u Kubernetes-u, gdje se vrijednosti predložaka dinamički prikazuju
- Šablone e-pošte koji spajaju korisnički kontrolirane ulaze
- Dashboards gdje se nizovi upita ili konfiguracijski podaci ubrizgavaju u predloške
- DevOps skripte koji generiraju HTML/Markdown koristeći mehanizme za predloške.
Primjer:
# ❌ Insecure Helm values with user input configMap: appMessage: "{{ .Values.message }}" If.Values.message dolazi iz nepouzdanog unosa, uvodi ubrizgavanje predloška na strani servera u vaše raspoređivanje pipeline sama.
Sprečavanje SSTI-a sigurnijim šablonima i statičkom analizom
Ublažavanje SSTI ranjivosti zahtijeva bolje obrasce kodiranja i rano otkrivanje.
Sigurni obrasci
- ❌ Ne koristite render_template_string ili ekvivalent
- ✅ Koristite unaprijed definirane datoteke predložaka i proslijedite provjerene varijable
- ✅ Sandbox šabloni kada su dostupni
- ✅ Validacija i izbjegavanje korisničkog unosa prije renderiranja
Nesigurno vs. sigurno rukovanje kolačićima (rizik povezan s unosom)
# ❌ 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") Mini kontrolna lista za programere
- Nikada ne renderuj sirovi korisnički unos direktno
- Koristite šablone u sandboxu kada je to podržano
- Sanitizirajte i validirajte sve varijable predloška
- Izbjegavajte evaluatore prilagođenih predložaka
- Skeniraj kod za render_template_string ili obrasci spajanja stringova
Statička analiza a linteri mogu označiti rizične konstrukcije prije nego što dođu do produkcije.
Ugrađivanje SSTI provjera u DevSecOps Pipelines
Rano otkrivanje ubrizgavanja šablona na strani servera je jeftinije i sigurnije od kasnijeg popravljanja. DevSecOps timovi bi trebali ugraditi provjere u pipelines:
- Commit hooks: odbaciti commits opasnim funkcijama (render_template_string)
- Statički analizatoriskeniranje rizika ubrizgavanja šablona na strani servera u kod šablona
- Validacija zavisnosti: označi zastarjele mehanizme predložaka s poznatim SSTI ranjivostima
- Pipeline kapije: spajanje blokova dok ne prođu SSTI provjere
Uključivanjem detekcije korisnog materijala SSTI u CI/CD, sprečavate da se iskorištavajući kod ikada isporuči.
Ne dozvolite da ubrizgavanje šablona sa strane servera prođe kroz vaš stek
Jedna injekcija šablona na strani servera može eskalirati od matematičkih trikova ({{7*7}}) do potpunog udaljenog izvršavanja koda. SSTI ranjivosti se pojavljuju ne samo u web aplikacijama već i u CI/CD pipelines, Helm grafikoni i predlošci e-pošte.
Ključni postupci
- Nikada ne prikazuj sirovi korisnički unos u predloške
- Validirajte i dezinficirajte sve dinamičke varijable
- Različiti motori (Jinja2, Velocity, Twig) imaju različitu SSTI nosivost, ali svi se mogu naoružati.
- Koristite statičku analizu i brze kapije za prekide u pipelines
- Redovno revidirajte predloške u svom steku
Alat poput Xygeni pomoći timovima da otkriju nesigurnu upotrebu predložaka, blokiraju SSI ranjivosti i provedu sigurne prakse pipelinei zavisnosti. U DevSecOps-u, tretiranje SSTI korisnih podataka kao rizika najvišeg nivoa je ključno jer jednokratna injekcija u vaš pipeline ili aplikacija može ugroziti cijelo vaše okruženje.
