* **Şirketinizi HackTricks'te reklamınızı görmek** veya **HackTricks'i PDF olarak indirmek** için [**ABONELİK PLANLARINI**](https://github.com/sponsors/carlospolop) kontrol edin!
* [**The PEASS Ailesi'ni**](https://opensea.io/collection/the-peass-family) keşfedin, özel [**NFT'lerimiz**](https://opensea.io/collection/the-peass-family) koleksiyonumuz
* 💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) **katılın** veya **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**'u takip edin**.
SSI (Sunucu Tarafı Dahil Etme), HTML sayfalarına yerleştirilen ve sayfalar sunulurken sunucuda değerlendirilen yönergelerdir. Bunlar, **tüm sayfayı bir CGI programı veya diğer dinamik teknoloji aracılığıyla sunmadan mevcut bir HTML sayfasına dinamik olarak oluşturulmuş içerik eklemenizi sağlar**.\
Örneğin, aşağıdaki gibi mevcut bir HTML sayfasına bir yönerge yerleştirebilirsiniz:
SSI'nin ne zaman kullanılacağı ve ne zaman sayfanızın tamamen bir program tarafından oluşturulması gerektiği genellikle sayfanın ne kadarının statik olduğuna ve sayfanın her sunulduğunda ne kadarının yeniden hesaplanması gerektiğine bağlıdır. SSI, yukarıda gösterildiği gibi mevcut zaman gibi küçük bilgileri eklemek için harika bir yoldur. Ancak sayfanızın çoğunluğu sunulduğunda oluşturuluyorsa, başka bir çözüm aramanız gerekmektedir.
Web uygulamasının \*\* `.shtml`, `.shtm` veya `.stm` uzantılı dosyaları kullanması durumunda SSI'nin varlığını çıkarabilirsiniz, ancak bu sadece bir durum değildir.
Server-side inclusion (SSI) ve edge-side inclusion (ESI) enjeksiyonu, web uygulamalarında yaygın olarak bulunan bir güvenlik açığıdır. Bu tür enjeksiyonlar, saldırganın hedef uygulamada kodu çalıştırmasına ve istemciye yanıt olarak dinamik içerik oluşturmasına olanak tanır.
SSI enjeksiyonu, sunucu tarafında gerçekleşir ve genellikle sunucu tarafı betiklerinin (örneğin PHP, ASP, JSP) kullanıldığı web uygulamalarında bulunur. Saldırgan, kullanıcı girişi veya diğer kullanıcı tarafından sağlanan verileri kullanarak SSI komutlarını enjekte eder. Bu komutlar sunucu tarafında çalıştırılır ve sonucu istemciye gönderilir.
ESI enjeksiyonu ise, içerik dağıtım ağı (CDN) veya ters proxy gibi ara sunucuların kullanıldığı web uygulamalarında ortaya çıkar. Saldırgan, ESI etiketlerini kullanarak istemciye gönderilen içeriği manipüle eder. Bu etiketler, dinamik içeriği yerleştirmek veya diğer sunuculara istek göndermek için kullanılır.
Bu tür enjeksiyonlar, saldırganın yetkisiz olarak uygulama sunucusunda kod çalıştırmasına ve hassas verilere erişmesine olanak tanır. Bu nedenle, SSI ve ESI enjeksiyonlarının önlenmesi ve tespit edilmesi önemlidir.
SSI ve ESI enjeksiyonlarını önlemek için aşağıdaki adımları izleyebilirsiniz:
- Kullanıcı girişi veya diğer kullanıcı tarafından sağlanan verileri güvenli bir şekilde işleyin. Bu verileri doğrulayın ve gerektiğinde filtreleyin.
- Sunucu tarafında çalışan betiklerde SSI veya ESI komutlarını kullanmaktan kaçının.
- Web uygulamanızı güncel tutun ve güvenlik yamalarını düzenli olarak uygulayın.
- Web uygulamanızı güvenlik testlerine tabi tutun ve düzenli olarak güvenlik açıklarını taramak için otomatik araçlar kullanın.
SSI ve ESI enjeksiyonları, web uygulamalarında yaygın olarak bulunan güvenlik açıklarıdır. Bu tür enjeksiyonları önlemek ve tespit etmek için güvenlik önlemleri almak önemlidir.
Bir sorun vardır: **bilgi önbelleğe alınırken veya dinamik uygulamaların** bir parçası olarak içeriğin bir sonraki alındığında **değişebilir** olması. İşte ESI'nin kullanıldığı yer burasıdır, ESI etiketlerini kullanarak **önbellek sürümü gönderilmeden önce oluşturulması gereken dinamik içeriği** belirtmek için kullanılır.\
Eğer bir **saldırgan**, önbellek içeriğine bir ESI etiketi **enjekte edebilirse**, o zaman kullanıcılara gönderilmeden önce belgeye **keyfi içerik enjekte edebilir**.
[GoSecure](https://www.gosecure.net/blog/2018/04/03/beyond-xss-edge-side-include-injection/) farklı ESI yetenekli yazılımlara karşı deneyebileceğimiz olası saldırıları anlamak için bir tablo oluşturdu, bu tablo şu şekildedir:
* **Vars**: `<esi:vars>` direktifini destekler. XSS Filtrelerini atlamak için kullanışlıdır
* **Cookie**: Belge çerezleri ESI motoruna erişilebilir
* **Upstream Headers Gerekli**: Surrogate uygulamaları, yukarı akış uygulaması başlıkları sağlanmadığı sürece ESI ifadelerini işlemeyecektir
* **Host Beyaz Listesi**: Bu durumda, ESI dahil etmeleri yalnızca izin verilen sunucu ana bilgisayarlarından mümkün olur, bu da örneğin SSRF'nin yalnızca bu ana bilgisayarlara karşı mümkün olmasını sağlar
Client-side Cross-Site Scripting (XSS) korumasını atlatmak için çeşitli yöntemler vardır. Bu yöntemler, saldırganın XSS saldırısını hedef uygulamaya enjekte etmesine ve korumaları aşmasına olanak tanır. İşte bazı yaygın yöntemler:
- **HTML entites bypasse**: İstemci tarafında XSS korumasını atlatmanın basit bir yolu, HTML özel karakterlerini HTML kodlarına dönüştürmek için kullanılan HTML entity kodlarını kullanmaktır. Bu, saldırganın XSS payloadunu korumaları aşarak enjekte etmesine olanak tanır.
- **JavaScript obfuscation**: JavaScript kodunu karmaşıklaştırarak veya şifreleyerek XSS korumasını atlatmak mümkündür. Bu, saldırganın XSS payloadunu gizlemesine ve korumaları aşmasına yardımcı olur.
- **DOM-based bypass**: DOM tabanlı XSS korumasını atlatmak için, saldırganın hedef uygulamanın DOM yapısını manipüle etmesi gerekebilir. Bu, saldırganın XSS payloadunu doğrudan DOM'a enjekte etmesine ve korumaları aşmasına olanak tanır.
Bu yöntemler, saldırganın istemci tarafında XSS korumasını atlatmasına yardımcı olabilir. Ancak, bu tür saldırıları önlemek için güvenlik önlemleri almak önemlidir. Uygulama geliştiricileri, güvenli kodlama tekniklerini kullanarak XSS saldırılarına karşı koruma sağlamalıdır.
CRLF (Carriage Return Line Feed) injection, also known as HTTP response splitting, is a web vulnerability that allows an attacker to inject malicious headers or control the response sent by the server. This can lead to various attacks, such as cross-site scripting (XSS), session hijacking, cache poisoning, and more.
The vulnerability occurs when user input is not properly validated or sanitized before being included in the response headers. An attacker can exploit this by injecting CRLF characters (%0D%0A) into the input, causing the server to interpret them as separate headers or new lines.
To exploit this vulnerability, an attacker can craft a malicious request that includes CRLF characters in the user input. For example, by injecting a CRLF character after the user's input, the attacker can add a new header or modify an existing one. This can be used to perform various attacks, such as injecting malicious JavaScript code in an XSS attack or manipulating the server's response to bypass security controls.
To prevent CRLF injection attacks, it is important to properly validate and sanitize user input before including it in the response headers. This can be done by using input validation techniques, such as whitelisting or blacklisting, and encoding user input to prevent the interpretation of special characters.
Overall, CRLF injection is a serious web vulnerability that can have severe consequences if not properly mitigated. It is important for developers and security professionals to be aware of this vulnerability and implement proper security measures to protect against it.
Bu zafiyet, bir web uygulamasının başlık ekleme işlevinde CRLF (Satır Sonu ve Satır Başı) enjeksiyonuna izin verdiği durumlarda ortaya çıkar. Bu, saldırganın HTTP yanıt başlıklarını manipüle ederek çeşitli saldırılar gerçekleştirmesine olanak tanır.
##### Saldırı Senaryoları
1.**HTTP Response Splitting (HTTP Yanıtı Bölme):** Saldırgan, CRLF karakterlerini kullanarak yanıt başlıklarını bölerek, yanıtın içeriğini değiştirebilir veya yanıtı tamamen bozabilir. Bu, saldırganın kullanıcıları yanıltmasına ve kötü amaçlı içerik sunmasına olanak tanır.
2.**Session Hijacking (Oturum Kaçırma):** Saldırgan, CRLF enjeksiyonunu kullanarak oturum kimlik bilgilerini çalabilir ve hedef kullanıcının oturumunu ele geçirebilir. Bu, saldırganın hedef kullanıcının hesabına erişim sağlamasına ve yetkisiz işlemler gerçekleştirmesine olanak tanır.
Bu saldırıda, saldırgan, kullanıcının tarayıcısına yanıt başlıklarını manipüle ederek kötü amaçlı bir web sitesine yönlendirir ve aynı zamanda kullanıcının oturum kimlik bilgilerini çalar.
2.**Session Hijacking Saldırısı:** Saldırgan, CRLF enjeksiyonunu kullanarak oturum kimlik bilgilerini çalar ve hedef kullanıcının oturumunu ele geçirir. Örneğin:
_dca_ parametresi için `xslt` değeri belirtilerek, **`eXtensible Stylesheet Language Transformations (XSLT)`** tabanlı ESI dahil edilebilir. Bu dahil etme, HTTP yerine geçenin XML ve XSLT dosyalarını almasına neden olur ve XSLT dosyası XML dosyasını filtreler. Bu tür XML dosyaları, _XML External Entity (XXE)_ saldırıları için kullanılabilir ve saldırganlara SSRF saldırıları gerçekleştirmelerine olanak tanır. Bununla birlikte, bu yaklaşımın kullanışlılığı sınırlıdır çünkü ESI zaten bir SSRF vektörü olarak hizmet vermektedir. Altta yatan Xalan kütüphanesinde destek olmadığından, harici DTD'ler işlenmez ve yerel dosya çıkarımı engellenir.
<summary><strong>AWS hacklemeyi sıfırdan kahramanla öğrenin</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Şirketinizi HackTricks'te **reklamınızı görmek veya HackTricks'i PDF olarak indirmek** için [**ABONELİK PLANLARINI**](https://github.com/sponsors/carlospolop) kontrol edin!
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family) koleksiyonumuzu keşfedin, özel [**NFT'lerimiz**](https://opensea.io/collection/the-peass-family)
* 💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) katılın veya **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**'ı takip edin.**