Formunuzda tarayıcı doğrulaması var — boş alan bırakılamıyor, e-posta biçimi kontrol ediliyor. Bu, kullanıcı deneyimi için iyi. Güvenlik için ise hiçbir anlamı yok.
Bu yazı, sunucu tarafı doğrulamanın neden zorunlu olduğunu ve nasıl yapılacağını ele alıyor.
Temel İlke
Güvenliğin başlangıç noktası tek bir kabul üzerine kurulur:
İstemci tarafında yapılan her kontrol atlanabilir.
Bunun nedeni basittir:
- JavaScript kapatılabilir.
- HTML nitelikleri geliştirici araçlarıyla değiştirilebilir.
- İstek doğrudan gönderilebilir. Formunuzu hiç kullanmadan.
- Gizli alanlar düzenlenebilir.
Üçüncü madde en çok gözden kaçandır: saldırgan sizin formunuzu doldurmaz, doğrudan sunucunuza istek gönderir — arayüzünüzdeki hiçbir kontrol devreye girmez.
Bu yüzden istemci doğrulaması bir kolaylıktır, sunucu doğrulaması ise zorunluluktur.
Gizli Alanlar Gizli Değildir
Yaygın bir hata, form içine gizli alanla veri taşımaktır:
- Ürün fiyatı gizli alana yazılır
- Kullanıcı formu gönderir
- Sunucu o fiyatı kullanır
- Kullanıcı fiyatı değiştirebilir
Bu senaryo e-ticaret sitelerinde gerçekten yaşanır: fiyat, indirim oranı veya kullanıcı kimliği gibi bilgiler asla istemciden gelen veriye dayandırılmamalıdır.
Doğru yaklaşım şudur: istemciden yalnızca ürün kimliği gelir, fiyat sunucuda veritabanından okunur. Kullanıcının değiştirebileceği tek şey hangi ürünü istediğidir.
Doğrulama Katmanları
Sunucu tarafında yapılacak kontroller:
| Kontrol | Amaç |
|---|---|
| Varlık | Alan gönderilmiş mi |
| Tür | Sayı mı metin mi |
| Uzunluk | Sınırlar içinde mi |
| Biçim | Beklenen desende mi |
| Aralık | Makul değerler mi |
| İş kuralı | Mantıklı mı |
Altıncı satır teknik değil mantıksal bir kontroldür: negatif adet, geçmiş tarihli rezervasyon veya kendi kendine transfer gibi durumlar teknik olarak geçerli ama mantıken hatalıdır.
Üçüncü satır ise hem güvenlik hem kaynak koruması sağlar. Uzunluk sınırı olmayan bir alan, megabaytlarca veri gönderilerek sunucunuzu boğmak için kullanılabilir.
Yasaklamak Yerine İzin Vermek
Doğrulama yaklaşımında iki felsefe vardır ve biri açıkça üstündür:
- Kara liste: Tehlikeli olanları engelle — kaybedilen bir savaş.
- Beyaz liste: Yalnızca izin verilenleri kabul et — güvenli.
Kara liste yaklaşımının sorunu şudur: her zaman düşünmediğiniz bir girdi biçimi kalır ve saldırganın işi yalnızca o biçimi bulmaktır.
Beyaz liste ise tersini yapar. Bir telefon numarası alanı yalnızca rakam ve birkaç işaret kabul ediyorsa, geri kalan her şey otomatik olarak reddedilir — neyin tehlikeli olduğunu bilmeniz gerekmez.
Veritabanına Yazarken
Doğrulama tek başına yeterli değildir; veriyi kullanırken de dikkat gerekir:
- Sorguları hazırlanmış ifadelerle çalıştırın.
- Değerleri sorgu metnine birleştirmeyin.
- Tablo ve sütun adlarını kullanıcıdan almayın.
- Sıralama alanlarını beyaz listeden seçin.
Birinci madde tek başına en yaygın saldırı sınıfını kapatır: hazırlanmış ifadelerde veri ile sorgu metni ayrı taşınır, dolayısıyla veri asla kod olarak yorumlanmaz.
Dördüncü madde ise ilginç bir istisnadır. Sıralama sütunu hazırlanmış ifadeyle parametre olarak geçirilemez — bu yüzden gelen değeri, izin verilen sütun adları listesiyle karşılaştırmak gerekir.
Ekrana Yazdırırken
Veritabanına güvenli yazmak, güvenli göstermek anlamına gelmez:
| Bağlam | Gereken kaçış |
|---|---|
| HTML gövdesi | HTML kaçışı |
| HTML niteliği | Tırnak dahil kaçış |
| JavaScript içi | Farklı kurallar |
| URL parametresi | URL kodlaması |
Kritik nokta şudur: kaçış işlemi, verinin nereye yazıldığına göre değişir — HTML için doğru olan kaçış, JavaScript içinde yetersiz kalır.
En güvenli yaklaşım, kullanıcı verisini hiç JavaScript içine gömmemektir. Gerekiyorsa bir veri niteliğinde taşıyıp betikten okumak, bağlam karışıklığını ortadan kaldırır.
Dosya Yüklemeleri
Form yükleme içeriyorsa ek kontroller gerekir:
- Uzantıyı beyaz listeyle sınırlayın.
- Dosya imzasını doğrulayın. Beyana güvenmeyin.
- Boyut sınırı koyun.
- Yeni bir ad üretin. Kullanıcının adını kullanmayın.
- Yükleme dizininde kod çalıştırmayı kapatın.
Beşinci madde en kritik önlemdir: yükleme dizininde kod çalıştırma açıksa, yüklenen bir betik doğrudan sunucuda çalıştırılabilir.
Bu ayarı dizin yapılandırma dosyasıyla tanımlayabildiğiniz Linux tabanlı hosting paketleri paketlerinde, yükleme klasörüne özel bir kural eklemek dakikalar sürer ve en büyük riski kapatır.
Hata Mesajları
Doğrulama başarısız olduğunda gösterilen mesaj da bir karardır:
- Kullanıcıya yardımcı olun. Hangi alan, ne bekleniyor?
- Sistem ayrıntısı vermeyin. Veritabanı hatası göstermeyin.
- Girilen veriyi koruyun. Formu boşaltmayın.
- Giriş denemelerinde belirsiz kalın.
Dördüncü madde bir güvenlik dengesidir: "bu e-posta kayıtlı değil" mesajı, saldırgana hangi adreslerin sistemde bulunduğunu söyler.
Giriş formlarında "e-posta veya şifre hatalı" gibi belirsiz bir mesaj kullanmak, kullanıcı deneyimini az miktarda zorlaştırır ama hesap keşfini engeller.
Sonuç
Güvenliğin temeli tek bir kabuldür: istemci tarafında yapılan her kontrol atlanabilir — saldırgan formunuzu doldurmaz, doğrudan sunucunuza istek gönderir. Doğrulamada kara liste değil beyaz liste yaklaşımını benimseyin; neyin tehlikeli olduğunu bilmek zorunda kalmazsınız. Fiyat ve kimlik gibi bilgileri asla istemciden gelen veriye dayandırmayın. Ve unutmayın: kaçış işlemi verinin nereye yazıldığına göre değişir — HTML için doğru olan, JavaScript içinde yetersizdir.
Sıkça Sorulan Sorular (SSS)
Tarayıcı doğrulaması yeterli değil mi?
Güvenlik için hiçbir anlamı yok. JavaScript kapatılabilir, HTML nitelikleri değiştirilebilir ve en önemlisi, istek formunuz hiç kullanılmadan doğrudan gönderilebilir. İstemci doğrulaması bir kullanıcı kolaylığıdır, sunucu doğrulaması zorunluluktur.
Gizli alanla veri taşımak güvenli mi?
Değil — gizli alanlar yalnızca görünmez, korumalı değildir ve kolayca değiştirilebilir. Fiyat, indirim oranı veya kullanıcı kimliği gibi bilgileri istemciden almayın. İstemciden yalnızca ürün kimliği gelsin, fiyat sunucuda veritabanından okunsun.
Kara liste mi beyaz liste mi?
Beyaz liste. Kara listede her zaman düşünmediğiniz bir girdi biçimi kalır ve saldırganın işi yalnızca onu bulmaktır. Beyaz listede ise yalnızca izin verdiğiniz biçimler kabul edilir — neyin tehlikeli olduğunu bilmeniz gerekmez.
Hata mesajlarında neye dikkat etmeliyim?
Kullanıcıya yardımcı olun ama sistem ayrıntısı vermeyin. Özellikle giriş formlarında belirsiz kalın: "bu e-posta kayıtlı değil" mesajı, saldırgana hangi adreslerin sistemde bulunduğunu söyler. "E-posta veya şifre hatalı" ifadesi bu keşfi engeller.
