SSTI czyli Server-Side Template Injection – za tą skomplikowaną nazwą kryje się bardzo niebezpieczna podatność występująca głównie w technologiach webowych pozwalająca w wielu przypadkach na przejęcie kontroli nad podatnym systemem.

Podatność tą często można spotkać także pod nazwą Double Evaluation czy Expression Language Injection i jest ona klasą podatności typu Code Injection (Wstrzyknięcie kodu). Z poniższego video w skrócie dowiesz się, czym templates„, jak pojawiają się na stronie i dlaczego mogą być niebezpieczne:

Tradycyjnie, do materiału video dołączamy także spis przydatnych linków i referencji zarówno dla osób, które chcą dowiedzieć się, jak tego typu podatność wyeliminować, jak również dla osób, które chcą się dowiedzieć jak skutecznie ją wykorzystywać. Całość poniżej.

SSTI – Chcę się bronić

Obrona przed podatnością SSTI zależy głównie od technologii, jakiej używamy w naszej aplikacji. Niestety, ale wiele zależy od tego, jaki silnik szablonów wykorzystujemy, więc nie ma jednej idealnej metody umożliwiającej zabezpieczenie się przed wszystkimi przypadkami podatności. Wszystkie środki zaradcze powinny być podejmowane per technologia, np.:

  • Ustawienie Sandboxa tam, gdzie to możliwe (np. Twig Sandbox mode i odpowiednie „escapowanie„) – utrudni to życie atakującemu, jeśli dojdzie do podatności
  • Patchowanie silników – np. popularne podatności Apache Struts powinny być usuwane tak szybko, jak to możliwe – warto monitorować Security Bulletiny technologii, której używamy
  • Analiza statyczna kodu, przeprowadzanie testów penetracyjnych – jest to jedna z metod sprawdzenia, czy na pewno nie mamy tej podatności, jednak zorganizowanie testów penetracyjnych to większe przedsięwzięcie i zazwyczaj nie jednorazowe
  • Implementacja Web Application Firewalla, jeśli mamy taką możliwość – wiele prób ataku jest charakterystyczna ze względu na kluczowe słowa i pomoże odsiać boty i mniej sprawnych atakujących (jednak obejście WAF’ów czasami jest możliwe)
  • Powierzchowne testy można wykonać we własnym zakresie zgodnie z OWASP Testing Guide:
  • I na koniec interesujący przypadek Apache Struts jako ciekawa lektura: https://securitylab.github.com/research/apache-struts-double-evaluation/

SSTI – Chcę atakować

Atakowanie SSTI zawsze zaczyna się od testowania. Głównymi podejrzanymi są wszelkie wystąpienia „XSS-ów” (tak, podatność SSTI czasami objawia się jako XSS, dopóki nie wstawimy magicznego wzoru mnożenia), podejrzane są także wszelkie miejsca, gdzie uda się wykonać mnożenie poprzez wstawienie specjalnego wyrażenia opisanego i na slajdach, i w poniższych artykułach.

Samo „wykonanie mnożenia” jednak nie świadczy jeszcze o podatności SSTI, a nawet czasami może być pomylone z Client-Side Template Injection (CSTI), czyli takim „Angularowym XSS’em„.

Faktyczny wpływ podatności SSTI można oszacować dopiero po udanej próbie eksploitacji, która zazwyczaj wiąże się z napisaniem wyrażenia w języku danego silnika szablonów. Jednak bardzo wiele przypadków zostało opublikowanych już w sieci, więc nie powinno być problemu ze znalezieniem ich. Czasami wykorzystanie podatności może nie być możliwe z powodu nietypowych ograniczeń – włączonych opcji bezpieczeństwa np. sandbox, lub warunków wynikających z innych mechanizmów aplikacji – ograniczenie długości wyrażenia, które możemy wpisać albo blokowanie jakichś kluczowych znaków z poziomu Web Application Firewalla.

  • Warto zapoznać się z tutorialem „od podstaw” dostępnym w Web Security Academy firmy Portswigger.
  • Dodatkowe ciekawe informacje można znaleźć w artykule na stronie firmy Cobalt
  • Kolejne dobre podsumowanie powyższych informacji znajdziemy na Hacktricks
  • Strategie atakowania podatności wstrzyknięcia Expression Language (Java)
  • Payload na wykonanie kodu w engine Razor (.NET, w chwili pisania mało jest o nim informacji)
  • Narzędzie do automatycznego znajdowania i wykorzystywania niektórych przypadków template injection: TplMap
  • I na koniec wordlista z różnymi payload’ami do wykorzystania przeciwko podatnym aplikacjom w celu testowania / atakowania ze zbioru PayloadAllTheThings

Dodatkowe referencje: obrazek tytułowy pochodzi z wspomnianego artykułu HackTricks.