Bu bölümde sunucu taraflı şablon enjeksiyonunun ne olduğunu konuşacağız ve bu güvenlik açıklarından yararlanmaya yönelik temel metodolojiyi özetleyeceğiz. Ayrıca, kendi şablon kullanımınızın sizi bu zafiyete maruz bırakmadığından emin olmanın yollarını da açıklayacağız.
Lablar:
Sunucu taraflı şablon enjeksiyonu güvenlik açıklarının ardındaki temel kavramlara zaten aşina iseniz ve bunları bazı gerçekçi, bilerek saldırıya açık bırakılmış hedefler üzerinde kullanma alıştırması yapmak istiyorsanız bu konunun altından tüm laboratuvarlara erişebilirsiniz.
Bu teknik ilk olarak PortSwigger tarafından konuyla ilgili 2015 araştırma makalesinde belgelendi. Bu güvenlik açıklarından bazılarından canlı web sitelerinde nasıl yararlanabildiğimizi merak ediyorsanız, araştırma sayfasında tam bir yazı mevcuttur. Link: Server-Side Template Injection (İngilizce).
Sunucu Taraflı Şablon Enjeksiyonu Nedir?
Sunucu taraflı şablon enjeksiyonu, bir saldırganın yerel şablon syntax'ını kullanarak bir şablona kötü amaçlı bir veri enjekte etmesi ve bunun daha sonra sunucu tarafında yürütülmesidir.
Şablon motorları, sabit şablonları geçici verilerle birleştirerek web sayfaları oluşturmak için tasarlanmıştır. Sunucu tarafı şablon ekleme saldırıları, kullanıcı girişinin veri olarak iletilmek yerine doğrudan bir şablonda birleştirilmesi durumunda meydana gelebilir. Bu, saldırganların şablon motorunu manipüle etmek için rastgele şablon yönergeleri eklemesine olanak tanır ve genellikle sunucunun tam kontrolünü ele geçirmelerine olanak tanır. Adından da anlaşılacağı gibi, sunucu tarafı şablon enjeksiyon verileri sunucu tarafında teslim edilir ve değerlendirilir; bu da onları tipik bir istemci tarafı şablon enjeksiyonundan potansiyel olarak çok daha tehlikeli hale getirir.
Sunucu taraflı şablon enjeksiyonunun etkisi nedir?
Sunucu tarafı şablon enjeksiyon güvenlik açıkları, söz konusu şablon motoruna ve uygulamanın onu 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.
Ölçeğin en uç noktasında, bir saldırgan potansiyel olarak uzaktan kod yürütmeyi başarabilir, arka uç sunucunun tam kontrolünü ele geçirebilir ve bunu dahili altyapıya başka saldırılar gerçekleştirmek için kullanabilir.
Tam uzaktan kod yürütmenin mümkün olmadığı durumlarda bile, bir saldırgan sıklıkla sunucu tarafı şablon enjeksiyonunu diğer birçok saldırının temeli olarak kullanabilir ve potansiyel olarak sunucudaki hassas verilere ve rastgele dosyalara okuma erişimi elde edebilir.
Sunucu taraflı şablon enjeksiyon güvenlik açıkları nasıl ortaya çıkar?
Sunucu taraflı şablon enjeksiyon güvenlik açıkları kullanıcı girişinin veri olarak iletilmek yerine şablonlar halinde birleştirilmesiyle ortaya çıkar.
Dinamik içeriğin oluşturulduğu yer tutucuları sağlayan statik şablonlar genellikle sunucu tarafı şablon eklemeye karşı savunmasız değildir. Klasik bir örnek ise her kullanıcıyı kendi adıyla karşılayan bir e-posta olabilir. Örneğin bir Twig şablonundan alınan bir kod dizesi:
Bu, sunucu tarafı şablon enjeksiyonuna karşı savunmasız değildir çünkü kullanıcının adı yalnızca şablona veri olarak aktarılır.
Bununla birlikte, şablonlar basit dizeler olduğundan, web geliştiricileri bazen kullanıcı girişini oluşturma öncesinde doğrudan şablonlara birleştirir. Yukarıdakine benzer bir örneği ele alalım, ancak bu sefer kullanıcılar e-postanın bazı kısımlarını gönderilmeden önce özelleştirebiliyor. Örneğin, kullanılacak adı seçebilirler:
Bu örnekte, şablona statik bir değer iletilmek yerine şablonun bir kısmı GET parametre adı kullanılarak dinamik olarak oluşturuluyor. Şablon sözdizimi sunucu tarafında değerlendirildiğinden, bu durum potansiyel olarak bir saldırganın name parametresinin içine sunucu tarafı şablon enjeksiyon payload'ını aşağıdaki gibi yerleştirmesine olanak tanır:
Bunun gibi güvenlik açıkları bazen güvenlik etkilerine aşina olmayan kişiler tarafından yapılan kötü şablon tasarımından kaynaklanan kazalardan kaynaklanır. Yukarıdaki örnekte olduğu gibi, bazıları kullanıcı girdisi içeren, birleştirilmiş ve bir şablona gömülmüş farklı bileşenler görebilirsiniz. Bazı yönlerden bu, kötü yazılmış hazırlanmış ifadelerde meydana gelen SQL enjeksiyon güvenlik açıklarına benzer.
Ancak bazen bu davranış aslında kasıtlı olarak uygulanmaktadır. Örneğin, bazı web siteleri, içerik editörleri gibi belirli ayrıcalıklı kullanıcıların tasarım gereği özel şablonları düzenlemesine veya göndermesine kasıtlı olarak izin verir. Bir saldırganın bu tür ayrıcalıklara sahip bir hesabı tehlikeye atması durumunda, bu açıkça büyük bir güvenlik riski oluşturur.
Sunucu taraflı şablon enjeksiyon saldırısı oluşturma
Sunucu taraflı şablon enjeksiyon güvenlik açıklarının belirlenmesi ve başarılı bir saldırının hazırlanması genellikle aşağıdaki süreci içerir.
Tespit etmek
Sunucu taraflı şablon enjeksiyon güvenlik açıkları karmaşık oldukları için değil, yalnızca onları açıkça arayan denetçiler tarafından gerçekten görülebildiği için genellikle fark edilmez. Bir güvenlik açığının mevcut olduğunu tespit edebilirseniz, bundan faydalanmak şaşırtıcı derecede kolay olabilir. Bu özellikle korumalı alan olmayan ortamlarda geçerlidir.
Her güvenlik açığında olduğu gibi bu güvenlik açığından yararlanmanın ilk adımı onu bulabilmektir. Belki de en basit başlangıç yaklaşımı ${{<%[%'"}}%\ gibi şablon ifadelerinde yaygın olarak kullanılan bir dizi özel karakter enjekte ederek şablonu bulanıklaştırmayı denemektir. Bir istisna ortaya çıkarsa, bu, enjekte edilen şablon sözdiziminin potansiyel olarak sunucu tarafından bir şekilde yorumlandığını gösterir. Bu, sunucu tarafı şablon ekleme konusunda bir güvenlik açığının mevcut olabileceğinin bir işaretidir.
Bu güvenlik açıkları, her biri kendi algılama yöntemini gerektiren iki farklı bağlamda ortaya çıkar. Bulanıklaştırma girişimlerinizin sonuçları ne olursa olsun, aşağıdaki bağlama özgü yaklaşımları da denemek önemlidir. Fuzzing sonuçsuz kaldıysa, bu yaklaşımlardan birini kullanarak bir güvenlik açığı yine de kendini ortaya çıkarabilir. Fuzzing bir şablon enjeksiyon güvenlik açığını önermiş olsa bile, bundan yararlanmak için yine de bağlamını tanımlamanız gerekir.
Düz metin bağlamı
Çoğu şablon dili, doğrudan HTML etiketlerini kullanarak veya HTTP yanıtı gönderilmeden önce arka uçta HTML'ye işlenecek olan şablonun yerel sözdizimini kullanarak serbestçe içerik girmenize olanak tanır. Örneğin, Freemarker'da render('Hello ' + kullanıcı adı) satırı Hello Carlos gibi bir şeye dönüştürülür.
Bu bazen XSS için kullanılabilir ve aslında çoğu zaman basit bir XSS güvenlik açığıyla karıştırılır. Ancak parametrenin değeri olarak matematiksel işlemleri ayarlayarak bunun aynı zamanda sunucu tarafı şablon enjeksiyon saldırısı için potansiyel bir giriş noktası olup olmadığını test edebiliriz.
Örneğin, aşağıdaki güvenlik açığı bulunan kodu içeren bir şablonu düşünün:
Denetim sırasında aşağıdaki gibi bir URL isteyerek sunucu tarafı şablon enjeksiyonunu test edebiliriz:
Ortaya çıkan çıktının Hello 49 içermesi matematiksel işlemin sunucu tarafında değerlendirildiğini gösterir. Bu, sunucu tarafı şablon ekleme güvenlik açığına ilişkin iyi bir kavram kanıtıdır.
Matematiksel işlemi başarılı bir şekilde değerlendirmek için gereken spesifik sözdiziminin, hangi şablon motorunun kullanıldığına bağlı olarak değişeceğini unutmayın. Bunu tanımlama adımında daha ayrıntılı olarak ele alacağız.
Kod bağlamı
Diğer durumlarda daha önce e-posta örneğimizde gördüğümüz gibi, kullanıcı girişinin bir şablon ifadesine yerleştirilmesiyle güvenlik açığı ortaya çıkar. Bu, kullanıcı tarafından kontrol edilebilen bir değişken adının bir parametrenin içine yerleştirilmesi şeklinde olabilir, örneğin:
Lablar:
Sunucu taraflı şablon enjeksiyonu güvenlik açıklarının ardındaki temel kavramlara zaten aşina iseniz ve bunları bazı gerçekçi, bilerek saldırıya açık bırakılmış hedefler üzerinde kullanma alıştırması yapmak istiyorsanız bu konunun altından tüm laboratuvarlara erişebilirsiniz.
Bu teknik ilk olarak PortSwigger tarafından konuyla ilgili 2015 araştırma makalesinde belgelendi. Bu güvenlik açıklarından bazılarından canlı web sitelerinde nasıl yararlanabildiğimizi merak ediyorsanız, araştırma sayfasında tam bir yazı mevcuttur. Link: Server-Side Template Injection (İngilizce).
Sunucu Taraflı Şablon Enjeksiyonu Nedir?
Sunucu taraflı şablon enjeksiyonu, bir saldırganın yerel şablon syntax'ını kullanarak bir şablona kötü amaçlı bir veri enjekte etmesi ve bunun daha sonra sunucu tarafında yürütülmesidir.
Şablon motorları, sabit şablonları geçici verilerle birleştirerek web sayfaları oluşturmak için tasarlanmıştır. Sunucu tarafı şablon ekleme saldırıları, kullanıcı girişinin veri olarak iletilmek yerine doğrudan bir şablonda birleştirilmesi durumunda meydana gelebilir. Bu, saldırganların şablon motorunu manipüle etmek için rastgele şablon yönergeleri eklemesine olanak tanır ve genellikle sunucunun tam kontrolünü ele geçirmelerine olanak tanır. Adından da anlaşılacağı gibi, sunucu tarafı şablon enjeksiyon verileri sunucu tarafında teslim edilir ve değerlendirilir; bu da onları tipik bir istemci tarafı şablon enjeksiyonundan potansiyel olarak çok daha tehlikeli hale getirir.
Sunucu taraflı şablon enjeksiyonunun etkisi nedir?
Sunucu tarafı şablon enjeksiyon güvenlik açıkları, söz konusu şablon motoruna ve uygulamanın onu 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.
Ölçeğin en uç noktasında, bir saldırgan potansiyel olarak uzaktan kod yürütmeyi başarabilir, arka uç sunucunun tam kontrolünü ele geçirebilir ve bunu dahili altyapıya başka saldırılar gerçekleştirmek için kullanabilir.
Tam uzaktan kod yürütmenin mümkün olmadığı durumlarda bile, bir saldırgan sıklıkla sunucu tarafı şablon enjeksiyonunu diğer birçok saldırının temeli olarak kullanabilir ve potansiyel olarak sunucudaki hassas verilere ve rastgele dosyalara okuma erişimi elde edebilir.
Sunucu taraflı şablon enjeksiyon güvenlik açıkları nasıl ortaya çıkar?
Sunucu taraflı şablon enjeksiyon güvenlik açıkları kullanıcı girişinin veri olarak iletilmek yerine şablonlar halinde birleştirilmesiyle ortaya çıkar.
Dinamik içeriğin oluşturulduğu yer tutucuları sağlayan statik şablonlar genellikle sunucu tarafı şablon eklemeye karşı savunmasız değildir. Klasik bir örnek ise her kullanıcıyı kendi adıyla karşılayan bir e-posta olabilir. Örneğin bir Twig şablonundan alınan bir kod dizesi:
PHP:
$output = $twig->render("Dear {first_name},", array("first_name" => $user.first_name) );Bununla birlikte, şablonlar basit dizeler olduğundan, web geliştiricileri bazen kullanıcı girişini oluşturma öncesinde doğrudan şablonlara birleştirir. Yukarıdakine benzer bir örneği ele alalım, ancak bu sefer kullanıcılar e-postanın bazı kısımlarını gönderilmeden önce özelleştirebiliyor. Örneğin, kullanılacak adı seçebilirler:
PHP:
$output = $twig->render("Dear " . $_GET['name']);
Kod:
http://vulnerable-website.com/?name={{kotu-seyler}}Bunun gibi güvenlik açıkları bazen güvenlik etkilerine aşina olmayan kişiler tarafından yapılan kötü şablon tasarımından kaynaklanan kazalardan kaynaklanır. Yukarıdaki örnekte olduğu gibi, bazıları kullanıcı girdisi içeren, birleştirilmiş ve bir şablona gömülmüş farklı bileşenler görebilirsiniz. Bazı yönlerden bu, kötü yazılmış hazırlanmış ifadelerde meydana gelen SQL enjeksiyon güvenlik açıklarına benzer.
Ancak bazen bu davranış aslında kasıtlı olarak uygulanmaktadır. Örneğin, bazı web siteleri, içerik editörleri gibi belirli ayrıcalıklı kullanıcıların tasarım gereği özel şablonları düzenlemesine veya göndermesine kasıtlı olarak izin verir. Bir saldırganın bu tür ayrıcalıklara sahip bir hesabı tehlikeye atması durumunda, bu açıkça büyük bir güvenlik riski oluşturur.
Sunucu taraflı şablon enjeksiyon saldırısı oluşturma
Sunucu taraflı şablon enjeksiyon güvenlik açıklarının belirlenmesi ve başarılı bir saldırının hazırlanması genellikle aşağıdaki süreci içerir.
Tespit etmek
Sunucu taraflı şablon enjeksiyon güvenlik açıkları karmaşık oldukları için değil, yalnızca onları açıkça arayan denetçiler tarafından gerçekten görülebildiği için genellikle fark edilmez. Bir güvenlik açığının mevcut olduğunu tespit edebilirseniz, bundan faydalanmak şaşırtıcı derecede kolay olabilir. Bu özellikle korumalı alan olmayan ortamlarda geçerlidir.
Her güvenlik açığında olduğu gibi bu güvenlik açığından yararlanmanın ilk adımı onu bulabilmektir. Belki de en basit başlangıç yaklaşımı ${{<%[%'"}}%\ gibi şablon ifadelerinde yaygın olarak kullanılan bir dizi özel karakter enjekte ederek şablonu bulanıklaştırmayı denemektir. Bir istisna ortaya çıkarsa, bu, enjekte edilen şablon sözdiziminin potansiyel olarak sunucu tarafından bir şekilde yorumlandığını gösterir. Bu, sunucu tarafı şablon ekleme konusunda bir güvenlik açığının mevcut olabileceğinin bir işaretidir.
Bu güvenlik açıkları, her biri kendi algılama yöntemini gerektiren iki farklı bağlamda ortaya çıkar. Bulanıklaştırma girişimlerinizin sonuçları ne olursa olsun, aşağıdaki bağlama özgü yaklaşımları da denemek önemlidir. Fuzzing sonuçsuz kaldıysa, bu yaklaşımlardan birini kullanarak bir güvenlik açığı yine de kendini ortaya çıkarabilir. Fuzzing bir şablon enjeksiyon güvenlik açığını önermiş olsa bile, bundan yararlanmak için yine de bağlamını tanımlamanız gerekir.
Düz metin bağlamı
Çoğu şablon dili, doğrudan HTML etiketlerini kullanarak veya HTTP yanıtı gönderilmeden önce arka uçta HTML'ye işlenecek olan şablonun yerel sözdizimini kullanarak serbestçe içerik girmenize olanak tanır. Örneğin, Freemarker'da render('Hello ' + kullanıcı adı) satırı Hello Carlos gibi bir şeye dönüştürülür.
Bu bazen XSS için kullanılabilir ve aslında çoğu zaman basit bir XSS güvenlik açığıyla karıştırılır. Ancak parametrenin değeri olarak matematiksel işlemleri ayarlayarak bunun aynı zamanda sunucu tarafı şablon enjeksiyon saldırısı için potansiyel bir giriş noktası olup olmadığını test edebiliriz.
Örneğin, aşağıdaki güvenlik açığı bulunan kodu içeren bir şablonu düşünün:
PHP:
render('Hello ' + kullanıcı adı)
Kod:
http://vulnerable-website.com/?username=${7*7}Matematiksel işlemi başarılı bir şekilde değerlendirmek için gereken spesifik sözdiziminin, hangi şablon motorunun kullanıldığına bağlı olarak değişeceğini unutmayın. Bunu tanımlama adımında daha ayrıntılı olarak ele alacağız.
Kod bağlamı
Diğer durumlarda daha önce e-posta örneğimizde gördüğümüz gibi, kullanıcı girişinin bir şablon ifadesine yerleştirilmesiyle güvenlik açığı ortaya çıkar. Bu, kullanıcı tarafından kontrol edilebilen bir değişken adının bir parametrenin içine yerleştirilmesi şeklinde olabilir, örneğin:
Kod:
greeting = getQueryParameter('greeting')[/COLOR][/SIZE][/CENTER][/COLOR][/SIZE][/CENTER]
[SIZE=4][COLOR=rgb(255, 255, 255)][CENTER][SIZE=4][COLOR=rgb(255, 255, 255)][CENTER]engine.render("Hello {{"+greeting+"}}", data)Web sitesinde ortaya çıkan URL şuna benzer:
Bu, Hello Carlos'un çıktısında gösterilecektir.
Bu bağlam, değerlendirme sırasında kolaylıkla gözden kaçırılabilir çünkü bariz bir XSS ile sonuçlanmaz ve basit bir hashmap aramasından neredeyse ayırt edilemez. Bu bağlamda sunucu tarafı şablon eklemeyi test etmenin bir yöntemi, öncelikle değere rastgele HTML enjekte ederek parametrenin doğrudan bir XSS güvenlik açığı içermediğini tespit etmektir:
Kod:
http://vulnerable-website.com/?greeting=data.usernameBu, Hello Carlos'un çıktısında gösterilecektir.
Bu bağlam, değerlendirme sırasında kolaylıkla gözden kaçırılabilir çünkü bariz bir XSS ile sonuçlanmaz ve basit bir hashmap aramasından neredeyse ayırt edilemez. Bu bağlamda sunucu tarafı şablon eklemeyi test etmenin bir yöntemi, öncelikle değere rastgele HTML enjekte ederek parametrenin doğrudan bir XSS güvenlik açığı içermediğini tespit etmektir:
Kod:
http://vulnerable-website.com/?greeting=data.username<tag>[/COLOR][/SIZE][/CENTER][/COLOR][/SIZE][/CENTER]
[SIZE=4][COLOR=rgb(255, 255, 255)][CENTER][SIZE=4][COLOR=rgb(255, 255, 255)][CENTER]XSS'nin yokluğunda, bu genellikle çıktıda boş bir girişe (kullanıcı adı olmadan yalnızca Hello), kodlanmış etiketlere veya bir hata mesajına neden olur. Bir sonraki adım, ortak şablon oluşturma sözdizimini kullanarak ifadeyi kırmaya çalışmak ve bundan sonra isteğe bağlı HTML eklemeye çalışmaktır:
Bu yine bir hatayla veya boş çıktıyla sonuçlanırsa, ya yanlış şablonlama dilinden sözdizimi kullanmışsınızdır ya da hiçbir şablon stili sözdizimi geçerli görünmüyorsa, sunucu tarafı şablon enjeksiyonu mümkün değildir. Alternatif olarak, çıktının rastgele HTML ile birlikte doğru şekilde oluşturulması, sunucu tarafı şablon ekleme güvenlik açığının mevcut olduğunun önemli bir göstergesidir:
Tanımlama
Şablon enjeksiyon potansiyelini tespit ettikten sonraki adım şablon motorunu tanımlamaktır.
Çok sayıda şablon oluşturma dili olmasına rağmen bunların çoğu, HTML karakterleriyle çakışmayacak şekilde özel olarak seçilmiş çok benzer sözdizimini kullanır. Sonuç olarak, hangi şablon motorunun kullanıldığını test etmek için araştırma yükleri oluşturmak nispeten basit olabilir.
Geçersiz sözdizimi göndermek genellikle yeterlidir, çünkü ortaya çıkan hata mesajı size şablon motorunun tam olarak ne olduğunu ve hatta bazen hangi versiyon olduğunu söyleyecektir. Örneğin, geçersiz <%=foobar%> ifadesi Ruby tabanlı ERB motorundan aşağıdaki yanıtı tetikler:
Aksi takdirde, farklı dile özgü veri yüklerini manuel olarak test etmeniz ve bunların şablon motoru tarafından nasıl yorumlanacağını incelemeniz gerekecektir. Hangi sözdiziminin geçerli veya geçersiz göründüğüne dayalı bir eleme işlemi kullanarak seçenekleri düşündüğünüzden daha hızlı daraltabilirsiniz. Bunu yapmanın yaygın bir yolu, farklı şablon motorlarından gelen sözdizimini kullanarak rastgele matematiksel işlemleri enjekte etmektir. Daha sonra başarıyla değerlendirilip değerlendirilmediklerini gözlemleyebilirsiniz. Bu sürece yardımcı olmak için aşağıdakine benzer bir karar ağacı kullanabilirsiniz:
Aynı veri yükünün bazen birden fazla şablon dilinde başarılı bir yanıt verebileceğini bilmelisiniz. Örneğin, {{7*'7'}} veri yükü Twig'de 49'u ve Jinja2'de 7777777'yi döndürür. Bu nedenle tek bir başarılı yanıta dayanarak hemen sonuca varmamak önemlidir.
Sömürmek
Potansiyel bir güvenlik açığının mevcut olduğunu tespit ettikten ve şablon motorunu başarılı bir şekilde tanımladıktan sonra, bundan yararlanmanın yollarını bulmaya başlayabilirsiniz.
Sunucu tarafı şablon ekleme güvenlik açıkları nasıl önlenir
Sunucu tarafı şablon enjeksiyonunu önlemenin en iyi yolu, hiçbir kullanıcının yeni şablonları değiştirmesine veya göndermesine izin vermemektir. Ancak bazen iş gereksinimleri nedeniyle bu kaçınılmaz olabilir.
Sunucu tarafı şablon yerleştirme güvenlik açıklarından kaçınmanın en basit yollarından biri, kesinlikle gerekli olmadıkça her zaman Bıyık gibi "mantıksız" bir şablon motoru kullanmaktır. Mantığı sunumdan mümkün olduğunca ayırmak, en tehlikeli şablon tabanlı saldırılara maruz kalma riskinizi büyük ölçüde azaltabilir.
Diğer bir önlem ise kullanıcıların kodunu yalnızca potansiyel olarak tehlikeli modüllerin ve işlevlerin tamamen kaldırıldığı korumalı alan ortamında çalıştırmaktır. Ne yazık ki, güvenilmeyen kodun sandbox'a alınması doğası gereği zordur ve bypass edilmeye açıktır.
Son olarak, başka bir tamamlayıcı yaklaşım, rastgele kod çalıştırmanın neredeyse kaçınılmaz olduğunu kabul etmek ve örneğin şablon ortamınızı kilitli bir Docker konteynerine dağıtarak kendi sanal alanınızı uygulamaktır.
Kaynak: Server-side template injection | Web Security Academy
Kod:
http://vulnerable-website.com/?greeting=data.username}}<tag>Bu yine bir hatayla veya boş çıktıyla sonuçlanırsa, ya yanlış şablonlama dilinden sözdizimi kullanmışsınızdır ya da hiçbir şablon stili sözdizimi geçerli görünmüyorsa, sunucu tarafı şablon enjeksiyonu mümkün değildir. Alternatif olarak, çıktının rastgele HTML ile birlikte doğru şekilde oluşturulması, sunucu tarafı şablon ekleme güvenlik açığının mevcut olduğunun önemli bir göstergesidir:
Kod:
Hello Carlos<tag>Tanımlama
Şablon enjeksiyon potansiyelini tespit ettikten sonraki adım şablon motorunu tanımlamaktır.
Çok sayıda şablon oluşturma dili olmasına rağmen bunların çoğu, HTML karakterleriyle çakışmayacak şekilde özel olarak seçilmiş çok benzer sözdizimini kullanır. Sonuç olarak, hangi şablon motorunun kullanıldığını test etmek için araştırma yükleri oluşturmak nispeten basit olabilir.
Geçersiz sözdizimi göndermek genellikle yeterlidir, çünkü ortaya çıkan hata mesajı size şablon motorunun tam olarak ne olduğunu ve hatta bazen hangi versiyon olduğunu söyleyecektir. Örneğin, geçersiz <%=foobar%> ifadesi Ruby tabanlı ERB motorundan aşağıdaki yanıtı tetikler:
Ruby:
(erb):1:in `<main>': undefined local variable or method `foobar' for main:Object (NameError)
from /usr/lib/ruby/2.5.0/erb.rb:876:in `eval'
from /usr/lib/ruby/2.5.0/erb.rb:876:in `result'
from -e:4:in `<main>'Aksi takdirde, farklı dile özgü veri yüklerini manuel olarak test etmeniz ve bunların şablon motoru tarafından nasıl yorumlanacağını incelemeniz gerekecektir. Hangi sözdiziminin geçerli veya geçersiz göründüğüne dayalı bir eleme işlemi kullanarak seçenekleri düşündüğünüzden daha hızlı daraltabilirsiniz. Bunu yapmanın yaygın bir yolu, farklı şablon motorlarından gelen sözdizimini kullanarak rastgele matematiksel işlemleri enjekte etmektir. Daha sonra başarıyla değerlendirilip değerlendirilmediklerini gözlemleyebilirsiniz. Bu sürece yardımcı olmak için aşağıdakine benzer bir karar ağacı kullanabilirsiniz:
Aynı veri yükünün bazen birden fazla şablon dilinde başarılı bir yanıt verebileceğini bilmelisiniz. Örneğin, {{7*'7'}} veri yükü Twig'de 49'u ve Jinja2'de 7777777'yi döndürür. Bu nedenle tek bir başarılı yanıta dayanarak hemen sonuca varmamak önemlidir.
Sömürmek
Potansiyel bir güvenlik açığının mevcut olduğunu tespit ettikten ve şablon motorunu başarılı bir şekilde tanımladıktan sonra, bundan yararlanmanın yollarını bulmaya başlayabilirsiniz.
Sunucu tarafı şablon ekleme güvenlik açıkları nasıl önlenir
Sunucu tarafı şablon enjeksiyonunu önlemenin en iyi yolu, hiçbir kullanıcının yeni şablonları değiştirmesine veya göndermesine izin vermemektir. Ancak bazen iş gereksinimleri nedeniyle bu kaçınılmaz olabilir.
Sunucu tarafı şablon yerleştirme güvenlik açıklarından kaçınmanın en basit yollarından biri, kesinlikle gerekli olmadıkça her zaman Bıyık gibi "mantıksız" bir şablon motoru kullanmaktır. Mantığı sunumdan mümkün olduğunca ayırmak, en tehlikeli şablon tabanlı saldırılara maruz kalma riskinizi büyük ölçüde azaltabilir.
Diğer bir önlem ise kullanıcıların kodunu yalnızca potansiyel olarak tehlikeli modüllerin ve işlevlerin tamamen kaldırıldığı korumalı alan ortamında çalıştırmaktır. Ne yazık ki, güvenilmeyen kodun sandbox'a alınması doğası gereği zordur ve bypass edilmeye açıktır.
Son olarak, başka bir tamamlayıcı yaklaşım, rastgele kod çalıştırmanın neredeyse kaçınılmaz olduğunu kabul etmek ve örneğin şablon ortamınızı kilitli bir Docker konteynerine dağıtarak kendi sanal alanınızı uygulamaktır.
Çevirmen: @Dolyetyus
Moderatör tarafında düzenlendi:
eter
