Güvenlik açığı başlıklarını okuduğunuzda, XML enjeksiyonu nadiren dikkat çeker. RCE ya da SQLi gibi çarpıcı bir isim bilinirliğine sahip değildir ve gösterişli bir uzaktan istismar kadar görsel olarak dramatik değildir. Ancak birçok kurumsal yığında - SOAP uç noktaları, eski XML API'leri, belge işleme hatları ve SAML/SOAP entegrasyonları - XML enjeksiyonu, güvenilir girdileri mantık hatalarına dönüştüren sessiz hata modudur.
XML enjeksiyonu özünde tek bir istismar değildir. Saldırgan tarafından kontrol edilen XML'in bir sunucunun bir isteği yorumlama şeklini değiştirdiği bir davranışlar ailesidir. Bu, bir XPath sorgusunun aniden beklenmedik kayıtlar döndürmesi, bir ayrıştırıcının çağırmasını istemediğiniz harici kaynakları çözümlemesi veya varlık genişletmenin CPU ve bellek tüketmesi anlamına gelebilir. Bir saldırganın bakış açısından bunlar pratik yapı taşlarıdır: dosyaları okumak, dahili istekleri tetiklemek veya faydalı kaosa neden olmak. Bir savunmacının bakış açısından ise aynı parçalar, mantık ve gözlemlenebilirlik boşluklarını düzeltmek için bir navigasyon haritasıdır.
Küçük, somut bir tat - kimseye bir oyun kitabı vermeden
Örüntüyü görmek için süslü yüklere ihtiyacınız yok. İstek alanlarından saf dize birleştirme yoluyla bir XPath oluşturan sunucu tarafı kodunu hayal edin:
// savunmasız model (sözde)
userId = request.xml.user.id
rol = request.xml.user.role
query = "doc('/db/users.xml')/users/user[id = " + userId + " and role = '" + role + "']"
result = xmlEngine.evaluate(query)
Bu zararsız görünüyor eğer userId ve rol iyi biçimlendirilmişlerdir. Ancak kullanıcı girdisinin sorgunun yapısını kontrol etmesine izin verdiğinizde Veri ve mantık. XPath enjeksiyonu bunun doğal sonucudur: kırılgan bir sorgu, doğruluk koşullarını değiştirmek ve olmaması gereken satırları döndürmek için manipüle edilebilir.
Bir başka eksen de varlık ya da DTD işlemedir. Birçok XML motoru belge türü bildirimlerine, varlıklara ve harici referanslara izin verir - meşru kompozisyon için yararlıdır, ancak güvenilmeyen girdi için açıldığında tehlikelidir. Savunma kuralı basittir: varlık genişletmeye veya DOCTYPE işlemeye ihtiyacınız yoksa, kapatın.
Yapılandırmayı ayrıştırmak neden gizli açıklardan daha önemli?
Bu sorunun iki seviyesi vardır. Birincisi iş mantığı hatasıdır - güvenilmeyen değerleri sorgu mantığına aktarmak, XML'i XPath veya XPath benzeri değerlendiricilere şablonlamak ve "iyi biçimlendirilmiş" ifadesinin "güvenli" anlamına geldiğini varsaymak. Bu tasarımla düzeltilebilir: doğrulama, kanonikleştirme ve verileri sorgulardan ayırma.
İkincisi ayrıştırıcı davranışıdır. XML ayrıştırıcıları güçlüdür; dosya içeriklerini getirebilir, HTTP istekleri yapabilir veya belleği balon gibi şişiren iç içe geçmiş varlıkları genişletebilirler. Bu yetenekler kontrollü bağlamlarda iyidir, genel girdiler kabul edildiğinde felakettir. Dolayısıyla pratik savunma, ayrıştırıcı sağlamlaştırma artı davranışsal telemetridir.
Pratik, mühendis dostu karşı önlemler (örneklerle)
Güvende olmak için XML'i yasaklamak zorunda değilsiniz. Üç alışkanlık değişikliğine ihtiyacınız var:
1) Ayrıştırıcı kapasitesini sınırlayın. Çoğu dilde harici varlıkları ve DOCTYPE işlemeyi devre dışı bırakabilirsiniz. Örneğin, Java'da (pseudo-API):
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("", true);
dbf.setFeature("", false);
dbf.setFeature("", false);
Ya da Python'da defusedxml (varsayılan olarak güvenli davranan bir kütüphane kullanın):
from defusedxml.ElementTree import fromstring
tree = fromstring(untrusted_xml)
2) Doğrulayın ve kanonikleştirin. Uç noktanız yalnızca küçük bir etiket kümesine ihtiyaç duyuyorsa, bir XSD'ye karşı doğrulama yapın veya beklenmedik DOCTYPE'leri reddedin. Dize birleştirme yoluyla sorgu oluşturmak yerine veri yapılarına ayrıştırmayı ve parametrelendirilmiş erişimi kullanmayı tercih edin.
3) Alet ve alarm. Garip sinyalleri izleyen kancalar ekleyin: DOCTYPE/ENTITY referanslı ayrıştırıcı istisnaları, ayrıştırma hizmetinden ani giden DNS/HTTP veya ayrıştırma sırasında başlatılan dosya açma işlemleri. Bu sinyaller herhangi bir statik kural listesinden çok daha fazla eyleme geçirilebilir.
Savunuculara gerçekten yardımcı olan algılanabilir sinyaller
İzlemeyi ayarlarken, kırılgan metinsel imzalara değil, gerçek davranışlara bakın:
- Ayrıştırıcı işleminizden kaynaklanan giden DNS veya HTTP çağrıları.
- XML işleme sırasında meydana gelen yerel yollara dosya erişim denemeleri.
- DOCTYPE veya harici varlık çözümlemesinden bahseden ayrıştırıcı istisna izleri.
- Aniden yalnızca dahili alanlar veya veriler içeren yanıtlar (XPath veya sorgu manipülasyonunu gösterir).
- Normal yük altında ayrıştırma kodunda olağandışı CPU/bellek artışları.
Bunlar alarm verebileceğiniz ve hızlı bir şekilde önceliklendirebileceğiniz şeylerdir.
Pervasız olmadan nasıl pratik yapılır
Deneme yapmak istiyorsanız - algılama kurallarını doğrulamak, ayrıştırıcı sağlamlaştırmanın işe yaradığını onaylamak veya CTF tarzı bir meydan okuma üzerinde eğitim almak - bunu yalnızca kontrollü laboratuvarlarda yapın. Üretimde hatalı biçimlendirilmiş XML kullanmayın. Bunun yerine, yalıtılmış sanal makineler, kanıtlanabilir laboratuvar aralıkları veya sterilize edilmiş, sömürücü olmayan test vakaları.
Doğal dil iş akışı - Penligent döngüde
Bu, pratik otomasyonun işe yaradığı yerdir. Sadece ayrıştırıcı ayarlarını veya algılama mantığını doğrulamak için düzinelerce testi elle kodlamak zorunda kalmamalısınız. Aşağıdaki gibi doğal dil odaklı bir pentest aracı ile Penligentgünlük dilde akış şu şekilde görünür:
"Hazırlama SOAP uç noktalarımızı XML enjeksiyon risklerine karşı kontrol edin. Yalnızca güvenli problar kullanın, ayrıştırıcı istisnalarını, dosya erişim olaylarını ve giden DNS/HTTP geri aramalarını toplayın. Önceliklendirilmiş güçlendirme adımları üretin."
Penligent, bu cümleyi yetkili test ortamınıza karşı hedeflenmiş, sterilize edilmiş kontrollere dönüştürür. Odaklanmış test senaryoları çalıştırır (canlı istismar zincirleri değil), telemetri toplar (ayrıştırıcı hataları, dosya erişim günlükleri, DNS geri aramaları), kanıtları ilişkilendirir ve kısa bir düzeltme kontrol listesi döndürür. CTF oyuncuları için avantaj hızdır: kabuk komut dosyaları yazmadan veya düzinelerce yük dosyası hazırlamadan bir hipotezi doğrulayabilir ve tespitinizin ateşlenip ateşlenmeyeceğini öğrenebilir - ardından yineleyebilirsiniz.
Kapanış düşüncesi
XML enjeksiyonu, bir güvenlik açığı liderlik tablosunda dikkat çekici görünmez, ancak gerçek gücü gizlidir. Veri katmanının zararsız olduğu, ayrıştırıcının "beklendiği gibi" davrandığı, izlemenin bariz hataları yakalayacağı gibi varsayımlardan yararlanır. Bunu düzeltmek sihirli bir yamadan ziyade tasarım hijyeniyle ilgilidir: ayrıştırıcı ayrıcalığını en aza indirmek, verileri mantıktan ayırmak, agresif bir şekilde doğrulamak ve önemli olan sinyalleri ölçmek. Doğal dil amacını güvenli doğrulama çalışmalarına dönüştüren araçlar, angarya işleri ortadan kaldırır ve ekiplerin düzeltme ve öğrenmeye odaklanmasını sağlar - ki modern savunma otomasyonunun amacı da tam olarak budur.
