XML harici varlık saldırısı, XML işleyicilerin harici varlık tanımlarını güvensiz biçimde işlemesinden yararlanan bir zafiyettir. XML biçimi, belge içinde dışarıdan içerik çağırmayı mümkün kılan varlık tanımlarını destekler. Bir uygulama, bu tanımları işleyen ve dış kaynaklara erişime izin veren bir yapılandırmayla XML işlerse risk doğar. Saldırgan, hazırladığı kötü niyetli bir XML belgesiyle sunucudaki dosyaları okuyabilir ya da iç kaynaklara erişebilir. Bu geniş etki, zafiyeti ciddi bir sunucu tarafı risk hâline getirir.

Sorunun kökeninde, XML işleyicilerin varsayılan yapılandırmalarının güvensiz olması yatar. Birçok işleyici, harici varlık işlemeyi varsayılan olarak etkin biçimde gelir. Geliştirici bu davranışın farkında değilse, uygulama farkında olmadan savunmasız kalır. Bu nedenle zafiyet, çoğu zaman bilinçli bir hatadan değil, güvensiz varsayılanlardan kaynaklanır. Bu durum, güvenli varsayılanların önemini açıkça ortaya koyar.

XXE Nedir?

XXE, XML işleyicinin harici varlık tanımlarını işlemesinden yararlanarak sunucudaki dosyaların okunmasını ya da iç kaynaklara erişimi sağlayan bir zafiyettir.

Saldırının en yaygın biçimi, sunucudaki dosyaların okunmasıdır. Saldırgan, bir harici varlığı yerel bir dosyayı işaret edecek biçimde tanımlar. İşleyici bu tanımı çözerken dosyanın içeriğini belgeye dahil eder ve saldırgana döndürebilir. Böylece yapılandırma dosyaları ya da hassas veriler okunabilir hâle gelir. Bu okuma yeteneği, saldırganın sistemi daha derinden tanımasına olanak tanır.

Bir diğer etki biçimi, iç kaynaklara yapılan isteklerdir. Saldırgan, harici varlığı iç ağdaki bir adrese yönlendirerek sunucuyu bu adrese istek göndermeye zorlayabilir. Bu davranış, sunucu tarafı istek sahteciliğine benzer bir etki üretir. Sunucu taraflı istek sahteciliği ile birlikte değerlendirildiğinde etki alanı genişler. Böylece dışarıdan erişilemeyen iç servisler hedef alınabilir.

Nasıl Önlenir?

En etkili önlem, XML işleyicide harici varlık işlemeyi tamamen devre dışı bırakmaktır. Çoğu işleyici, bu davranışı kapatmak için bir yapılandırma seçeneği sunar. Uygulama XML’i işlerken bu güvenli yapılandırmayı açıkça uygulamalıdır. Böylece kötü niyetli varlık tanımları hiç işlenmez ve saldırı olanağı ortadan kalkar. Bu tek yapılandırma değişikliği, zafiyetin en yaygın biçimlerini kökten önler.

İkinci önlem, girdi olarak alınan XML’in doğrulanmasıdır. Uygulama, yalnızca beklenen yapıya uygun belgeleri kabul edecek biçimde tasarlanmalıdır. Girdi doğrulama bu bağlamda ek bir savunma katmanı sağlar. Ayrıca mümkün olduğunda, XML yerine daha basit ve güvenli veri biçimleri tercih edilebilir. Bu tercih, saldırı yüzeyini baştan daraltan bir tasarım kararıdır.

• XML işleyicide harici varlık işlemenin devre dışı bırakılması
• Belge tür tanımı işlemenin kapatılması
• Girdi olarak alınan XML’in yapısal olarak doğrulanması
• Mümkün olduğunda daha güvenli veri biçimlerinin tercih edilmesi
• Kullanılan işleyici kütüphanelerinin güncel tutulması

Test ve Doğrulama

Zafiyetin tespiti, XML kabul eden tüm giriş noktalarının incelenmesini gerektirir. Dosya yükleme, veri alışverişi ve yapılandırma içe aktarma gibi işlevler tipik risk noktalarıdır. Web uygulama sızma testi bu noktaları hedefli yüklerle değerlendirir. Ayrıca kod incelemesi, güvensiz işleyici yapılandırmalarını erken yakalar. İki yaklaşım birlikte, zafiyetin hem çalışma zamanında hem kodda tespit edilmesini sağlar.

Görünmeyen ve Kör Biçimleri

Bu zafiyet her zaman doğrudan çıktı üretmez; bazı durumlarda sonuç dolaylı yollarla anlaşılır. Kör biçimde, işleyicinin okuduğu içerik doğrudan geri döndürülmez ama başka kanallardan sızdırılabilir. Saldırgan, okunan dosyayı dışarıdaki bir sunucuya gönderten yükler hazırlayarak veriyi elde edebilir. Bu nedenle görünür bir çıktı olmaması, zafiyetin bulunmadığı anlamına gelmez. Kör biçimler, tespiti zorlaştırdığı için özellikle dikkatli test gerektirir.

Bir diğer görünmez etki, hizmet dışı bırakma biçimidir. Özenle hazırlanmış varlık tanımları, işleyicinin aşırı kaynak tüketmesine yol açarak uygulamayı yanıt veremez hâle getirebilir. Bu biçim, veri sızdırmasa da hizmetin kesintiye uğramasına neden olur. Bu nedenle savunma, yalnızca dosya okumaya değil kaynak tüketimine karşı da tasarlanmalıdır. İşleyici yapılandırması, bu tür aşırı tüketimi sınırlayacak biçimde ayarlanmalıdır.

Güvenli Varsayılan İlkesi

Bu zafiyet, güvenli varsayılanların önemini açıkça ortaya koyan bir örnektir. Sorun genellikle bilinçli bir hatadan değil, işleyicinin güvensiz varsayılan yapılandırmasından kaynaklanır. Bu nedenle geliştiriciler, kullandıkları kütüphanelerin varsayılan davranışlarını bilmeli ve güvenli hâle getirmelidir. Varsayılan güvenli yapılandırma ilkesi bu bağlamda kritik önem taşır. Güvenli varsayılanların benimsenmesi, benzer zafiyetlerin en baştan önlenmesini sağlar.

Kütüphane seçimi ve güncelliği de bu ilkenin bir parçasıdır. Güvenli varsayılanlarla gelen güncel kütüphaneler, geliştirici hatası olasılığını azaltır. Eski sürümler ise hem güvensiz varsayılanlar hem de bilinen zafiyetler barındırabilir. Bu nedenle kullanılan işleyici kütüphaneleri düzenli olarak güncellenmelidir. Güncel ve güvenli varsayılanlı bileşenler, savunmanın önemli bir temelini oluşturur.

Privia Security olarak XML işleyen uygulamalarda harici varlık ve ilgili zafiyetlerin tespitini düzenli zafiyet tarama kapsamında değerlendiriyoruz.