XML External Entity (XXE) saldırısı, bir uygulamanın XML verisini işlerken dış kaynaklara (dosya, URL vb.) erişmesine izin vermesiyle oluşan bir güvenlik açığıdır. Bu açık sayesinde saldırgan, sistemdeki gizli dosyaları okuyabilir, sunucuya istek gönderebilir veya sistemi yavaşlatabilir.

XXE Nedir?

• XML: Verileri taşımak için kullanılan bir dosya formatı.
• Entity (varlık): XML içinde tekrar kullanılabilen veri parçaları.
• External Entity (dış varlık): XML'in dışarıdaki bir kaynağa (örneğin sunucudaki dosya veya internet üzerindeki bir URL) başvurması.

Uygulamanın Davranışını Analiz Etme

İlgili lab'da, kullanıcı arayüzünde bir butona basıldığında JavaScript ile backend'e bir istek gönderildiği görülüyor.

Önemli noktalar:

• İstek POST metodu ile gönderiliyor
• Content-Type başlığı text/xml
• Gönderilen veri ham XML

Bu üç sinyal şunu söylüyor:

"Backend, client'tan gelen XML'i doğrudan parse ediyor."

Bu noktada henüz bir açık yok. Ancak bu yapı, XXE test edilmesi gereken klasik bir senaryodur.

Neden XXE Denenebilir?

Çünkü:

• XML body tamamen kullanıcı kontrolünde
• JSON veya form-data değil
• XML schema veya validation yok
• Parser davranışı kısıtlanmamış

Bu durumda mantıklı soru şudur:

"Bu XML parse edilirken DOCTYPE ve external entity'ler kapatılmış mı?"

Cevabı ancak kontrollü bir deneme ile alabiliriz.

Kullanılan XXE Payload

XML body şu şekilde düzenlenir:

Burada olanlar:

• DOCTYPE ile xxe adında bir external entity tanımlanır
• Bu entity, sunucudaki /etc/passwd dosyasını işaret eder
• &xxe; ifadesi XML içinde kullanılarak dosya içeriği enjekte edilir

İsteğin Gönderilmesi

Bu XML, POST isteği ile ilgili endpoint'e gönderilir:

• URL: XML'i parse eden backend endpoint
• Header: Content-Type: text/xml
• Body: Yukarıdaki XML payload

Bu noktada saldırganın yaptığı şey:

"Parser'a, XML standardına uygun ama tehlikeli bir talimat vermek"

Sonuç: Açığın Kanıtı

Sunucudan dönen response içinde şu içerik görülür:

Bu çıktı şunu kesin olarak kanıtlar:

• XML parser external entity'leri işliyor
• file:// protokolü engellenmemiş
• Sunucu dosyaları kullanıcıya geri döndürülüyor

Bu, başarılı bir XXE File Disclosure istismarıdır.

API Hacking

API Nedir?

• API (Application Programming Interface): Uygulamaların birbirleriyle konuşmasını sağlayan bir "köprü"dür.
• Örneğin: Telefonundaki hava durumu uygulaması, meteoroloji servisinden veriyi API aracılığıyla alır.
• Yani API, farklı yazılımların veri alışverişi yapmasına izin veren bir arayüzdür.

🔹 API Hacking Nedir?

• API Hacking: Bir uygulamanın API'sindeki güvenlik açıklarını bulup kötüye kullanmaktır.
• Saldırgan, API'nin yanlış yapılandırılmış veya korumasız noktalarını hedef alır.
• Amaç genelde:
• Yetkisiz veri erişimi (örneğin gizli kullanıcı bilgilerini çekmek),
• Yetkisiz işlemler yapmak (örneğin admin gibi davranmak),
• Sistemi bozmak veya manipüle etmek.

1️⃣ İlk Adım: Kaynak Kodu İncelemek

Her labda olduğu gibi, rastgele payload denemek yerine önce kaynak kodu incelemek en doğru yaklaşımdır.

Login sayfasında verilen PHP koduna baktığımızda iki önemli şey fark ediyoruz:

• Kullanıcı bilgileri veritabanından değil, bir JSON dosyasından (users.json) okunuyor
• Giriş kontrolü çok basit:
• username ve password birebir eşleşirse session oluşturuluyor
• JavaScript tarafında form doğrudan submit edilmiyor, AJAX ile API çağrısı yapılıyor

Bu bize şunu söylüyor:

Uygulama klasik bir "form + backend" yapısından çok, API tabanlı çalışıyor.

Dolayısıyla saldırı yüzeyi:

• HTML formlar değil
• API endpoint'leri

2️⃣ Login Neden Önemli Ama Asıl Açık Değil?

Labda user / user bilgileri açıkça verilmiş durumda. Bu noktada login olmak zor değil ve zaten amaç da bu değil.

Login olduktan sonra şunu fark ediyoruz:

• Dashboard sayfasında:
• Resim yükleme alanı var
• "Wallpapers" başlığı var
• Ama:
• Silme (delete) butonu yok
• "All wallpapers" gibi bir liste açıkça gösterilmiyor

Burada kritik farkındalık şu:

UI'da olmayan bir işlem, backend'te olmayacak anlamına gelmez.

Bu lab, tam olarak bu varsayımı test ediyor.

3️⃣ Burp Suite ile API Trafiğini Yakalamak

UI üzerinden bir şey göremediğimiz için artık HTTP trafiğini izlememiz gerekiyor.

Burp Suite'te:

• Proxy → Intercept ON yapıyoruz
• Dashboard sayfasını yeniliyoruz

Bu sırada aşağıdaki isteği yakalıyoruz:

GET /lab/api-hacking/api-hacking1/api/all_wallpapers.php HTTP/1.1 Cookie: PHPSESSID=…

Bu istek çok önemli çünkü:

• /api/ dizini altında bir endpoint var
• Backend, duvar kağıtlarını API üzerinden getiriyor
• Session cookie kullanılıyor ama yetki kontrolü hakkında hiçbir bilgi yok

Bu noktada şunu düşünüyoruz:

"Listeleyen bir endpoint varsa, silen bir endpoint de olabilir."

4️⃣ Mantık Yürütme: API'lerde Silme İşlemi Nasıl Yapılır?

REST mantığında:

• Listeleme → GET
• Silme → DELETE

UI'da silme yok ama backend'te şu tarz bir endpoint olması çok muhtemel:

/api/delete_image.php

Bu endpoint:

• UI tarafından çağrılmıyor olabilir
• Ama dosya sisteminde mevcut olabilir
• Ve en önemlisi: yetki kontrolü yapmıyor olabilir

İşte labın kırılma noktası burası.

5️⃣ Repeater ile Yetkisiz DELETE İsteği Göndermek

Burp'ta yakaladığımız all_wallpapers.php isteğini Repeater'a gönderiyoruz ve sadece üç şeyi değiştiriyoruz:

🔹 HTTP Method

GET → DELETE

🔹 Endpoint

/api/all_wallpapers.php → /api/delete_image.php

🔹 Parametre

?image=1_delete_me.jpg

Son halimiz:

DELETE /lab/api-hacking/api-hacking1/api/delete_image.php?image=1_delete_me.jpg HTTP/1.1
Host: localhost:1337
Cookie: PHPSESSID=...

Bu isteğin body'si yok. Sadece method + endpoint + parametre var.

6️⃣ Sonuç: Backend Kontrol Etmeden İşlemi Yapıyor

İsteği gönderdiğimizde gelen cevap:

{"success":true,"message":null}

Bu cevap şunu gösteriyor:

• API isteği kabul etti
• Yetki kontrolü yapılmadı
• Belirtilen dosya başarıyla silindi

Bu noktada lab teknik olarak çözülmüş oluyor.

7️⃣ Asıl Zafiyet Neydi?

Bu labda sorun:

• Silme işlemi yapan API endpoint'inin:
• Kullanıcı yetkisi kontrol etmemesi
• Rol / izin kontrolü yapmaması
• İsteğin gerçekten UI'dan gelip gelmediğini doğrulamaması

Yani backend şunu yapıyor:

"DELETE isteği geldiyse ve dosya adı verilmişse, sil."

Bu da Broken Authorization + Improper API Design zafiyetidir.