Web Uygulaması Sızma Testlerinde Sürekli Karşılaştığım Bug'lar

Müşteri değişir, bug sınıfları çoğu zaman değişmez. Yeterince web uygulaması projesi yaptıktan sonra, önümdeki uygulamaya özgü hiçbir şeye bakmadan önce varsayılan olarak kontrol ettiğim kısa bir liste oluşuyor. Hiçbiri özel bir teknik gerektirmiyor — üretime girmeye devam eden, sıkıcı ve tekrar eden şeyler bunlar.

Yanlış şeyi doğrulayan erişim kontrolü #

En sık rastladığım bulgu “auth kontrolü yok” değil, açık farkla. Sorun, giriş yaptığınızı doğrulayıp bu nesneye erişim yetkiniz olduğunu hiç sormayan bir kontrol — klasik IDOR. İstekteki ID’yi değiştirerek başka bir kullanıcının dosyalarını silebilen bir hesap. Sadece arayüzde gizlenmiş, API’de hiç korunmamış bir “taslak” ya da “yayınlanmamış” kayıt — direkt isteyin, orada duruyor.

Hemen arkasından: function-level authorization eksikleri geliyor. Admin’e özel bir endpoint — kayıt sıralamak, toplu işlem yapmak, internal yönetim ekranları — çağıranın rolüne hiç bakmıyor, sadece geçerli bir session’ı var mı diye kontrol ediyor. Frontend sıradan kullanıcıdan bir butonu saklıyorsa bu bir arayüz kararı, güvenlik önlemi değil. Kontrol sunucuda, her istekte olmalı — arayüzün ne göstermeyi seçtiğinde değil.

Yanlış sinyale bakan dosya yükleme kontrolü #

Dosya yüklemeyi destekleyen neredeyse her uygulama, extension’a ya da client’ın bildirdiği MIME type’a göre doğrulama yapıyor — ikisi de client’ın elinde, ikisini de sahtelemek çok kolay. Polyglot dosyalar (aynı zamanda geçerli bir SVG olan bir PNG, comment alanına payload gizlenmiş bir JPEG), dosyanın gerçek içeriğine değil bildirdiği tipe bakan content-type kontrollerinden rahatça geçiyor. Bir formatmış gibi görünüp aslında başka bir şey çalıştıran dosyalar — extension’ı değiştirilmiş bir çalıştırılabilir dosyanın “report.pdf” diye yüklenmesi gibi — benzer sıklıkta karşıma çıkıyor. Çözüm daha uzun bir extension yasak listesi değil; dosyanın gerçek içeriğini beklenen formata göre doğrulamak, ve storage’a giden ya da başka bir kullanıcıya geri gösterilen hiçbir şeyde client’ın söylediği tipe güvenmemek.

Tek başına önemsiz görünen enumeration #

URL’lerde sıralı ya da tahmin edilebilir ID’ler. “Şifre yanlış” ile “böyle bir kullanıcı yok” için farklı hata mesajı veren giriş/kayıt akışları. Tek başlarına önemli görünmüyorlar. Ama üst üste koyunca — geçerli kullanıcı adlarını bulup, sonra genelde rate limit ya da lockout olmadan bu listeye brute-force atmak — gerçek bir soruna dönüşüyor. Tek tek parçalar, hak ettiğinden daha sık “sadece bilgi sızıntısı, önemli değil” diye geçiştiriliyor.

Kimsenin bilerek bırakmadığı fazladan açık veri #

Arayüzün gösterdiğinden daha fazlasını taşıyan response’larda finansal ya da kişisel veri — API tüm objeyi dönüyor, frontend sadece bazı alanları göstermiyor, ama network trafiğine bakan herkes zaten hepsini görüyor. Kalması gerekmeyen bir yerde biten hassas veriler — bir cookie, bir URL, client tarafında bir log — çünkü geliştirirken en kolay yer orasıydı ve kimse geri dönüp düzeltmedi.

Asıl mesele #

Hiçbiri yeni bir teknik istemiyor. İstediği şey, sıkıcı soruları varsayılan olarak sormak: her nesneye erişim isteği, sadece oturumun geçerliliğine değil sahipliğe de mi bakıyor; admin’e özel her işlem rolü sunucuda mı kontrol ediyor; dosya doğrulaması extension’a değil içeriğe mi bakıyor; API’nin döndürdüğü, arayüzün göstermesi gerekenle mi sınırlı, yoksa backend’in elindeki her şey mi. Temiz çıkan projeler genelde bu dört soruyu bir pentest bulmadan önce sormuş olanlar.

Web uygulaması sızma testleri yapıyorum — erişim kontrolü, dosya işleme, auth ve yukarıda saydığım OWASP top 10’un geri kalanı. Çalıştırdığınız bir şeyde bu pattern’lerden tanıdık gelen varsa: [email protected].