Merhaba değerli okurlar bugün sizlere SSTI (Server Side Template Injection) hakkında konuşacağım.
SSTI Nedir?
Server Side Template Injection (SSTI): Web uygulamalarında verileri sunmak için kullanılan şablonlara beklentinin dışında girdi eklenerek harekete geçiren güvenlik zafiyetidir.Sunucu tarafı şablon enjeksiyonu, bir saldırganın şablona kötü amaçlı bir yük enjekte etmek için yerel şablon syntaxı kullanabilmesi ve ardından sunucu tarafında yürütülmesidir.Şablon motorları, sabit şablonları değişken verilerle birleştirerek web sayfaları oluşturmak üzere tasarlanmıştır. SSTI saldırıları, kullanıcı girişi veri olarak iletilmek yerine doğrudan şablona birleştirildiğinde oluşabilir. Bu, saldırganların şablon motorunu manipüle etmek için rasgele şablon yönergeleri enjekte etmelerine olanak tanır ve genellikle sunucunun tam kontrolünü ele geçirmelerini sağlar. Adından da anlaşılacağı gibi, sunucu tarafı şablon enjeksiyon yükleri sunucu tarafında teslim edilir ve değerlendirilir, bu da potansiyel olarak onları tipik bir istemci tarafı şablon enjeksiyonundan çok daha tehlikeli hale getirir.
SSTI Güvenlik Açıkları Nasıl Ortaya Çıkar?
SSTI güvenlik açıkları, kullanıcı girişi veri olarak iletilmek yerine şablonlara birleştirildiğinde ortaya çıkar. Dinamik içeriğin işlenmediği yer tutucular sağlayan statik şablonlar genellikle SSTI'ya karşı savunmasız değildir.
Etkileri Nedir?
Sunucu tarafı şablon enjeksiyon güvenlik açıkları, söz konusu şablon altyapısına ve uygulamanın tam olarak nasıl kullandığına bağlı olarak web sitelerini çeşitli saldırılara maruz bırakabilir. Bazı nadir durumlarda, bu güvenlik açıkları gerçek bir güvenlik riski oluşturmaz. Ancak, çoğu zaman sunucu tarafı şablon enjeksiyonunun etkisi felaket olabilir. Sonunda bir saldırgan potansiyel olarak uzaktan kod yürütmeyi başarabilir, back-end sunucunun kontrolünü tamamen ele geçirebilir ve onu iç altyapıya yönelik diğer saldırıları gerçekleştirmek için kullanabilir. Tam uzaktan kod yürütmenin mümkün olmadığı durumlarda bile, saldırgan çoğu zaman sunucu tarafı şablon enjeksiyonunu diğer birçok saldırının temeli olarak kullanmaya devam edebilir ve potansiyel olarak sunucudaki hassas verilere ve rasgele dosyalara okuma erişimi kazanabilir.
SSTI Saldırısı Oluşturma
Tespit Etmek:
SSTI güvenlik açıkları genellikle karmaşık oldukları için değil, yalnızca bunları açıkça arayan denetçiler için gerçekten belirgin oldukları için fark edilmez. Bir güvenlik açığının bulunduğunu tespit edebiliyorsanız, bu güvenlik açığından yararlanmak çok kolay olabilir. Herhangi bir güvenlik açığında olduğu gibi, sömürüye doğru atılan ilk adım onu bulabilmektir. Belki de en basit başlangıç yaklaşımı şablon ifadelerinde yaygın olarak kullanılan bir dizi özel karakterleri (${{<%[%'"}}%\) enjekte ederek şablonu bulanıklaştırmayı denemektir.
Plaintext context:
Çoğu şablon dili, HTML etiketlerini doğrudan kullanarak veya HTTP yanıtı gönderilmeden önce back-end'de HTML'ye işlenecek şablonun yerel syntaxını kullanarak içeriği serbestçe girmenize olanak tanır.Bu bazen XSS için kullanılabilir ve aslında genellikle basit bir XSS güvenlik açığı ile karıştırılır. Bununla birlikte, matematiksel işlemleri parametrenin değeri olarak ayarlayarak, bunun SSTI saldırısı için potansiyel bir giriş noktası olup olmadığını da test edebiliriz. Örneğin, yandaki savunmasız kodu içeren bir şablon düşünün:
render('Hello ' + username)
denetim sırasında aşağıdaki gibi bir URL isteyerek SSTI enjeksiyonunu test edebiliriz:
http://savunmasiz-website.com/?username=${7*7}
elde edilen sonuç merhaba 49 çıkıyorsa işlemin sunucu tarafında değerlendirildiğini gösterir. Güvenlik açığı için iyi bir kanıttır.
Code context:
Aşağıdaki gibi bir parametrenin içine yerleştirilen kullanıcı tarafından kontrol edilebilen bir değişken adı şeklinde olabilir
greeting = getQueryParameter('greeting')
engine.render("Hello {{"+greeting+"}}", data)
Ve ortaya çıkan url;
Bu bağlam değerlendirme sırasında kolayca gözden kaçırılır, çünkü belirgin XSS ile sonuçlanmaz ve basit bir hashmap aramasından neredeyse ayırt edilemez. Bu bağlamda sunucu tarafı şablon enjeksiyonu için test yöntemlerinden biri, önce parametrenin değere rasgele HTML enjekte ederek doğrudan bir XSS güvenlik açığı içermediğini tespit etmektir:
http://savunmasiz-website.com/?greeting=data.username<tag>
http://savunmasiz-website.com/?greeting=data.username}}<tag>
Bu yeniden bir hata veya boş çıktı ile sonuçlanırsa, yanlış şablonlama dilinden syntax kullandınız veya şablon stili sözdizimi geçerli görünmüyorsa, sunucu tarafı şablon enjeksiyonu mümkün değildir. Alternatif olarak, çıktı rastgele HTML ile birlikte doğru şekilde işlenirse, bu, SSTI güvenlik açığının mevcut olduğunun önemli bir göstergesidir.
Identify
Bir sonraki adımımız ise şablon motorunu tanımlamak.Çok sayıda şablon dili olmasına rağmen, çoğu HTML karakterleriyle çakışmamak için özel olarak seçilmiş çok benzer syntaxi kullanır. Sonuç olarak, hangi şablon motorunun kullanıldığını test etmek için sondalama yükleri oluşturmak nispeten basit olabilir.Geçersiz sözdizimi göndermek çoğu zaman yeterlidir, çünkü sonuçta ortaya çıkan hata mesajı size şablon motorunun tam olarak ne olduğunu ve hatta bazen hangi sürümün olduğunu söyleyecektir.Aksi takdirde, dile özgü farklı yükleri el ile sınamanız ve bunların şablon altyapısı tarafından nasıl yorumlandığını incelemeniz gerekir.
Exploit
Olası bir güvenlik açığının bulunduğunu tespit ettikten ve şablon altyapısını başarıyla tanımladıktan sonra, bu güvenlik açığından yararlanmanın yollarını bulmaya başlayabilirsiniz.
Araştırdıklarım bundan ibaretti, okuduğunuz için teşekkürler.
Not: Eksiklerim - yanlışlarım olabilir düzeltmek istediğiniz yer olursa yorumlarda belirtiniz.
Son düzenleme:
