Ushbu bo'limda server-side template injection nima ekanini muhokama qilamiz va SSTI zaifliklarini ekspluatatsiya qilishning asosiy metodologiyasini bayon qilamiz. Shuningdek, o'z template'laringizdan foydalanishingiz sizni SSTI'ga ochib qo'ymasligining yo'llarini taklif qilamiz.
Server-side template injection — hujumchi template'ning tabiiy sintaksisidan foydalanib, zararli payloadni template'ga inyeksiya qila olganda va u server tomonida bajarilganda yuzaga keladi. Template engine'lar sobit template'larni o'zgaruvchan ma'lumot bilan birlashtirib veb-sahifalar yaratish uchun mo'ljallangan. SSTI hujumlari foydalanuvchi kiritmasi ma'lumot sifatida uzatilish o'rniga, to'g'ridan-to'g'ri template'ga birlashtirilganda yuzaga kelishi mumkin. Bu hujumchilarga ixtiyoriy template direktivalarini inyeksiya qilib, template engine'ni manipulyatsiya qilishga — ko'pincha serverni to'liq nazorat qilishga imkon beradi.
SSTI zaifliklari template engine va ilova undan qanday foydalanishiga qarab turli hujumlarga ochib qo'yishi mumkin. Aksariyat hollarda SSTI ta'siri halokatli bo'lishi mumkin. Eng og'ir uchida hujumchi masofaviy kod bajarishga (RCE) erishib, back-end serverni to'liq egallab, undan ichki infratuzilmaga boshqa hujumlar qilish uchun foydalanishi mumkin. To'liq RCE mumkin bo'lmagan holatda ham hujumchi SSTI'dan file path traversal kabi boshqa yuqori jiddiylikdagi hujumlar uchun foydalanib, maxfiy ma'lumot va ixtiyoriy fayllarga o'qish huquqini olishi mumkin.
SSTI zaifliklari foydalanuvchi kiritmasi ma'lumot sifatida uzatilish o'rniga template'ga birlashtirilganda yuzaga keladi. Dinamik kontent render qilinadigan joy-tutuvchilarni (placeholders) beruvchi statik template'lar odatda SSTI'ga zaif emas. Klassik misol — har bir foydalanuvchini ismi bilan salomlaydigan email (Twig template'idan):
$output = $twig->render("Dear {first_name},", array("first_name" => $user.first_name) );Bu SSTI'ga zaif emas, chunki foydalanuvchi ismi template'ga shunchaki ma'lumot sifatida uzatilyapti. Biroq template'lar shunchaki satr bo'lgani uchun, dasturchilar ba'zan foydalanuvchi kiritmasini render'dan oldin to'g'ridan-to'g'ri template'ga birlashtiradi:
$output = $twig->render("Dear " . $_GET['name']);Bu misolda template'ga statik qiymat uzatilish o'rniga, template'ning bir qismi name GET parametri yordamida dinamik generatsiya qilinyapti. Template sintaksisi server tomonida baholangani uchun, bu hujumchiga name parametri ichiga SSTI payloadini joylashga imkon beradi:
http://vulnerable-website.com/?name={{bad-stuff-here}}Bunday zaifliklar ba'zan xavfsizlik oqibatlaridan bexabar odamlar tomonidan sifatsiz template dizayni tufayli tasodifan yuzaga keladi. Ba'zan esa bu xatti-harakat ataylab joriy qilinadi — masalan, ayrim saytlar kontent muharrirlari kabi imtiyozli foydalanuvchilarga maxsus template'larni tahrirlash yoki yuborishga ruxsat beradi.
SSTI zaifliklarini aniqlash va muvaffaqiyatli hujum qurish odatda quyidagi yuqori darajadagi jarayonni o'z ichiga oladi: Aniqlash (Detect), Identifikatsiya (Identify), Ekspluatatsiya (Exploit).
Ekspluatatsiyaga birinchi qadam — zaiflikni topa olish. Eng oddiy dastlabki yondashuv — template'ni fuzzing qilib, template ifodalarida keng ishlatiladigan maxsus belgilar ketma-ketligini (masalan ${{<%[%'"}}%\) inyeksiya qilish. Agar istisno chiqsa, bu inyeksiya qilingan template sintaksisi server tomonidan qandaydir tarzda talqin qilinayotganini bildiradi. SSTI ikki alohida kontekstda yuzaga keladi, har biri o'z aniqlash usulini talab qiladi.
Ko'p template tillari kontentni erkin kiritishga imkon beradi. Masalan, render('Hello ' + username) kodini ko'rib chiqing. Parametr qiymati sifatida matematik amal berib, bu SSTI uchun kirish nuqtasi ekanini sinash mumkin:
http://vulnerable-website.com/?username=${7*7}Agar natijada Hello 49 chiqsa, bu matematik amal server tomonida baholanayotganini ko'rsatadi — SSTI uchun yaxshi proof-of-concept.
Boshqa hollarda zaiflik foydalanuvchi kiritmasi template ifodasi ichiga joylanganda ochiladi:
greeting = getQueryParameter('greeting')
engine.render("Hello {{"+greeting+"}}", data)Bu kontekst baholashda osongina o'tkazib yuboriladi, chunki u aniq XSS bermaydi. Sinash uchun avval parametrda to'g'ridan-to'g'ri XSS yo'qligini aniqlang, so'ng odatiy template sintaksisidan foydalanib iboradan chiqishga urining:
http://vulnerable-website.com/?greeting=data.username}}<tag>Agar natija ixtiyoriy HTML bilan birga to'g'ri render qilinsa (Hello Carlos<tag>), bu SSTI zaifligi mavjudligining muhim belgisidir.
Template injection imkoniyatini aniqlaganingizdan so'ng, keyingi qadam — template engine'ni identifikatsiya qilish. Ko'p template tillari o'xshash sintaksisdan foydalanadi. Noto'g'ri sintaksisni yuborish ko'pincha yetarli, chunki natijadagi xato xabari template engine'ni (ba'zan hatto versiyani) aniq aytadi. Masalan, <%=foobar%> Ruby'ga asoslangan ERB engine'idan xato keltirib chiqaradi. Bitta payload bir necha tilda muvaffaqiyatli javob berishi mumkin — masalan {{7*'7'}} Twig'da 49, Jinja2'da 7777777 qaytaradi.
SSTI'ning oldini olishning eng yaxshi yo'li — foydalanuvchilarga template'larni o'zgartirish yoki yangi yuborishga ruxsat bermaslik. Yana bir usul — iloji boricha Mustache kabi "logic-less" (mantiqsiz) template engine'idan foydalanish, mantiqni taqdimotdan ajratish. Boshqa chora — foydalanuvchi kodini faqat xavfli modul va funksiyalar olib tashlangan sandbox muhitida bajarish. Nihoyat, template muhitini qulflangan Docker konteynerida joylashtirib, o'zingizning sandboxingingizni qo'llash mumkin.