Emirhan
New member
Double Parse Nedir? Aynı Verinin İki Kez Yorumlanması Neden Önemli?
Teknolojiyle, yazılımla veya siber güvenlikle biraz olsun ilgilenenlerin bir noktada karşısına “double parse” ya da buna yakın biçimde kullanılan “parser differential” kavramı çıkıyor. İlk bakışta oldukça teknik ve dar bir konu gibi görünse de aslında günlük internet deneyimimizin arkasındaki önemli sorunlardan birine dokunuyor: Aynı veriyi iki farklı sistem okursa gerçekten aynı şeyi mi anlar?
Benim bu konudaki yaklaşımım, “double parse” ifadesini yalnızca bir verinin iki kez işlenmesi olarak değil, özellikle güvenlik bağlamında aynı girdinin birden fazla parser tarafından veya birden fazla aşamada farklı biçimde yorumlanması üzerinden değerlendirmek. Çünkü modern uygulamalarda veri çoğu zaman tek bir yazılımdan geçmiyor. Bir istek CDN'den, güvenlik duvarından, ters proxy'den, web sunucusundan, API ağ geçidinden ve nihayet uygulamadan geçebiliyor.
Tam burada küçük bir yorum farkı bile büyük sonuçlar doğurabiliyor.
GitLab'ın güvenlik araştırmalarında parser differentials, aynı mesajın farklı bileşenler tarafından farklı yorumlanması şeklinde açıklanıyor. GitHub'ın 2025'te yayımladığı bir araştırma ise SAML doğrulamasında iki farklı XML parser'ının aynı veri üzerinde farklı sonuçlara ulaşabilmesinin kimlik doğrulama atlatma riskine dönüşebildiğini gösterdi. GitLab+1
Double Parse Tam Olarak Ne Demek?
“Parse” kelimesi en basit haliyle, bilgisayarın ham veriyi anlamlandırmasıdır. Örneğin bir JSON metni uygulamaya geldiğinde parser bu metni okuyarak anahtarları, değerleri ve veri yapısını çıkarır.
Double parse ise genel kullanımda bir verinin iki ayrı ayrıştırma veya yorumlama aşamasından geçmesini anlatabilir.
Burada önemli bir ayrım var. Bir verinin iki kez parse edilmesi tek başına güvenlik açığı değildir. Bir uygulamanın önce JSON'u, ardından JSON içindeki belirli bir alanı başka bir format olarak işlemesi gayet normal olabilir.
Sorun, iki aşamanın aynı veriyi aynı şekilde yorumlamaması ile başlar.
Örneğin bir güvenlik katmanı URL'nin hedefini bir parser kullanarak değerlendirirken, arka plandaki HTTP istemcisi aynı URL'yi başka bir parser ile yorumluyorsa iki sistem farklı bir hedef görebilir. 2026'da yayımlanan bir GitHub güvenlik duyurusunda da SSRF korumasındaki parser farklılığının URL'nin güvenlik kontrolü ile gerçek HTTP isteği arasında farklı yorumlanmasına yol açabildiği görülüyor. GitHub+1
Yani asıl mesele “iki kere parse edildi” değil, “iki kez parse edildiğinde iki farklı anlam ortaya çıktı” sorusudur.
Parser Differential ile Double Parse Arasındaki İlişki
Bu iki kavramı birbirinden ayırmak faydalı.
Double parse daha geniş bir ifade olarak bir girdinin birden fazla ayrıştırma aşamasından geçmesini anlatabilir. Parser differential ise iki parser'ın aynı girdiyi farklı yorumlaması durumudur.
Dolayısıyla her double parse parser differential oluşturmaz.
Basit bir örnek düşünelim. Bir sistem gelen XML'i önce parser A ile okuyor, daha sonra aynı XML'i parser B'ye gönderiyor. Eğer A ve B aynı düğümü, aynı özniteliği ve aynı yapıyı görüyorlarsa ortada otomatik olarak bir güvenlik sorunu yoktur.
Fakat A'nın “güvenli” kabul ettiği bölge ile B'nin uygulamaya aktardığı bölge farklıysa problem başlar.
GitHub'ın ruby-saml araştırması bu açıdan oldukça öğretici. Araştırmacılar aynı güvenlik doğrulama sürecinde REXML ve Nokogiri olmak üzere iki XML parser'ının kullanıldığını tespit etti. Parser'ların aynı XPath sorgusuna farklı sonuç verebilmesi, imza doğrulamasıyla uygulamanın daha sonra kullandığı veri arasında ayrışma yaratabiliyordu. Sonuç olarak belirli koşullarda kimlik doğrulamanın atlatılmasına kadar giden açıklar ortaya çıktı. The GitHub Blog
Bu örnek bana göre kavramı anlamanın en iyi yollarından biri: Sorun verinin karmaşık olması değil, güvenlik kararını veren sistem ile veriyi kullanan sistemin aynı gerçekliği görmemesi.
Neden Modern Sistemlerde Risk Daha da Artıyor?
Eskiden bir web uygulamasını kabaca tarayıcı → web sunucusu → uygulama şeklinde düşünmek mümkündü. Bugün mimariler çok daha parçalı.
Bir kullanıcı isteği CDN, WAF, load balancer, reverse proxy, API gateway, servis mesh, mikroservis ve uygulama katmanlarından geçebiliyor.
Her katman kendi parser'ını, normalizasyon yöntemini veya kütüphanesini kullanabiliyor.
Bu durum özellikle HTTP isteklerinde, URL'lerde, XML'de, JSON'da, dosya formatlarında ve kimlik doğrulama protokollerinde önem kazanıyor.
GitLab'ın araştırması da modern web mimarisinde farklı bileşenlerin aynı HTTP isteğini farklı yorumlamasının güvenlik açığı oluşturabileceğini gösteriyor. GitLab+1
Örneğin ön taraftaki sistem bir isteği zararsız kabul ederken arka taraftaki servis isteğin farklı bir bölümünü esas alabilir. Güvenlik kontrolü bir parser'ın gördüğü gerçekliğe, uygulama ise başka parser'ın gördüğü gerçekliğe göre hareket eder.
Bu nedenle gelecekte yazılım güvenliğinin yalnızca “gelen veri temiz mi?” sorusundan ibaret olmayacağını düşünüyorum. Daha kritik soru şu olacak:
“Bu veriyi zincirdeki bütün bileşenler aynı şekilde mi yorumluyor?”
2026 Sonrası İçin En Önemli Eğilim: Parser Uyumluluğu
Önümüzdeki yıllarda parser uyumluluğunun daha fazla gündeme geleceğini düşünüyorum. Bu bir tahmin olsa da dayanağı oldukça somut.
MITRE'nin EMB3D çalışması parser güvenlik açıklarını ve özellikle parser differentials sorununu doğrudan ele alıyor. Çalışmada formal verification, yani parser'ın belirli bir format tanımına uygun davrandığının matematiksel yöntemlerle doğrulanması, ileri düzey bir azaltma yöntemi olarak gösteriliyor. MITRE EMB3D™
Bunun önemli bir sonucu olabilir: Gelecekte kritik güvenlik bileşenlerinde “hangi parser daha hızlı?” sorusundan çok “hangi parser'ın davranışı daha öngörülebilir ve doğrulanabilir?” sorusu önem kazanabilir.
Özellikle finans, savunma, sağlık, kimlik doğrulama ve kamu sistemlerinde bu yaklaşımın güçlenmesini bekliyorum.
Stratejik açıdan bakıldığında erkek veya kadın geliştiricilerin farklı bakış açıları getirmesi de burada değerli olabilir. Erkek mühendislerin önemli bir bölümünün mimari sadeleştirme, performans, saldırı yüzeyi ve sistem dayanıklılığı gibi stratejik başlıklara yoğunlaşması mümkünken; kadın mühendislerin ve güvenlik araştırmacılarının önemli katkılarının kullanıcı güveni, erişilebilirlik, hata durumlarının insan üzerindeki etkisi ve kurumsal süreçler gibi alanlarda öne çıkması mümkün. Ancak bunu cinsiyete bağlı bir yetenek farkı olarak görmemek gerekir. Bu tür yaklaşımlar kişiden kişiye değişir ve ekiplerin çeşitliliği asıl avantajı yaratır.
Bence geleceğin güçlü güvenlik ekipleri, bu bakış açılarını birbirinin alternatifi değil tamamlayıcısı olarak değerlendirecek.
Yapay Zekâ Double Parse Sorununu Büyütebilir mi?
Bence en ilginç gelecek tartışmalarından biri burada.
Yapay zekâ sistemleri giderek daha fazla yapılandırılmış veriyle çalışıyor. API'lerden gelen JSON'lar, araç çağrıları, XML belgeleri, kullanıcı tarafından yüklenen dosyalar ve farklı formatlardaki dokümanlar bir modelin işlem zincirine girebiliyor.
Bu zincirde verinin bir parser tarafından okunması, yapay zekâ katmanına aktarılması, başka bir serviste tekrar yorumlanması ve son olarak bir uygulamaya gönderilmesi mümkün.
Teknolojiyle, yazılımla veya siber güvenlikle biraz olsun ilgilenenlerin bir noktada karşısına “double parse” ya da buna yakın biçimde kullanılan “parser differential” kavramı çıkıyor. İlk bakışta oldukça teknik ve dar bir konu gibi görünse de aslında günlük internet deneyimimizin arkasındaki önemli sorunlardan birine dokunuyor: Aynı veriyi iki farklı sistem okursa gerçekten aynı şeyi mi anlar?
Benim bu konudaki yaklaşımım, “double parse” ifadesini yalnızca bir verinin iki kez işlenmesi olarak değil, özellikle güvenlik bağlamında aynı girdinin birden fazla parser tarafından veya birden fazla aşamada farklı biçimde yorumlanması üzerinden değerlendirmek. Çünkü modern uygulamalarda veri çoğu zaman tek bir yazılımdan geçmiyor. Bir istek CDN'den, güvenlik duvarından, ters proxy'den, web sunucusundan, API ağ geçidinden ve nihayet uygulamadan geçebiliyor.
Tam burada küçük bir yorum farkı bile büyük sonuçlar doğurabiliyor.
GitLab'ın güvenlik araştırmalarında parser differentials, aynı mesajın farklı bileşenler tarafından farklı yorumlanması şeklinde açıklanıyor. GitHub'ın 2025'te yayımladığı bir araştırma ise SAML doğrulamasında iki farklı XML parser'ının aynı veri üzerinde farklı sonuçlara ulaşabilmesinin kimlik doğrulama atlatma riskine dönüşebildiğini gösterdi. GitLab+1
Double Parse Tam Olarak Ne Demek?
“Parse” kelimesi en basit haliyle, bilgisayarın ham veriyi anlamlandırmasıdır. Örneğin bir JSON metni uygulamaya geldiğinde parser bu metni okuyarak anahtarları, değerleri ve veri yapısını çıkarır.
Double parse ise genel kullanımda bir verinin iki ayrı ayrıştırma veya yorumlama aşamasından geçmesini anlatabilir.
Burada önemli bir ayrım var. Bir verinin iki kez parse edilmesi tek başına güvenlik açığı değildir. Bir uygulamanın önce JSON'u, ardından JSON içindeki belirli bir alanı başka bir format olarak işlemesi gayet normal olabilir.
Sorun, iki aşamanın aynı veriyi aynı şekilde yorumlamaması ile başlar.
Örneğin bir güvenlik katmanı URL'nin hedefini bir parser kullanarak değerlendirirken, arka plandaki HTTP istemcisi aynı URL'yi başka bir parser ile yorumluyorsa iki sistem farklı bir hedef görebilir. 2026'da yayımlanan bir GitHub güvenlik duyurusunda da SSRF korumasındaki parser farklılığının URL'nin güvenlik kontrolü ile gerçek HTTP isteği arasında farklı yorumlanmasına yol açabildiği görülüyor. GitHub+1
Yani asıl mesele “iki kere parse edildi” değil, “iki kez parse edildiğinde iki farklı anlam ortaya çıktı” sorusudur.
Parser Differential ile Double Parse Arasındaki İlişki
Bu iki kavramı birbirinden ayırmak faydalı.
Double parse daha geniş bir ifade olarak bir girdinin birden fazla ayrıştırma aşamasından geçmesini anlatabilir. Parser differential ise iki parser'ın aynı girdiyi farklı yorumlaması durumudur.
Dolayısıyla her double parse parser differential oluşturmaz.
Basit bir örnek düşünelim. Bir sistem gelen XML'i önce parser A ile okuyor, daha sonra aynı XML'i parser B'ye gönderiyor. Eğer A ve B aynı düğümü, aynı özniteliği ve aynı yapıyı görüyorlarsa ortada otomatik olarak bir güvenlik sorunu yoktur.
Fakat A'nın “güvenli” kabul ettiği bölge ile B'nin uygulamaya aktardığı bölge farklıysa problem başlar.
GitHub'ın ruby-saml araştırması bu açıdan oldukça öğretici. Araştırmacılar aynı güvenlik doğrulama sürecinde REXML ve Nokogiri olmak üzere iki XML parser'ının kullanıldığını tespit etti. Parser'ların aynı XPath sorgusuna farklı sonuç verebilmesi, imza doğrulamasıyla uygulamanın daha sonra kullandığı veri arasında ayrışma yaratabiliyordu. Sonuç olarak belirli koşullarda kimlik doğrulamanın atlatılmasına kadar giden açıklar ortaya çıktı. The GitHub Blog
Bu örnek bana göre kavramı anlamanın en iyi yollarından biri: Sorun verinin karmaşık olması değil, güvenlik kararını veren sistem ile veriyi kullanan sistemin aynı gerçekliği görmemesi.
Neden Modern Sistemlerde Risk Daha da Artıyor?
Eskiden bir web uygulamasını kabaca tarayıcı → web sunucusu → uygulama şeklinde düşünmek mümkündü. Bugün mimariler çok daha parçalı.
Bir kullanıcı isteği CDN, WAF, load balancer, reverse proxy, API gateway, servis mesh, mikroservis ve uygulama katmanlarından geçebiliyor.
Her katman kendi parser'ını, normalizasyon yöntemini veya kütüphanesini kullanabiliyor.
Bu durum özellikle HTTP isteklerinde, URL'lerde, XML'de, JSON'da, dosya formatlarında ve kimlik doğrulama protokollerinde önem kazanıyor.
GitLab'ın araştırması da modern web mimarisinde farklı bileşenlerin aynı HTTP isteğini farklı yorumlamasının güvenlik açığı oluşturabileceğini gösteriyor. GitLab+1
Örneğin ön taraftaki sistem bir isteği zararsız kabul ederken arka taraftaki servis isteğin farklı bir bölümünü esas alabilir. Güvenlik kontrolü bir parser'ın gördüğü gerçekliğe, uygulama ise başka parser'ın gördüğü gerçekliğe göre hareket eder.
Bu nedenle gelecekte yazılım güvenliğinin yalnızca “gelen veri temiz mi?” sorusundan ibaret olmayacağını düşünüyorum. Daha kritik soru şu olacak:
“Bu veriyi zincirdeki bütün bileşenler aynı şekilde mi yorumluyor?”
2026 Sonrası İçin En Önemli Eğilim: Parser Uyumluluğu
Önümüzdeki yıllarda parser uyumluluğunun daha fazla gündeme geleceğini düşünüyorum. Bu bir tahmin olsa da dayanağı oldukça somut.
MITRE'nin EMB3D çalışması parser güvenlik açıklarını ve özellikle parser differentials sorununu doğrudan ele alıyor. Çalışmada formal verification, yani parser'ın belirli bir format tanımına uygun davrandığının matematiksel yöntemlerle doğrulanması, ileri düzey bir azaltma yöntemi olarak gösteriliyor. MITRE EMB3D™
Bunun önemli bir sonucu olabilir: Gelecekte kritik güvenlik bileşenlerinde “hangi parser daha hızlı?” sorusundan çok “hangi parser'ın davranışı daha öngörülebilir ve doğrulanabilir?” sorusu önem kazanabilir.
Özellikle finans, savunma, sağlık, kimlik doğrulama ve kamu sistemlerinde bu yaklaşımın güçlenmesini bekliyorum.
Stratejik açıdan bakıldığında erkek veya kadın geliştiricilerin farklı bakış açıları getirmesi de burada değerli olabilir. Erkek mühendislerin önemli bir bölümünün mimari sadeleştirme, performans, saldırı yüzeyi ve sistem dayanıklılığı gibi stratejik başlıklara yoğunlaşması mümkünken; kadın mühendislerin ve güvenlik araştırmacılarının önemli katkılarının kullanıcı güveni, erişilebilirlik, hata durumlarının insan üzerindeki etkisi ve kurumsal süreçler gibi alanlarda öne çıkması mümkün. Ancak bunu cinsiyete bağlı bir yetenek farkı olarak görmemek gerekir. Bu tür yaklaşımlar kişiden kişiye değişir ve ekiplerin çeşitliliği asıl avantajı yaratır.
Bence geleceğin güçlü güvenlik ekipleri, bu bakış açılarını birbirinin alternatifi değil tamamlayıcısı olarak değerlendirecek.
Yapay Zekâ Double Parse Sorununu Büyütebilir mi?
Bence en ilginç gelecek tartışmalarından biri burada.
Yapay zekâ sistemleri giderek daha fazla yapılandırılmış veriyle çalışıyor. API'lerden gelen JSON'lar, araç çağrıları, XML belgeleri, kullanıcı tarafından yüklenen dosyalar ve farklı formatlardaki dokümanlar bir modelin işlem zincirine girebiliyor.
Bu zincirde verinin bir parser tarafından okunması, yapay zekâ katmanına aktarılması, başka bir serviste tekrar yorumlanması ve son olarak bir uygulamaya gönderilmesi mümkün.