Çıktı Kaçışlama: Kullanıcı Verisini Sayfada Güvenle Göstermek

Formunuzu doğruluyorsunuz, veritabanına güvenli yazıyorsunuz. Sonra bir kullanıcı yorum alanına bir betik etiketi yazıyor ve o yorumu görüntüleyen herkesin tarayıcısında o kod çalışıyor.

Bu yazı, veriyi sayfada güvenle göstermeyi ele alıyor.

Girdi Doğrulama Yetmez

İki farklı savunma katmanı vardır ve karıştırılır:

İkincisi olmadan birincisi yetersiz kalır: bir yorum metni girdi olarak tamamen geçerlidir — içinde her karakter bulunabilir — ama o metin sayfaya olduğu gibi basıldığında tarayıcı onu kod olarak yorumlar.

Sorun verinin kendisinde değil, gösterildiği bağlamdadır.

Bu nedenle kaçışlama, veriyi kaydederken değil ekrana yazarken yapılmalıdır.

Bağlam Belirleyicidir

Aynı veri farklı yerlerde farklı kaçışlama ister:

• HTML gövdesinde. Etiket karakterleri dönüştürülür.
• Etiket özniteliğinde. Tırnaklar da dahil.
• Adres içinde. Adres kodlaması gerekir.
• Betik içinde. Ayrı kurallar geçerlidir.
• Stil içinde. Çok riskli, kaçınılmalı.

Dördüncü madde en tehlikeli olanıdır: kullanıcı verisini doğrudan bir betik bloğunun içine basmak, HTML kaçışlaması yapılsa bile güvenli değildir — betik bağlamında farklı karakterler tehlike üretir.

Doğru yaklaşım, veriyi betiğe gömmek yerine bir veri özniteliğinde tutup betikten okumaktır.

Üçüncü madde ise sık atlanır. Bir bağlantı adresine yerleştirilen kullanıcı verisi, adres kodlamasından geçirilmelidir.

Varsayılan Kaçışlama

Modern şablon motorları bu işi otomatik yapar:

1. Her değişken varsayılan olarak kaçışlanır.
2. Ham çıktı için özel işaret gerekir.
3. Güvensiz olan görünür hâle gelir.

Üçüncü madde bu yaklaşımın asıl gücüdür: varsayılan güvenli olduğunda, kod incelemesinde yalnızca ham çıktı işaretlerini aramak yeterlidir — güvenlik açığı olabilecek her nokta açıkça belirtilmiş olur.

Manuel kaçışlamada ise unutulan bir yeri bulmak, tüm şablonları tek tek okumayı gerektirir.

Şablon motoru kullanmıyorsanız, en azından bir yardımcı fonksiyon tanımlayıp her çıktıda onu kullanmak gerekir.

Zengin Metin Sorunu

Bazı içeriklerin HTML içermesi gerekir:

İkinci satır sık denenen ve sürekli başarısız olan bir yöntemdir: yasaklı etiket listesi tutmak, saldırganların bulacağı sonsuz varyasyon karşısında her zaman geride kalır — büyük-küçük harf karışımı, kodlama hileleri ve yeni etiketler listeyi aşar.

Üçüncü satır tersini yapar: yalnızca izin verilen etiketler ve öznitelikler bırakılır, kalan her şey atılır.

Dördüncü satır ise sorunu tamamen ortadan kaldırır. Kullanıcı HTML yazmaz, basit bir işaretleme kullanır ve siz onu güvenli HTML'e çevirirsiniz.

Temizleme Kütüphanesi Kullanmak

HTML temizleme kendiniz yazılmayacak işlerdendir:

• Ayrıştırma karmaşıktır.
• Tarayıcı davranışları beklenmediktir.
• Test edilmiş kütüphaneler vardır.

İkinci madde işin neden zor olduğunu açıklar: tarayıcılar bozuk HTML'i toparlamaya çalışır ve bu toparlama sırasında, düz metin sanılan bir şeyi çalıştırılabilir koda dönüştürebilir.

Basit bir düzenli ifade filtresi bu davranışları hesaba katamaz.

Olgunlaşmış bir temizleme kütüphanesi, yıllardır bilinen tüm atlatma yöntemlerine karşı test edilmiştir.

Ek Savunma Katmanı

Kaçışlama tek savunma olmamalıdır:

1. İçerik güvenliği politikası tanımlayın.
2. Satır içi betiği yasaklayın.
3. Betik kaynaklarını sınırlayın.

İkinci madde en etkili tek ayardır: satır içi betik çalıştırmayı yasaklayan bir politika, kaçışlamada bir hata olsa bile enjekte edilen kodun çalışmasını engeller — saldırı başarılı olsa bile etkisiz kalır.

Bu, mevcut sitelerde uygulanması zor olabilir çünkü çoğu tema satır içi betik kullanır.

Kademeli geçiş için önce raporlama modunda çalıştırıp hangi kaynakların engelleneceğini görmek doğru yaklaşımdır.

Depolanan ve Yansıyan

İkinci satır çok daha yıkıcıdır: veritabanına kaydedilen zararlı bir kod, o sayfayı ziyaret eden her kullanıcıda çalışır — bir yönetici o sayfaya baktığında kendi yetkileriyle kod çalıştırmış olur.

Bu yolla yönetici hesabı ele geçirilebilir.

Üçüncü satır ise sunucu tarafında hiç görünmez. Adres parçasındaki veriyi sayfaya yazan bir betik, sunucu günlüklerine hiçbir iz bırakmadan saldırıya açık olur.

Test Etmek

• Her kullanıcı girdisi alanını deneyin.
• Arama sonuç sayfalarını unutmayın.
• Hata mesajlarını kontrol edin.
• Yönetim panelini de test edin.

Üçüncü madde çok atlanır: "aradığınız X bulunamadı" gibi hata mesajları kullanıcı girdisini geri yazar ve kaçışlama yapılmazsa doğrudan bir açık oluşturur.

Aynı durum doğrulama hata mesajları için de geçerlidir.

Dördüncü madde ise en yüksek riski taşır. Yönetim panelinde çalışan bir kod, en yetkili kullanıcıyı hedef alır ve genellikle hiç test edilmez.

Güvenlik başlıkları ve politikalar hosting panelinizden tanımlanabilir; Linux hosting hizmetleri kapsamında kural dosyası üzerinden bu başlıkları ekleyebilirsiniz.

Sonuç

Girdi doğrulama tek başına yetmez çünkü sorun verinin kendisinde değil gösterildiği bağlamdadır — bir yorum metni tamamen geçerli olabilir ama sayfaya olduğu gibi basıldığında tarayıcı onu kod sayar. Kaçışlamayı kaydederken değil ekrana yazarken yapın ve varsayılan olarak kaçışlayan bir şablon motoru kullanın. Zengin metinde kara liste değil beyaz liste uygulayın; yasaklı etiket listesi, saldırganların bulacağı sonsuz varyasyon karşısında her zaman geride kalır.

Sıkça Sorulan Sorular (SSS)

Girdiyi doğruluyorum, yeterli değil mi?

Değil. Bir yorum metni girdi olarak tamamen geçerlidir — içinde her karakter bulunabilir. Sorun o metnin sayfaya olduğu gibi basılmasıdır; tarayıcı onu kod olarak yorumlar. Kaçışlama, veriyi kaydederken değil ekrana yazarken yapılmalıdır.

Her yerde aynı kaçışlama yeterli mi?

Hayır, bağlam belirleyicidir. HTML gövdesi, etiket özniteliği, adres içi ve betik içi farklı kurallar gerektirir. En tehlikelisi betik bağlamıdır — kullanıcı verisini doğrudan bir betik bloğuna basmak, HTML kaçışlaması yapılsa bile güvenli değildir. Veriyi bir veri özniteliğinde tutup betikten okuyun.

Zengin metin girişine izin vermem gerekiyorsa?

Beyaz liste ile temizleyin: yalnızca izin verdiğiniz etiket ve öznitelikler kalsın, gerisi atılsın. Kara liste yaklaşımı güvenilmezdir. Bu temizlemeyi kendiniz yazmayın — tarayıcılar bozuk HTML'i toparlarken düz metin sanılan şeyi çalıştırılabilir koda dönüştürebilir; olgunlaşmış bir kütüphane kullanın.

Hangi alanları test etmeliyim?

Tüm kullanıcı girdisi alanlarını, ayrıca çok atlanan iki yeri: arama sonuç sayfalarını ve hata mesajlarını. "Aradığınız X bulunamadı" gibi mesajlar kullanıcı girdisini geri yazar. Yönetim panelini de mutlaka test edin — orada çalışan bir kod en yetkili kullanıcıyı hedef alır.