Server Side Template Injection Nedir?
Çoğu web uygulaması sahibi, e-postaların veya web sayfalarının HTML bölümlerine dinamik ve zengin verilerin sorunsuz bir şekilde yerleştirilmesi için Twig, Mustache ve FreeMarker benzeri şablon motorlarını kullanmayı tercih eder. Kullanıcı girişi şablona güvenli olmayan bir şekilde veya kötü niyetli öğelerin varlığı ile tanıtıldığında, bir SSTI saldırısı gerçekleşir.
SSTI, kötü niyetli öğelerin sunucu tarafında kullanılan yerleşik şablonlar aracılığıyla ünlü şablon motorlarına eklenmesidir. Burada, aktörün bu eyleminin temel amacı, sunucu tarafı operasyonlarını ele geçirmektir.
SSTI sürecini anlamanın kolay yolu, onu gerçek dünyadan örneklerle açıklamaktır. Şimdi senaryoyu düşünün; Müşteri e-postalarını oluşturmak için bir pazarlama uygulaması kullanıyorsunuz ve e-posta alıcılarına adlarıyla hitap etmek için Twig şablon sistemini kullanıyorsunuz.
Alıcılara herhangi bir değişiklik yeteneği verilmeden şablona ad eklenirse, işler sorunsuz olacaktır. E-postaların alıcı tarafından özelleştirilmesine izin verilir verilmez, gönderen şablon içeriği üzerindeki hakimiyetini kaybetmeye başlar.
Tehdit aktörleri, kullanıcı sonu özelleştirme olanağını bir fırsat olarak kullanabilir ve özelleştirmede kullanılan şablon oluşturma motorunu bularak ve özellikli yükü tercihlerine göre değiştirerek bir SSTI saldırısı gerçekleştirebilir.
SSTI saldırıları her zaman planlanmaz; bazen, kullanıcı tarafı girdisi şablonla doğrudan sözleşme yaptığında bilmeden gerçekleşir. Bu durum, tehdit aktörlerinin şablon motoru bozan komutlar vermeleri ve sunucuları istedikleri gibi çalıştırmaları için bir fırsat yaratır. Her durumda, bir SSTI saldırısının sonuçları çoğunlukla yıkıcıdır.
Sunucu Tarafı Şablonları Nasıl Çalışır?
Geliştiriciler, sunucuya yönlendirilen özelleştirilmiş son kullanıcı verilerini içeren önceden doldurulmuş bir web sayfası oluşturmak için genellikle bu şablonları kullanır. Bu şablonların kullanımı, sunucu tarafı istek işleme sırasında tarayıcıdan sunucuya gidip gelmeyi azaltır.
Sunucu tarafı şablonlar, önceden katıştırılmış kullanıcı girdilerine büyük esneklik ve kısayollar sunduğundan, genellikle XXS veya siteler arası komut dosyası oluşturma ile karıştırılır .
Şablon oluşturma motorları, web çerçeveleri için dinamik HTML oluşturmak için en çok tercih edilen kaynaklardır. Yapısal düzeyde, bir şablon, amaçlanan HTML kullanıcı çıktısının statik bölümünü ve dinamik içerik ekleme sürecini açıklayan belirli kuralları içerir.
En iyi uygulamaları benimsemelerine rağmen, şablon sistemleri iyi korunmamaktadır ve tehdit aktörlerinin veya kötü niyetli şablon oluşturucuların eline geçmeye eğilimlidir.
Kullanıcı tarafından oluşturulan şablonları sağlama veya sunma özgürlüğü veren web uygulamalarının SSTI saldırılarının hedefi olması muhtemeldir. Bir yazarın bu bağlamda bir değişken için verileri düzenlediğini varsayalım. Web uygulamasına dinamik bileşenler eklemek için şablon dosyalarını kullanmak için motoru tetikler.
Ayrıca, bir HTTP isteği gerçekleşir gerçekleşmez motor otomatik olarak HTML çıktı yanıtları oluşturmaya başlar.
Kontrol etmek için bir HTTP POST isteği kullanabilirsiniz:
Örneğin:
İşte bu güvenlik açığını test etmenin birkaç yolu. Burada bu amaçla farklı parametre değerleri kullanacağız.
=${7*3}
=<%= 7*3 %>
={{7*3}}
Ardından, hata ayıklama çıktısını okuyun (örneğin, Django için). Farklı şablon motorlarının bunu yapmak için biraz farklı yolları olacaktır.
Bu istek size hata ayıklama için kullanılabilecek okunabilir nesnelerin bir listesini getirecektir. Buradan 'ayarlar' gibi nesnelere de erişilebilir. Bu nedenle, gizli anahtarı okumayı deneyin ve başarılı olup olamayacağınızı görün:
Sunucu Tarafı Şablon Enjeksiyonunun Etkisi
Diğer tüm siber güvenlik açıkları gibi, SSTI da hedefi bozar. Örneğin, tanıtımı web sitesini birden fazla saldırıya açık hale getirir.
Etkilenen şablon motoru türü ve bir uygulamanın bunu kullanma şekli, SSTI saldırısının sonucunu belirleyen iki unsurdur.
Çoğunlukla, sonuç hedef için oldukça yıkıcıdır, örneğin:
Tüm bu eylemler kişinin hayal gücünün ötesinde hasara neden olabilir. Çok nadir durumlarda, SSTI daha az rahatsız edici olmaya devam eder.
SSTI Nasıl Tespit Edilir?
SSTI'nin yukarıda belirtilen sonuçları, geliştiricilerin ve savunucuların öngörülü olmaları ve enjeksiyonu erken aşamada tanımlamaları için bir işarettir. Bununla birlikte, SSTI'lerin anlaşılması karmaşık olduğu, XSS saldırılarına çok benzediği ve genellikle görünmez kaldığı için bu göründüğü kadar kolay değildir. Bu nedenle, SSTI'nin daha erken ve kesin tespiti için ekstra çaba sarf etmek gerekir.
Diğer saldırılarda olduğu gibi, ilk tespit adımı onun varlığını bulmaktır. Bunun gerçekleşmesi için en uygun yol, genel olarak kullanılan ifadeleri özel karakter dizileriyle tanıştırarak şablonu bulanıklaştırmaktır.
Test cihazı karakter dizisini yürütemiyorsa, bu SSTI'nin varlığını gösterir.
Ek olarak, .stm, .shtml ve .shtm gibi uzantılara sahip web sayfalarının varlığına bakılabilir. Bu uzantılara sahip sayfaları olan web sitelerinin SSTI saldırısından etkilenmesi muhtemeldir.
Ancak, bu yaklaşımların tümü %100 kesin SSTI algılaması yapmak için yeterli değildir, çünkü varlığı için 2 bağlam vardır: düz metin ve kod metni.
Her iki bağlamda da SSTI'yi algılamak için en yaygın yaklaşımların ayrıntılı bir açıklaması aşağıda verilmiştir:
Bu algılama yönteminde, güvenlik açığının varlığını kontrol etmek için XSS girdisi benzeri düz metin kullanılır. Bunun SSTI için uygun bir durum olup olmadığını doğrulamak için parametrenizde matematiksel ifadeler de kullanabilirsiniz.
Bir siteyi kontrol etmek için http://example.com/?username=${7*7} URL'si SSTI tespitinde yardımcı olabilir. Burada, 'example.com'u sitenin adıyla değiştirmeniz gerekir. URL arama sonucu herhangi bir matematiksel değer içeriyorsa, SSTI güvenlik açığının varlığını gösterir.
Sunucuda mevcut olan hata veya boş yanıtları sağlayabilecek bir yük oluşturmakla ilgilidir. Ayrıca XSS zafiyeti için sıfır olasılık sağlanarak da yapılabilir. Bunu yapmak için değere isteğe bağlı HTML eklemeyi deneyebilirsiniz.
XSS olmadığında, bu SSTI algılama yönteminde bir yük oluşturan ilk yaklaşım kullanılmalıdır.
SSTI Nasıl Belirlenir?
SSTI enjeksiyonunun başarılı bir şekilde saptanması üzerine, etkilenen şablon motorunun tanınmasına vurgu yapılmalıdır.
Çeşitli şablonlama dilleri vardır, ancak çoğu benzer sözdizimi kullanır. Bu sözdizimleri, kullanılmış HTML öğeleriyle çelişmeyecek şekilde oluşturulur. Bu, etkilenen şablon motoru testi için araştırma yükü oluşturmayı kolay bir görev haline getirir.
Geçersiz sözdizimi göndermek de SSTI güvenliğinin ihlal edildiğini belirlemenin uygun bir yoludur. Gönderiminiz, önemli ayrıntıları vermek için sunucu tarafı sistemlerden gelen hata mesajlarını zorunlu kılacaktır.
Çoğu durumda, bu işe yarar. Alternatif yollar arayan test uzmanları, sayısız yükü manuel olarak test etmeli ve şablon oluşturucu motorları aracılığıyla müdahale prosedürlerini analiz etmelidir. Seçeneklerinizi daraltmak için işlem sırasında denemelerinize göre sözdizimi kalıplarını ortadan kaldırmayı deneyebilirsiniz.
Ayrıca, çeşitli şablon motorları tarafından takip edilen sözdizimine göre rastgele aritmetik işlemler enjekte etmek çok yaygın bir yaklaşımdır.
Doğru tanımlama için yukarıda belirtilen mantık ağacı izlenebilir. Kesin SSTI tanımlamasını hedeflerken, benzer yüklerin Twig veya Jinja2 gibi birden çok dilde etkili yanıtlar verebileceğini unutmayın. Bu nedenle, testçiler, önemli bir sonuca ulaşmak için her zaman birden fazla başarılı yanıt biriktirmelidir.
Sunucu Tarafı Şablon Enjeksiyon Saldırısını Önleme
Bir SSTI saldırısının sonucunu kavradıktan sonra, onu göz ardı etmek ve önleyici yolları öğrenmemek akıllıca değildir. Bir şablon motorunun kullanımını ortadan kaldırmak, kod akışında herhangi bir kesintiye neden olmazken birden fazla cephede modifikasyonu desteklediğinden dikkate değer bir alternatif değildir.
Bu nedenle, geliştiriciler ve güvenlik uzmanları, uygulamaları ve web sitelerini SSTI'nin erişiminden uzak tutmanın başka yollarını aramalıdır. İşte zorlamak için uzman onaylı bazı SSTI önleme stratejileri.
Her durumda, şablonlar, geliştiriciler ve yöneticiler dışında hiç kimse tarafından değiştirilemez ve değiştirilemez. Herkese açık şablonlar, bilgisayar korsanları için kolay hedeflerdir. Bu nedenle, şablonlarda erişim kurallarını uygulamak ve erişilebilirliklerini sınırlı tutmak akıllıca olacaktır. Ancak bu her zaman ulaşılabilir bir hedef değildir.
Sanitizasyon, SSTI saldırılarının olasılıklarını alt tarafta tutmak için başka bir uygulanabilir tekniktir. Amaçlanan tüm içeriğin önceden tahrip edici unsurların varlığı için çapraz kontrol edilmesi anlamına gelir. En önemlisi, bu ön inceleme, kullanıcı tarafından iletilen veriler üzerinde gerçekleştirilmelidir. Normal ifade kullanarak ve doğrulanmış ifadelerin bir listesini oluşturarak bunu gerçekleştirebilirsiniz. Bu çözümün %100 koruma sağlamadığını unutmayın.
SSTI'den daha iyi koruma için sandboxing, sanitizasyondan daha iyi bir seçenektir. Kullanıcı için güvenli ve yakın bir ekosistem oluşturmayı içeren önleyici bir yaklaşımdır. Yakın çevre, tehlikeli özelliklerden ve modüllerden arındırılırken, herhangi bir güvenlik açığı tespit edildiğinde diğer verilere kısıtlı erişim. Etkinliği övgüye değer olsa da, uygulanması zor bir iştir. Ayrıca, gözden kaçırma veya yanlış yapılandırma kullanarak bunu atlamak kolaydır.
SSTI saldırılarını önlemek için mantıksız şablonlar kullanabilirsiniz. Mantıksız motor şablonları, kod yorumlamayı ve görsel işlemeyi ayırmak için kullanılan şablonlardır. Bıyık, mantıksız bir şablonun yaygın bir örneğidir. Mantıksız bir şablon mil kontrol akış ifadeleri kullandığından, her tür kontrol varsayılan olarak veriye dayalıdır ve uygulama mantığı entegrasyonunu mümkün kılar. Bu, uzaktan kod yürütme olasılığını azaltır.
Yukarıdaki çözümlerden hiçbiri işe yaramazsa, savunucular uzaktan kod yürütmenin kaçınılmaz olduğunu kabul etmeli ve şablon motorunu tamamen kilitli bir Docker kapsayıcısında yürüterek özelleştirilmiş korumalı alan uygulayarak etkisini azaltmaya çalışmalıdır.
0 Comments