Server-side template injection (SSTI) er en sårbarhet der brukerinput evalueres av en malmotor i stedet for å gjengis som ren tekst, slik at en angriper kan kjøre vilkårlig kode på serveren.
Hvordan serversidemalinjeksjon fungerer bak kulissene
En malinjeksjon på serversiden skjer når brukerinput legges inn direkte i en malmotor og evalueres uten skikkelig sanering eller isolering. Dette skaper et SSTI-sårbarhet som lar en angriper injisere spesiallagde SSTI-nyttelaster (for eksempel {{7*7}} i Jinja2), som motoren vil evaluere, noe som muliggjør alt fra dataavsløring til vilkårlig kodekjøring i serverkontekst. Fordi forskjellige malmotorer eksponerer forskjellige objekter og API-er, varierer SSTI-nyttelaster fra plattform til plattform, men deler den samme faren: de lar upålitelig input unnslippe den forventede gjengivelsesflyten og kjøres i applikasjonens kjøretid, noe som ofte fører til full ekstern kodekjøring eller sideveis bevegelse hvis det ikke kontrolleres.
Minimalt sårbart eksempel i Jinja2
Hvis en bruker sender ?navn={{7*7}}, vil appen evaluere den og returnere Hei 49Det er en typisk SSTI-sårbarhet.
Minimalt sårbart eksempel i Twig
En angriper kan injisere SSTI-nyttelaster som {{7*7}} for å bevise kodeutførelse. Faren: enkel injeksjon kan eskalere til å lese filer, utføre OS-kommandoer eller dreie seg dypere inn i infrastrukturen.
Ekte utnyttelser: SSTI-nyttelaster som utløser ekstern kodekjøring
Når en SSTI-sårbarhet eksisterer, prøver angripere å gå fra konseptbevismatematikk til full RCEUlike malmotorer håndterer nyttelaster forskjellig.
Jinja2 nyttelast
- {{7*7}} → aritmetisk utførelse
- {{config.items()}} → lekker serverkonfigurasjoner.
- {{ “”.__class__.__mro__[2].__subclasses__() }} → sti til RCE
Hastighetsnyttelaster
- #sett($x=”7″)${x} → injeksjonsbypass
- #set($a=$class.inspect(“java.lang.Runtime”)) → direkte tilgang under kjøring
Kvistnyttelast
- {{7*7}} → aritmetikk
- {{app.request.server.all}} → miljøvariabler
- {{_self.env.registerUndefinedFilterCallback(‘system’)}} → kodeutførelse
Disse SSTI-nyttelastene demonstrerer hvordan den samme sårbarheten i forskjellige motorer fører til forskjellige utnytte stier, men de er alltid farlige.
Hvor serversidemalinjeksjon skjuler seg CI/CD-Driven Applications
Injeksjon av serversidemaler er ikke bare en risiko for webapper; det dukker opp i moderne CI/CD pipelines også. Typiske gjemmesteder inkluderer:
- Hjelmdiagrammer i Kubernetes, hvor malverdier gjengis dynamisk
- E-postmaler som sammenkobler brukerstyrte inndata
- Dashboards der spørrestrenger eller konfigurasjonsdata injiseres i maler
- DevOps-skript som genererer HTML/Markdown ved hjelp av malmotorer.
Eksempel:
If.Verdier.melding kommer fra upålitelige input, introduserer den en serversidemalinjeksjon i distribusjonen din pipeline selv.
Forebygging av SSTI med tryggere malmønstre og statisk analyse
Å redusere SSTI-sårbarheter krever bedre kodemønstre og tidlig deteksjon.
Sikre mønstre
- ❌ Ikke bruk gjengivelsesmal_streng eller tilsvarende
- ✅ Bruk forhåndsdefinerte malfiler og send rensede variabler
- ✅ Sandbox-malmotorer når tilgjengelig
- ✅ Valider og escape brukerinndata før gjengivelse
Mini-sjekkliste for utviklere
- Aldri gjengi rå brukerinndata direkte
- Bruk sandkassemaler når det støttes
- Rens og valider alle malvariabler
- Unngå tilpassede mal-evaluatorer
- Skann koden for gjengivelsesmal_streng eller strengsammenkoblingsmønstre
Statisk analyse og linters kan flagge risikable konstruksjoner før de når produksjon.
Integrering av SSTI-sjekker i DevSecOps Pipelines
Å fange opp serversidemalinjeksjon tidlig er billigere og tryggere enn å fikse det senere. DevSecOps-team bør bygge inn sjekker i pipelines:
- Commit hooksavvis commitmed farlige funksjoner (gjengivelsesmal_streng)
- Statiske analysatorer: skann etter risiko for malinjeksjon på serversiden i malkode
- Avhengighetsvalidering: flagg utdaterte malmotorer med kjente SSTI-sårbarheter
- Pipeline porter: blokker slås sammen til SSTI-sjekker består
Ved å gjøre SSTI-nyttelastdeteksjon til en del av CI/CD, forhindrer du at utnyttbar kode noen gang sendes.
Ikke la serversidemalinjeksjon gli inn i stakken din
En enkelt serversidemalinjeksjon kan eskalere fra matte triks ({{7*7}}) til full ekstern kodekjøring. SSTI-sårbarheter vises ikke bare i webapper, men også i CI/CD pipelines, Helm-diagrammer og e-postmaler.
Nøkkelferier
- Aldri gjengi rå brukerinndata i maler
- Valider og sanitær alle dynamiske variabler
- Ulike motorer (Jinja2, Velocity, Twig) har ulik SSTI-nyttelast, men alle kan bevæpnes
- Bruk statisk analyse og feilfrie porter i pipelines
- Revider maler i stakken din regelmessig
Xygeni skanner kodebasen din for injeksjonsfeil og andre usikre kodemønstre når de dukker opp, og fanger opp risikable konstruksjoner som usanisert malgjengivelse før de når produksjon, med den laveste falske positive raten på OWASP Benchmark. Xygenis CI/CD og IaC security skanning utvider den samme dekningen til pipeline konfigurasjoner, Helm-diagrammer og byggeskript, og flagger feilkonfigurasjoner og ondsinnede kommandoer før de sendes. Når Xygeni finner en sårbarhet, genererer AI AutoFix en kontekstbevisst, utviklerklar løsning direkte i pull request, slik at utbedring ikke venter til neste sprint.
I DevSecOps, fange malinjeksjon på pipeline Det er fase, ikke etter utplassering, som hindrer en enkelt nyttelast i å bli et fullstendig kompromiss.
Start gratis. Ingen kredittkort nødvendig, skann ditt første repo på få minutter.
FAQ
Hva er serversidemalinjeksjon?
SSTI skjer når brukerinput sendes inn i en malmotor og evalueres som kode i stedet for å vises som tekst, slik at en angriper kan utføre kommandoer i serverens kontekst.
Er SSTI det samme som XSS?
Nei. XSS injiserer skript som kjører i offerets nettleser, mens SSTI injiserer kode som malmotoren evaluerer på selve serveren, og det er derfor SSTI kan føre direkte til ekstern kjøring av kode.
Hvilke malmotorer er sårbare for SSTI?
Enhver motor som evaluerer uttrykk kan være sårbar hvis brukerinput når den usanisert, inkludert Jinja2, Twig og Velocity, selv om hver eksponerer forskjellige objekter og derfor forskjellige utnyttelsesbaner.
Hvordan forebygger du SSTI i CI/CD pipelines?
Skann etter farlige mønstre som render_template_string at commit tid, sandkasse-malmotorer der det ble støttet, og gate-sammenslåinger på statiske analyseresultater før koden når produksjon.
