Server Side Template Injection o zaman baş verir ki, təcavüzkar template-ə zərərli yük yeritmək üçün yerli template sintaksisindən istifadə edə bilsin, sonra bu, server tərəfində yerinə yetirilir. Template engine-lər sabit template-ləri uçucu məlumatlarla birləşdirərək veb səhifələr yaratmaq üçün nəzərdə tutulmuşdur. Server Side Template Injection hücumları, istifadəçi girişi məlumat kimi ötürülmək əvəzinə, birbaşa template-ə birləşdirildikdə baş verə bilər. Bu, təcavüzkarlara template engine-i manipulyasiya etmək üçün ixtiyari template direktivlərini yeritməyə imkan verir və çox vaxt onlara server üzərində tam nəzarəti ələ keçirməyə imkan verir.
Vulnerable kod nümunəsi aşağıdakı birinə baxın:
$output = $twig->render("Dear " . $_GET['name']);
Əvvəlki nümunədə template-in özü GET parametr adından istifadə edərək dinamik şəkildə yaradılır. Template sintaksisi server tərəfində qiymətləndirilir, bu, potensial olaraq təcavüzkarın Server Side Template Injection yükünü ad parametri daxilində aşağıdakı kimi yerləşdirməyə imkan verir:
Server Side Template Injection hücumunun qurulması
Aşkar etmə
Hər hansı zəiflikdə olduğu kimi, istismara doğru ilk addım onu tapa bilməkdir. Ola bilsin ki, ən sadə ilkin yanaşma, ${<%[%'"}}%\ poliqlotu kimi şablon ifadələrində çox istifadə olunan xüsusi simvolların ardıcıllığını yeridərək template-i qeyri-müəyyənləşdirməyə cəhd etməkdir.
Serverin həssas olub-olmadığını yoxlamaq üçün parametr və verilən faydalı yüklə bağlı adi məlumatlarla cavab arasında fərqləri görməlisiniz. Səhv atılırsa, serverin həssas olduğunu və hətta hansı mühərrikin engine-in anlamaq asan olacaq. Lakin siz həmçinin həssas server tapa bilərsiniz, əgər siz onun verilmiş faydalı yükü əks etdirəcəyini gözləyirdinizsə və o, əks olunmursa və ya cavabda çatışmayan simvollar varsa.
Detect - Plaintext context
Verilmiş daxiletmə render olunur və cavabda əks olunur. Bu asanlıqla sadə XSS zəifliyi ilə səhv salınır, lakin template ifadəsi daxilində riyazi əməliyyatlar qurmağa cəhd etsəniz, onu fərqləndirmək asandır:
{{7*7}}
${7*7}
<%= 7*7 %>
${{7*7}}
#{7*7}
*{7*7}
Detect - Code context
Bu hallarda istifadəçi girişi template ifadəsinə yerləşdirilir:
engine.render("Hello {{"+greeting+"}}", data)
Həmin səhifənin URL girişi bu ilə oxşar ola bilər: http://vulnerable-website.com/?greeting=data.username
Əgər greeting parametrini fərqli dəyərə dəyişsəniz, cavabda istifadəçi adı olmayacaq, lakin aşağıdakı kimi bir şeyə daxil olsanız: http://vulnerable-website.com/?greeting=data.username}}hello, cavab olacaq istifadəçi adını ehtiva edir (əgər bağlanan şablon ifadə simvolları }} idisə). Bu test zamanı xəta baş verərsə, serverin həssas olduğunu tapmaq daha asan olacaq.
Müəyyən etmək
Template enjeksiyon potensialını aşkar etdikdən sonra növbəti addım template mühərrikini müəyyən etməkdir. Çox sayda template dilləri olmasına baxmayaraq, onların bir çoxu HTML simvolları ilə toqquşmamaq üçün xüsusi olaraq seçilmiş çox oxşar sintaksisdən istifadə edir.
Əgər şanslısınızsa, server səhvləri çap edəcək və siz xətaların içərisində istifadə olunan engine-i tapa biləcəksiniz. Səhvlərə səbəb ola biləcək bəzi mümkün yüklər:
Əks halda, müxtəlif dillərə aid faydalı yükləri əl ilə sınamalı və onların template mühərriki tərəfindən necə şərh edildiyini öyrənməli olacaqsınız. Bunu etməyin ümumi yolu müxtəlif template mühərriklərindən sintaksisdən istifadə edərək ixtiyari riyazi əməliyyatları yeritməkdir. Daha sonra onların uğurla qiymətləndirilib-qiymətləndirilmədiyini müşahidə edə bilərsiniz. Bu prosesə kömək etmək üçün aşağıdakılara bənzər bir qərar ağacından istifadə edə bilərsiniz:
Exploit
Read
Template inyeksiyasını tapdıqdan və template mühərrikini müəyyən etdikdən sonra ilk addım sənədləri oxumaqdır. Əsas maraq sahələri bunlardır:
Əsas sintaksisi əhatə edən "For Template Authors" bölmələri.
'Security Considerations' - çox güman ki, sınaqdan keçirdiyiniz proqramı yaradanlar bunu oxumayıblar və onda bəzi faydalı göstərişlər ola bilər.
Daxili metodların, funksiyaların, filtrlərin və dəyişənlərin siyahıları.
Extensions/plugins siyahıları - bəziləri standart olaraq aktivləşdirilə bilər.
Araşdırma
Heç bir istismarın özünü təqdim etmədiyini fərz etsək, növbəti addım tam olaraq nəyə çıxışınız olduğunu öyrənmək üçün ətraf mühiti araşdırmaqdır. Siz həm template engine tərəfindən təmin edilmiş standart obyektləri, həm də tərtibatçı tərəfindən template-ə ötürülən tətbiqə aid obyektləri tapa bilərsiniz. Bir çox template sistemləri əhatə dairəsində olan hər şeyi ehtiva edən "self" və ya namespace obyektini və obyektin atributlarını və metodlarını siyahıya salmaq üçün idiomatik bir yolu ifşa edir.
Daxili öz-özünə obyekt yoxdursa, SecLists və Burp Intruder-in söz siyahısı kolleksiyasından istifadə edərək dəyişən adlarını bruteforce etməli olacaqsınız.
Tərtibatçı tərəfindən təmin edilən obyektlərin xüsusilə həssas məlumatları ehtiva etmə ehtimalı var və proqram daxilində müxtəlif templatelər arasında dəyişə bilər, ona görə də bu proses ideal olaraq hər bir fərqli template-ə fərdi şəkildə tətbiq edilməlidir.
Hücum
Bu nöqtədə sizin əlinizdə olan hücum səthi haqqında dəqiq təsəvvürünüz olmalıdır və istifadə edilə bilən zəifliklər üçün hər bir funksiyanı nəzərdən keçirərək ənənəvi təhlükəsizlik auditi üsullarına davam edə bilməlisiniz. Buna daha geniş tətbiq kontekstində yanaşmaq vacibdir - bəzi funksiyalar tətbiqə xas xüsusiyyətlərdən istifadə etmək üçün istifadə edilə bilər. İzlənəcək nümunələr ixtiyari obyekt yaradılması, ixtiyari faylın oxunması/yazılması, uzaq fayl daxil edilməsi, məlumatın açıqlanması və imtiyazların artırılması zəifliklərini işə salmaq üçün template inyeksiyasından istifadə edəcək.
#set($str=$class.inspect("java.lang.String").type)
#set($chr=$class.inspect("java.lang.Character").type)
#set($ex=$class.inspect("java.lang.Runtime").type.getRuntime().exec("whoami"))
$ex.waitFor()
#set($out=$ex.getInputStream())
#foreach($i in [1..$out.available()])
$str.valueOf($chr.toChars($out.read()))
#end
Ətraflı məlumat
Thymeleaf (Java)
SSTI üçün tipik test ifadəsi ${7*7}-dir. Bu ifadə Thymeleaf-da da işləyir. Uzaqdan kod icrasına nail olmaq istəyirsinizsə, aşağıdakı test ifadələrindən birini istifadə edə bilərsiniz:
Ancaq daha əvvəl qeyd etdiyimiz kimi, ifadələr yalnız Thymeleaf atributlarında işləyir. Şablonda fərqli bir yerdə ifadə istifadə etmək lazımdırsa, Thymeleaf ifadənin daxil edilməsini dəstəkləyir. Bu funksiyadan istifadə etmək üçün siz [[...]] və ya [(...)] daxilində ifadə qoymalısınız (xüsusi simvollardan qaçmağın lazım olub-olmamasından asılı olaraq birini və ya digərini seçin). Beləliklə, Thymeleaf üçün sadə SSTI aşkarlama yükü [[${7*7}]] olacaqdır.
Yuxarıdakı aşkarlama yükünün işləmə ehtimalı çox aşağıdır. SSTI zəiflikləri adətən kodda template dinamik şəkildə yaradıldıqda baş verir. Thymeleaf, standart olaraq, belə dinamik şəkildə yaradılan template-ə icazə vermir və bütün templatelər daha əvvəl yaradılmalıdır. Buna görə də, əgər tərtibatçı tez bir sətirdən template yaratmaq istəyirsə, öz TemplateResolver-ini yaratmalıdır. Bu mümkündür, lakin çox nadir hallarda olur.
Thymeleaf template mühərrikinin sənədlərinə daha dərindən nəzər salsaq, ifadənin əvvəlcədən işlənməsi adlı maraqlı bir xüsusiyyət tapacağıq. Qoşa alt xətt (...) arasında yerləşdirilən ifadələr əvvəlcədən işlənir və ilkin işlənmənin nəticəsi müntəzəm emal zamanı ifadənin bir hissəsi kimi istifadə olunur. Budur Thymeleaf sənədlərindən rəsmi bir nümunə:
