Wstrzyknięcie szablonu po stronie serwera (SSTI) to luka w zabezpieczeniach, w której dane wprowadzone przez użytkownika są oceniane przez silnik szablonów zamiast być renderowane jako zwykły tekst. W ten sposób atakujący może uruchomić dowolny kod na serwerze.
Jak działa wstrzykiwanie szablonów po stronie serwera w tle
Wstrzyknięcie szablonu po stronie serwera ma miejsce, gdy dane wprowadzane przez użytkownika są osadzane bezpośrednio w silniku szablonów i oceniane bez odpowiedniej dezynfekcji lub izolacji. Tworzy to lukę w zabezpieczeniach SSTI, która umożliwia atakującemu wstrzyknięcie specjalnie spreparowanych ładunków SSTI (na przykład: {{7*7}} w Jinja2), które silnik będzie oceniać, umożliwiając wszystko, od ujawnienia danych po wykonanie dowolnego kodu w kontekście serwera. Ponieważ różne silniki szablonów udostępniają różne obiekty i interfejsy API, ładunki SSTI różnią się w zależności od platformy, ale wiążą się z tym samym zagrożeniem: pozwalają one na to, aby niezaufane dane wejściowe wymknęły się oczekiwanemu przepływowi renderowania i zostały wykonane w środowisku uruchomieniowym aplikacji, co często prowadzi do całkowitego zdalnego wykonania kodu lub ruchu bocznego, jeśli nie zostaną sprawdzone.
Minimalny przykład podatności w Jinja2
Jeśli użytkownik wysyła ?nazwa={{7*7}}, aplikacja to oceni i zwróci Witaj 49To jest podręcznikowy przykład podatności SSTI.
Minimalny przykład podatności w Twig
Atakujący może wstrzykiwać ładunki SSTI, takie jak {{7*7}} aby udowodnić wykonanie kodu. Niebezpieczeństwo: proste wstrzyknięcie może przerodzić się w odczytywanie plików, wykonywanie poleceń systemu operacyjnego lub głębsze wnikanie w infrastrukturę.
Eksploatacja w świecie rzeczywistym: ładunki SSTI wyzwalające zdalne wykonanie kodu
Gdy pojawi się luka w zabezpieczeniach SSTI, atakujący próbują przejść od teorii dowodu koncepcji do pełnego RCERóżne silniki szablonów inaczej obsługują ładunki.
Ładunki Jinja2
- {{7*7}} → wykonywanie działań arytmetycznych
- {{config.items()}} → wycieka konfiguracja serwera.
- {{ “”.__class__.__mro__[2].__subclasses__() }} → ścieżka do RCE
Ładunki prędkościowe
- #ustaw($x=”7″)${x} → ominięcie wtrysku
- #set($a=$class.inspect(“java.lang.Runtime”)) → bezpośredni dostęp do środowiska wykonawczego
Ładunki Twig
- {{7*7}} → arytmetyka
- {{app.request.server.all}} → zmienne środowiskowe
- {{_self.env.registerUndefinedFilterCallback(‘system’)}} → wykonanie kodu
Te ładunki SSTI pokazują, jak ta sama luka w zabezpieczeniach różnych silników prowadzi do różnych eksploatować ścieżki, ale zawsze są niebezpieczne.
Gdzie kryje się wstrzykiwanie szablonów po stronie serwera CI/CDAplikacje sterowane
Wstrzyknięcie szablonu po stronie serwera nie jest zagrożeniem tylko dla aplikacji internetowych; pojawia się ono w nowoczesny CI/CD pipelines też. Typowe kryjówki obejmują:
- Wykresy steru w Kubernetes, gdzie wartości szablonów są renderowane dynamicznie
- Szablony poczty elektronicznej które łączą dane wejściowe kontrolowane przez użytkownika
- Dashboards gdzie ciągi zapytań lub dane konfiguracyjne są wstrzykiwane do szablonów
- Skrypty DevOps które generują kod HTML/Markdown przy użyciu silników szablonów.
Przykład:
If.Wartości.wiadomość pochodzi z niezaufanych danych wejściowych, powoduje wstrzyknięcie szablonu po stronie serwera w Twoim wdrożeniu pipeline sama.
Zapobieganie SSTI dzięki bezpieczniejszym wzorcom szablonów i analizie statycznej
Aby ograniczyć luki w zabezpieczeniach SSTI, konieczne jest stosowanie lepszych wzorców kodowania i wczesne wykrywanie.
Bezpieczne wzorce
- ❌ Nie używaj ciąg_szablonu_renderowania lub odpowiednik
- ✅ Używaj wstępnie zdefiniowanych plików szablonów i przekazuj zdezynfekowane zmienne
- ✅ Silniki szablonów piaskownicy, jeśli są dostępne
- ✅ Sprawdź poprawność danych wprowadzanych przez użytkownika i usuń je przed renderowaniem
Mini lista kontrolna dla programistów
- Nigdy nie renderuj bezpośrednio surowych danych wejściowych użytkownika
- Używaj szablonów w trybie piaskownicy, jeśli są obsługiwane
- Oczyść i zweryfikuj wszystkie zmienne szablonu
- Unikaj niestandardowych ewaluatorów szablonów
- Zeskanuj kod dla ciąg_szablonu_renderowania lub wzorce łączenia ciągów znaków
Analiza statyczna a systemy kontroli wersji mogą oznaczać ryzykowne konstrukcje zanim dotrą one do produkcji.
Osadzanie kontroli SSTI w DevSecOps Pipelines
Wczesne wykrycie wstrzyknięcia szablonu po stronie serwera jest tańsze i bezpieczniejsze niż późniejsze naprawianie. Zespoły DevSecOps powinny osadzić kontrole w pipelines:
- Commit hooks: odrzucić commitz niebezpiecznymi funkcjami (ciąg_szablonu_renderowania)
- Analizatory statyczne:skanuj w poszukiwaniu ryzyka wstrzyknięcia szablonu po stronie serwera w kodzie szablonowym
- Walidacja zależności:oznacz przestarzałe silniki szablonów ze znanymi lukami w zabezpieczeniach SSTI
- Pipeline Bramy:bloki łączą się, dopóki kontrole SSTI nie zakończą się powodzeniem
Dzięki włączeniu wykrywania ładunku SSTI do CI/CD, zapobiegasz rozprzestrzenianiu się podatnego na ataki kodu.
Nie pozwól, aby wstrzyknięcie szablonu po stronie serwera przedostało się do Twojego stosu
Pojedyncze wstrzyknięcie szablonu po stronie serwera może prowadzić do eskalacji sztuczek matematycznych ({{7*7}}) do pełnego zdalnego wykonania kodu. Luki w zabezpieczeniach SSTI pojawiają się nie tylko w aplikacjach internetowych, ale także w CI/CD pipelines, wykresy Helm i szablony wiadomości e-mail.
Kluczowe dania na wynos
- Nigdy nie umieszczaj surowych danych wprowadzanych przez użytkownika w szablonach
- Sprawdź poprawność i oczyść wszystkie zmienne dynamiczne
- Różne silniki (Jinja2, Velocity, Twig) mają różne ładunki SSTI, ale wszystkie można uzbroić
- Użyj analizy statycznej i bramek odpornych na awarie w pipelines
- Regularnie sprawdzaj szablony w swoim stosie
Xygeni Skanuje bazę kodu w poszukiwaniu luk w zabezpieczeniach i innych niebezpiecznych wzorców kodowania w momencie ich pojawienia się, wychwytując ryzykowne konstrukcje, takie jak nieoczyszczone renderowanie szablonów, zanim dotrą one do produkcji, z najniższym wskaźnikiem fałszywie pozytywnych wyników w teście OWASP Benchmark. Xygeni CI/CD oraz IaC security skanowanie rozszerza ten sam zasięg na pipeline konfiguracje, wykresy Helm i skrypty kompilacji, sygnalizując błędne konfiguracje i złośliwe polecenia przed ich wysłaniem. Gdy Xygeni wykryje lukę w zabezpieczeniach, AI AutoFix generuje poprawkę kontekstową, gotową do użycia przez programistę, bezpośrednio w systemie. pull request, więc naprawa nie będzie czekać do następnego sprintu.
W DevSecOps wyłapywanie wstrzyknięć szablonów w pipeline to właśnie na tym etapie, a nie po wdrożeniu, chroni się pojedynczy ładunek przed całkowitym naruszeniem bezpieczeństwa.
Zacznij za darmo. Nie potrzebujesz karty kredytowej, zeskanuj swoje pierwsze repozytorium w kilka minut.
FAQ
Czym jest wstrzykiwanie szablonu po stronie serwera?
Atak SSTI ma miejsce, gdy dane wejściowe użytkownika są przekazywane do silnika szablonów i oceniane jako kod, a nie wyświetlane jako tekst. Umożliwia to atakującemu wykonywanie poleceń w kontekście serwera.
Czy SSTI to to samo co XSS?
Nie. XSS wstrzykuje skrypt, który uruchamia się w przeglądarce ofiary; SSTI wstrzykuje kod, który silnik szablonów ocenia bezpośrednio na serwerze, dlatego SSTI może prowadzić bezpośrednio do zdalnego wykonania kodu.
Które silniki szablonów są podatne na atak SSTI?
Każdy silnik oceniający wyrażenia może być podatny na ataki, jeśli dane wejściowe użytkownika dotrą do niego bez odpowiednich zabezpieczeń. Dotyczy to m.in. Jinja2, Twig i Velocity, chociaż każdy z nich ujawnia inne obiekty, a zatem inne ścieżki dostępu do luk w zabezpieczeniach.
Jak zapobiegać zakażeniom skóry i tkanek miękkich u dzieci? CI/CD pipelines?
Przeskanuj w poszukiwaniu niebezpiecznych wzorców, takich jak render_template_string at commit czas, silniki szablonów piaskownicy, o ile są obsługiwane, i scalanie bramek w wynikach analizy statycznej przed dotarciem kodu do produkcji.
