Client-side doğrulama bir güvenlik sınırı değil, UX aracıdır; dev.to yazısı geliştiricileri uyarıyor

dev.to'da yakın zamanda yayımlanan bir yazı, web güvenliğinin en eski ve en sık gözden kaçan derslerinden birine geri dönüyor: tarayıcıda çalışan doğrulama bir kolaylık özelliğidir, güvenlik kontrolü değil. Yazar, uygulamanın gerçekte dayandığı her kuralın sunucuda yeniden uygulanması gerektiğini savunuyor; çünkü kullanıcının tarayıcısında çalışan her şey atlatılabilir.

Tarayıcı nasıl atlatılır

Yazıya göre bir sayfa e-posta adresi zorunlu kılabilir, kullanıcı adının uzunluğunu sınırlayabilir veya belirli karakterlerin yazılmasını tamamen engelleyebilir — ve bunların hiçbiri kararlı bir kullanıcıya karşı dayanamaz. Birisi sayfanın HTML'ini düzenleyebilir, JavaScript'i kapatabilir, tarayıcının geliştirici araçlarıyla istekleri değiştirebilir ya da sayfayı tamamen atlayıp curl, Postman veya Burp Suite gibi araçlarla doğrudan endpoint ile iletişim kurabilir.

Yazının örnek vakası, kullanıcı adını 20 karakterle sınırlayan bir kayıt formu. Meşru bir gönderim kısa bir değer taşır; ancak doğrudan sunucuya istek gönderen bir saldırgan böyle bir kısıtlamaya tabi değildir, çünkü sınır yalnızca formda var olmuştur.

Her gelen değeri güvenilmeyen olarak ele alın

Yazarın ortaya koyduğu temel kural basit: sunucu, tarayıcının neyi denetlemiş olduğuna bakmaksızın tüm gelen veriyi güvenilmeyen olarak görmelidir. Bu; form alanları, URL parametreleri, JSON istek gövdeleri, HTTP header'ları, cookie'ler, dosya yüklemeleri ve API istekleri için geçerlidir.

Yazı, bir kullanıcı kimliğini sayıya dönüştürmek ve pozitif bir tam sayı olmadığı takdirde reddetmek gibi sunucu tarafı kontrollerle örnekliyor. Vurgulanan nokta belirli koddan çok kodun nerede çalıştığı — yani isteğin sunucuya ulaştığı andan sonra, zira sunucu herhangi bir client-side kontrolün yapıldığını varsayamaz.

Doğrulama, sanitizasyon ve allow list'ler

Yazar, geliştiricilerin sık karıştırdığı bir ayrım da çiziyor. Doğrulama, bir değerin kabul edilebilir olup olmadığını sorar: tam sayı mı, dize beklenen uzunlukta mı, bilinen bir kümeye mi ait, beklenen formata mı uyuyor. Sanitizasyon ise bir değeri daha güvenli hale getirmek amacıyla içeriği değiştirir veya ayıklar.

Bir uygulama az sayıda bilinen değer bekliyorsa — active, inactive veya pending gibi durumlar — yazı, tam olarak neyin kabul edildiğini tanımlayan ve geri kalan her şeyi reddeden allow list'ler öneriyor. Yazar, bunun olası tüm kötü girdileri kataloglamaktan daha kolay akıl yürütülebileceğini savunuyor. Tür ve aralık kontrolleri de önemli: bir pagination limiti kabul eden endpoint, değerin 1 ile 100 arasında bir tam sayı olduğunu doğrulamalıdır; böylece 999999999 isteyen bir istek sunucuda başarısız olur, yerine getirilmez.

Doğrulama tek bir katmandır, savunmanın tamamı değil

Yazı, sunucu tarafı doğrulamayı aşırı satmamaya da özen gösteriyor. Bu doğrulama; parametreli veritabanı sorgularının, çıktı kodlamasının (output encoding), kimlik doğrulamanın, yetkilendirmenin, güvenli dosya işlemenin, rate limiting'in ya da özenli hata yönetiminin yerini almaz. Yazarın veritabanı sorgusu örneğinde sorgu yine bağlı parametreler kullanmalıdır; çünkü SQL injection'a karşı gerçek savunma girdi doğrulaması değil, parametrelendirmedir. Güvenlik, yazının vardığı sonuç gibi, bağımsız katmanlardan oluşan bir yığın olarak en iyi şekilde çalışır.

Client-side kontroller yine de değerli

Bunların hiçbiri tarayıcı tarafındaki doğrulamayı işe yaramaz kılmıyor. Yazı, bunun kullanıcılara anında geri bildirim sağladığına dikkat çekiyor — sunucuya bir gidiş-dönüş yaşanmadan önce boş kullanıcı adını işaretlemek gibi — ve bu gerçek bir kullanılabilirlik kazanımıdır. Hata, bunun bir şeyi koruduğunu varsaymaktır; çünkü aynı JavaScript basitçe atlatılabilir. Yazarın özeti şu: tarayıcı kullanıcıların iyi veri göndermesine yardımcı olur, ancak verinin gerçekten kabul edilebilir olup olmadığına yalnızca sunucu karar verebilir.

Neden önemli

Bu tuzak sürekli yeniden karşımıza çıkıyor; çünkü başarısızlık normal kullanımda görünmezdir: testlerde doğru davranan bir form, güvenli bir formdan tamamen aynı görünür. Atlatma, yalnızca biri tarayıcıyı amaçlandığı şekilde kullanmayı bıraktığında ortaya çıkar ve o noktada sunucu geriye kalan tek savunma hattıdır. Web uygulaması veya API geliştiren ekipler için dev.to yazısından pratik çıkarım net bir iş bölümüdür — client-side doğrulama kullanıcı deneyimi için, sunucu tarafı doğrulama uygulama için vardır. Yalnızca JavaScript'te uygulanan her kural, bir saldırganın gözünde sadece bir öneriden ibarettir.