Server Side Inclusion/Edge Side Inclusion Injection
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
(Giriş Apache belgelerinden alınmıştır)
SSI (Server Side Includes), HTML sayfalarına yerleştirilen ve sayfalar sunulurken sunucuda değerlendirilen direktiflerdir. Mevcut bir HTML sayfasına dinamik olarak üretilen içerik eklemenizi sağlar, tüm sayfayı bir CGI programı veya diğer dinamik teknoloji aracılığıyla sunmak zorunda kalmadan. Örneğin, mevcut bir HTML sayfasına şu şekilde bir direktif yerleştirebilirsiniz:
<!--#echo var="DATE_LOCAL" -->
Ve sayfa sunulduğunda, bu parça değerlendirilecek ve değeri ile değiştirilecektir:
Salı, 15-Oca-2013 19:28:54 EST
SSI kullanma kararı, sayfanızın ne kadarının statik olduğu ve sayfa her sunulduğunda ne kadarının yeniden hesaplanması gerektiği ile genellikle ilgilidir. SSI, yukarıda gösterilen mevcut zamanı gibi küçük bilgi parçaları eklemek için harika bir yoldur. Ancak sayfanızın çoğunluğu sunulduğu anda üretiliyorsa, başka bir çözüm aramanız gerekir.
Web uygulaması .shtml
, .shtm
veya .stm
uzantılı dosyalar kullanıyorsa SSI'nin varlığını çıkarabilirsiniz, ancak bu sadece bir durum değildir.
Tipik bir SSI ifadesinin aşağıdaki formatı vardır:
Dinamik uygulamaların veya bilgilerin önbelleğe alınması ile ilgili bir sorun vardır, çünkü içeriğin bir sonraki kez alındığında değişmiş olabileceği durumlar vardır. Bu, ESI'nin kullanılma amacıdır; ESI etiketlerini kullanarak önbellek versiyonundan önce oluşturulması gereken dinamik içeriği belirtmek için. Eğer bir saldırgan önbellek içeriğine bir ESI etiketi enjekte edebilirse, o zaman, kullanıcılar için gönderilmeden önce belgede rastgele içerik enjekte edebilir.
Sunucudan gelen bir yanıttaki aşağıdaki header, sunucunun ESI kullandığını gösterir:
Eğer bu başlığı bulamazsanız, sunucu her neyse ESI kullanıyor olabilir. Kör istismar yaklaşımı da kullanılabilir çünkü bir isteğin saldırganın sunucusuna ulaşması gerekir:
GoSecure oluşturdu farklı ESI uyumlu yazılımlar üzerinde deneyebileceğimiz olası saldırıları anlamak için bir tablo:
Includes: <esi:includes>
direktifini destekler
Vars: <esi:vars>
direktifini destekler. XSS Filtrelerini atlatmak için kullanışlıdır
Cookie: Belge çerezleri ESI motoruna erişilebilir
Upstream Headers Required: Surrogate uygulamaları, upstream uygulama başlıkları sağlamadıkça ESI ifadelerini işleme almaz
Host Allowlist: Bu durumda, ESI dahil etmeleri yalnızca izin verilen sunucu ana bilgisayarlarından mümkündür, bu da örneğin SSRF'yi yalnızca bu ana bilgisayarlara karşı mümkün kılar
Aşağıdaki ESI direktifi, sunucunun yanıtı içinde rastgele bir dosya yükleyecektir.
Uzaktan çerez çalma
HTTP_ONLY çerezini XSS ile yanıt içinde yansıtarak çalın:
Bunu "Yerel Dosya Dahil Etme" ile karıştırmayın:
Aşağıdaki, yanıta bir Location
başlığı ekleyecektir.
Zorunlu istekte başlık ekle
Yanıtın başlığına ekleyin (XSS içeren bir yanıtta "Content-Type: text/json" atlatmak için faydalıdır)
Bu, yanıtta yer alan hata ayıklama bilgilerini gönderecektir:
dca parametresi için xslt
değerini belirleyerek, eXtensible Stylesheet Language Transformations (XSLT)
tabanlı ESI'yi dahil etmek mümkündür. Dahil etme, HTTP surrogate'ının XML ve XSLT dosyalarını almasına neden olur; bu da birincisini filtreler. Bu tür XML dosyaları, saldırganların SSRF saldırıları gerçekleştirmesine olanak tanıyan XML External Entity (XXE) saldırıları için kullanılabilir. Ancak, bu yaklaşımın faydası sınırlıdır çünkü ESI zaten bir SSRF vektörü olarak hizmet eder. Temel Xalan kütüphanesinde destek olmaması nedeniyle, harici DTD'ler işlenmez ve yerel dosya çıkarımı engellenir.
XSLT dosyası:
Check the XSLT page:
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)