Web Uygulama Güvenliği: Sahada En Sık Görülen 7 Açık

Web uygulama güvenliği denince akla karmaşık saldırı teknikleri gelir. Oysa sahada karşılaşılan olayların büyük bölümü temel hatalardan doğar: unutulmuş bir yetki kontrolü, birleştirilerek yazılmış bir SQL sorgusu, kaçışlanmamış bir çıktı. Bu yazıda en sık görülen yedi açığı, nasıl oluştuklarını ve kalıcı çözümlerini ele alıyoruz.

1. Yetki kontrolü eksikliği (IDOR)

En yaygın ve en kolay istismar edilen açıktır. Kullanıcı /faturalar/1042 adresini görür, numarayı 1041 yapar ve başkasının faturasını okur. Kod, kaydı bulmuştur ama "bu kayıt bu kullanıcıya mı ait" sorusunu sormamıştır.

Çözüm tek cümledir: her kayıt erişiminde sahiplik veya kapsam kontrolü sunucuda yapılmalıdır. Kontrolü ekranda düğmeyi gizleyerek yapmak koruma değildir; kullanıcı adresi doğrudan yazabilir. Yetki kontrolünü tek bir politika sınıfında toplamak, her ekranda tekrar yazmaktan çok daha güvenlidir.

2. SQL enjeksiyonu

Kullanıcıdan gelen veri sorguya doğrudan eklendiğinde ortaya çıkar. Sonucu, veritabanının tamamının okunmasına kadar gidebilir. Çözüm bilinir ve kesindir: parametreli sorgular veya sorgu oluşturucu kullanmak, kullanıcı verisini asla sorgu metnine birleştirmemek.

Dikkat edilmesi gereken ince nokta, sıralama ve tablo adı gibi parametre olarak bağlanamayan alanlardır. Buralarda beyaz liste kullanılmalıdır: gelen değer, izin verilen sütun adları listesinde yoksa reddedilmelidir.

3. XSS (siteler arası betik çalıştırma)

Kullanıcının girdiği metin, kaçışlanmadan sayfaya basıldığında oluşur. Saldırgan bir yorum alanına betik yazar; o sayfayı açan her kullanıcının tarayıcısında bu kod çalışır ve oturum bilgileri çalınabilir.

Kural: çıktı, basıldığı bağlama göre kaçışlanmalıdır. HTML gövdesi, HTML özniteliği, JavaScript ve URL bağlamlarının kuralları farklıdır. Zengin metin girişine izin veriliyorsa, izin verilen etiketler beyaz listeyle sınırlandırılmalıdır. İçerik güvenlik politikası (CSP) başlığı ise ikinci savunma hattı olarak eklenmelidir.

4. Zayıf oturum ve parola yönetimi

• Parolalar bcrypt veya Argon2 ile saklanmalı; özel şema yazılmamalıdır.
• Giriş denemelerine hız sınırı konulmalı, art arda başarısız denemeler yavaşlatılmalıdır.
• Parola değiştiğinde mevcut oturumlar sonlandırılmalıdır.
• Oturum çerezleri HttpOnly, Secure ve uygun SameSite ayarlarıyla verilmelidir.
• Yetkili hesaplarda iki adımlı doğrulama sunulmalıdır.

5. Dosya yükleme açıkları

Dosya yükleme, en çok hata yapılan alanlardan biridir. İstemciden gelen dosya adına ve MIME bilgisine güvenilmemelidir; ikisi de kolayca değiştirilebilir. Güvenli akış şudur: uzantıyı beyaz listeyle sınırla, dosya içeriğini gerçekten doğrula, dosya adını sunucuda yeniden üret, yüklenen dosyaları çalıştırılamayan bir dizinde sakla ve boyut sınırı koy.

Görseller için ek bir önlem, yeniden boyutlandırma işleminden geçirmektir; bu işlem gömülü zararlı içeriği de temizler.

6. Güvenlik açığı olan bağımlılıklar

Modern uygulamaların kodunun büyük bölümü üçüncü parti kütüphanelerden gelir. Bu kütüphanelerde çıkan açıklar, sizin kodunuz kusursuz olsa bile sizi etkiler. Bağımlılık taramasını otomatik hâle getirin ve güncellemeleri düzenli bir bakım işine dönüştürün. Yıllardır güncellenmemiş bir projede yükseltme, tek seferde yapılamayacak kadar büyür.

7. Bilgi sızdıran hata mesajları ve açıkta kalan dosyalar

Canlı ortamda ayrıntılı hata ekranı göstermek, veritabanı yapısını ve dosya yollarını saldırgana sunar. Aynı şekilde yapılandırma dosyaları, yedekler ve sürüm kontrol klasörleri web üzerinden erişilebilir olmamalıdır. Bunu test etmek için adresleri doğrudan tarayıcıya yazmak yeterlidir; sonuç çoğu zaman şaşırtıcıdır.

Savunmayı sıraya koymak

Sınırlı zamanla çalışıyorsanız öncelik sırası şudur: önce yetki kontrolleri, sonra veri tabanı ve çıktı güvenliği, sonra oturum yönetimi, en sonda ileri düzey sertleştirmeler. Kapsamlı ve güncel bir çerçeve için OWASP Top 10 listesi başlangıç noktası olmalıdır.

Güvenliği geliştirme sürecine gömmek

Güvenlik, yayından önce yapılan tek seferlik bir denetim olarak ele alındığında pahalıya patlar. Bulunan her açık, kodun tekrar yazılması demektir. Bunun yerine süreç içine yerleştirilmiş küçük kontroller çok daha ucuzdur.

Uygulanabilir dört adım vardır. Birincisi, kod incelemesine kısa bir güvenlik sorusu eklemek: bu değişiklik yeni bir veri erişim noktası açıyor mu, açıyorsa yetki kontrolü nerede? İkincisi, bağımlılık taramasını otomatik hatta dahil etmek. Üçüncüsü, yeni her uç nokta için yetkisiz erişim denemesi testi yazmak; bu testler hem açığı yakalar hem de belge işlevi görür. Dördüncüsü, hassas işlemleri (yetki değişikliği, toplu veri dışa aktarma, parola sıfırlama) ayrı bir denetim kaydında toplamak.

Saldırıyı görebilmek

Güvenlik yalnızca önleme değil, fark etme meselesidir. Başarısız giriş denemeleri, yetkisiz erişim girişimleri, olağandışı veri indirme hacimleri kayıt altına alınmalı ve belirli eşiklerde uyarı üretmelidir. Bir ihlali aylar sonra öğrenmek ile aynı gün öğrenmek arasındaki fark, çoğunlukla bu kayıtlarla belirlenir.

Sonuç

Güvenlik, projenin sonuna eklenen bir kontrol listesi değil, her istekte uygulanan bir alışkanlıktır. Yetkiyi sunucuda kontrol edin, veriyi parametreyle taşıyın, çıktıyı kaçışlayın, bağımlılıkları güncel tutun ve olan biteni kayıt altına alın. Bu beş alışkanlık, gerçek dünyadaki olayların büyük çoğunluğunu baştan engeller.