# Sunucu Tarafı Dahil Etme/Kenar Tarafı Dahil Etme Enjeksiyonu
AWS hacklemeyi sıfırdan kahraman seviyesine öğreninhtARTE (HackTricks AWS Kırmızı Takım Uzmanı)!
HackTricks'ı desteklemenin diğer yolları:
* **Ş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!
* [**Resmi PEASS & HackTricks ürünlerini**](https://peass.creator-spring.com) edinin
* [**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**.
* **Hacking hilelerinizi** [**HackTricks**](https://github.com/carlospolop/hacktricks) ve [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github depolarına **PR göndererek paylaşın**.
## Sunucu Tarafı Dahil Etme Temel Bilgileri
**(Giriş [Apache belgelerinden alınmıştır](https://httpd.apache.org/docs/current/howto/ssi.html))**
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:
``
Ve sayfa sunulduğunda, bu parça değerlendirilecek ve değeriyle değiştirilecektir:
`Salı, 15-Oca-2013 19:28:54 EST`
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.
Tipik bir SSI ifadesi aşağıdaki formata sahiptir:
```
```
### Kontrol Et
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.
```javascript
// Document name
// Date
// File inclusion
// Including files (same directory)
// CGI Program results
// Including virtual files (same directory)
// Modification date of a file
// Command exec
// Command exec
// Reverse shell
// Print all variables
// Setting variables
```
## Edge Side İçerik Ekleme
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**.
### ESI Tespiti
Sunucudan gelen bir yanıtta aşağıdaki **başlık**, sunucunun ESI kullandığı anlamına gelir:
```
Surrogate-Control: content="ESI/1.0"
```
Eğer bu başlık bulunamazsa, sunucu yine de ESI kullanıyor olabilir.\
Kör bir saldırı yaklaşımı da kullanılabilir çünkü bir istek saldırganın sunucusuna ulaşmalıdır:
```javascript
// Basic detection
hello
// If previous is reflected as "hello", it's vulnerable
// Blind detection
// XSS Exploitation Example
// Cookie Stealer (bypass httpOnly flag)
// Introduce private local files (Not LFI per se)
// Valid for Akamai, sends debug information in the response
```
### ESI istismarı
[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:
* **Includes**: `` direktifini destekler
* **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
| **Yazılım** | **Includes** | **Vars** | **Cookies** | **Upstream Headers Gerekli** | **Host Beyaz Listesi** |
| :------------------------: | :----------: | :------: | :---------: | :-------------------------: | :--------------------: |
| Squid3 | Evet | Evet | Evet | Evet | Hayır |
| Varnish Cache | Evet | Hayır | Hayır | Evet | Evet |
| Fastly | Evet | Hayır | Hayır | Hayır | Evet |
| Akamai ESI Test Sunucusu | Evet | Evet | Evet | Hayır | Hayır |
| NodeJS esi | Evet | Evet | Evet | Hayır | Hayır |
| NodeJS nodesi | Evet | Hayır | Hayır | Hayır | İsteğe bağlı |
#### XSS
Aşağıdaki ESI direktifi, sunucunun yanıtının içine herhangi bir dosyayı yükler.
```xml
```
#### İstemci XSS korumasını atlatma
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.
```xml
x=>alert(/Chrome%20XSS%20filter%20bypass/);>
Use to bypass WAFs:
ipt>alert(1)ript>
error=alert(1)>
```
#### Çerez Çalma
* Uzaktan çerez çalma
```xml
```
* XSS ile HTTP\_ONLY çerez çalma işlemi, yanıtta yansıtarak gerçekleştirilir:
```bash
# This will reflect the cookies in the response
# Reflect XSS (you can put '">