Web Uygulaması Güvenliği: Yazılım Firmanıza Sormanız Gereken 8 Soru

“Sistem güvenli mi?” diye sorduğunuzda hiçbir yazılım firması “hayır” demez. O yüzden bu, sorulabilecek en az işe yarar soru.

Daha iyi sonuç veren yol, firmanın güvenliği nasıl ele aldığını somut sorularla anlamak. Bunun için yazılım bilmeniz gerekmiyor; iyi bir cevabın neye benzediğini bilmeniz yetiyor. Aşağıdaki sekiz soruyu, web uygulaması güvenliğinde en çok başvurulan kaynaklardan biri olan OWASP Top 10 listesine dayanarak hazırladık. Çalışanların ve kullanıcıların alabileceği temel önlemleri siber saldırılara karşı korunma yazımızda anlatmıştık; burada işin yazılım tarafına bakıyoruz.

OWASP Top 10 neden sizi ilgilendiriyor?

OWASP, web uygulaması güvenliği üzerine çalışan, kâr amacı gütmeyen açık bir topluluk. Top 10 ise bu topluluğun, gerçek uygulamalarda en sık görülen ve en çok zarar veren açık türlerini kategoriler hâlinde derlediği liste. Birkaç yılda bir güncelleniyor; kategorilerin adı ve sırası sürümden sürüme değişebiliyor ama ana başlıklar büyük ölçüde yerinde duruyor.

Liste bir standart ya da sertifika değil. Yine de yazılım firmanız bu listeyi tanımıyorsa, bu size yeterince şey anlatır.

Biz OWASP önerilerini web yazılım projelerimizde geliştirme sürecinin bir parçası olarak ele alıyoruz. Aşağıdaki sorular, bu işi yaparken en çok üzerinde durduğumuz noktalar.

Soruların en iyi zamanı teklif aşaması. Proje bittikten sonra sorulduğunda cevap “bakarız” oluyor ve o bakış ek maliyet demek. Mevcut bir sisteminiz varsa da geç değil; bakım anlaşmasını yenilerken aynı listeyi kullanabilirsiniz.

Yazılım firmanıza sormanız gereken 8 soru

1. Bir kullanıcı başka birinin verisini görebilir mi?

Bu soru, OWASP listesinde en çok öne çıkan kategorilerden biri olan erişim kontrolü hatalarına karşılık geliyor. Tipik örnek şu: müşteri panelinde adres çubuğundaki fatura numarasını bir artırınca başka bir müşterinin faturası açılıyor. Ya da sıradan bir kullanıcı, yönetim sayfasının adresini tahmin edip içeri girebiliyor.

İyi bir cevapta şunu duymalısınız: yetki kontrolü her istekte sunucu tarafında yapılıyor ve testlerde farklı rollerle, başka kullanıcının kaydına ulaşmaya çalışılarak deneniyor. Menüden bir düğmeyi gizlemek yetki kontrolü değildir.

Sisteminizin bir de mobil uygulaması varsa bu soruyu ikinci kez sorun. Uygulamanın konuştuğu arka uç servisleri, ekranda hiç gösterilmeyen verileri de döndürüyor olabilir; telefonun ekranında görünmemesi, o verinin dışarıya gitmediği anlamına gelmez.

2. Kullanıcının yazdığı veriyi sisteme nasıl alıyorsunuz?

Enjeksiyon açıkları buradan doğar. Arama kutusuna ya da bir form alanına yazılan özel ifadeler veritabanına komut olarak ulaşabilir. Bir yorum alanına yazılan kod, o yorumu okuyan başka kullanıcının tarayıcısında çalışabilir.

Duymak istediğiniz kavramlar: parametreli sorgular ya da bunu kendiliğinden yapan bir ORM, ekrana basılan verinin güvenli biçimde kodlanması, dosya yüklemelerinde tür ve boyut kontrolü, yüklenen dosyaların çalıştırılamayacak bir yerde saklanması.

3. Giriş sistemini nasıl koruyorsunuz?

Kimlik doğrulama hataları hâlâ çok yaygın. Temel beklentiler belli: parolaların geri çevrilemez biçimde (hash ile) saklanması, art arda yanlış denemelere sınır konması, yönetici hesaplarında iki adımlı doğrulama, parola sıfırlama bağlantısının süreli ve tek kullanımlık olması, uzun süre işlem yapılmayan oturumların kapanması.

Kendi başınıza yapabileceğiniz basit bir kontrol var. “Parolamı unuttum” dediğinizde size mevcut parolanız gönderiliyorsa, parolalar okunabilir biçimde saklanıyor demektir. Bu tek başına ciddi bir işaret.

Müşterilerin kendi hesabıyla giriş yaptığı bir portalınız varsa bir riski daha hesaba katın. İnsanlar aynı parolayı pek çok yerde kullanıyor; başka sitelerden sızmış e-posta ve parola listeleriyle yapılan otomatik giriş denemeleri gerçek ve sık görülen bir saldırı biçimi. Deneme sınırı ve şüpheli girişlerde ek doğrulama bu yüzden var.

4. Hassas veriler nasıl saklanıyor ve taşınıyor?

OWASP'ın şifreleme hataları diye adlandırdığı kategori burada devreye giriyor. Sitenin her sayfası HTTPS ile açılmalı; T.C. kimlik numarası, sağlık bilgisi, banka bilgisi gibi alanlar veritabanında şifreli durmalı, yedekler de şifrelenmeli. Veritabanı parolası ya da ödeme servisinin anahtarı kaynak kodun içine yazılmamalı.

Ödeme alan sistemlerde en temiz yol, kart bilgisinin sizin sunucunuza hiç uğramaması; yani kartın ödeme kuruluşunun sayfasında ya da güvenli alanında girilmesi. Saklamadığınız veri çalınamaz.

Sık atlanan bir ek soru: test ortamında gerçek müşteri verisi kullanılıyor mu? Kullanılıyorsa o ortam da canlı sistem kadar korunmalı. Gördüğümüz sistemlerin çoğunda korunmuyor.

5. Hazır bileşenleri nasıl güncel tutuyorsunuz?

Bir web uygulaması, üzerine kurulduğu çatının yanında onlarca, bazen yüzlerce açık kaynak paket kullanır. Bunlardan birinde çıkan açık sizin uygulamanızın da açığıdır. Güncel olmayan ve açığı bilinen bileşenler, OWASP'ın ayrı bir kategori olarak izlediği riskler arasında. Hazır bir içerik yönetim sistemi üzerine kurulan sitelerde aynı durum eklentiler için geçerli: yıllardır güncellenmemiş tek bir eklenti, sitenin geri kalanı ne kadar sağlam olursa olsun içeri girilen kapı olabiliyor.

Beklenen cevap; bağımlılıkların otomatik taranması, düzenli bir güncelleme takvimi ve destek süresi biten sürümlerden zamanında çıkılmasıdır. Destek süresi biten bir çatı sürümüne güvenlik yaması gelmez. Bu yüzden .NET projelerinde uzun süreli destek (LTS) sürümlerini tercih ediyoruz; bugün için bu .NET 10.

Asıl soruyu ise çoğu kişi sormuyor: yayından sonra bu güncellemeleri kim yapacak? Bakım anlaşması olmadan teslim edilen bir sistem, birkaç yıl içinde eskimiş bileşenlerle dolu bir sisteme dönüşür.

6. Sunucu ve ayarlar kimin sorumluluğunda?

Yapılandırma hataları, kod ne kadar iyi olursa olsun kapıyı açık bırakır. Değiştirilmemiş varsayılan parolalar, internete açık bırakılmış veritabanı bağlantısı, herkesin ulaşabildiği yönetim paneli, hata sayfalarında görünen teknik ayrıntılar, unutulmuş bir test ortamı. Başka ekiplerden devralınan projelerde bunlara sık rastlanıyor.

Duymak istediğiniz önlemler de belli: sunucuda yalnızca gerekli bağlantı noktalarının açık olması, işletim sistemi güncellemelerinin düzenli yapılması, yönetim paneline yalnızca belirli adreslerden ya da VPN üzerinden girilebilmesi, canlı sistemde hata ayrıntılarının kullanıcıya gösterilmemesi.

Burada en önemli şey sorumluluğun yazılı olması. Barındırma firması mı, yazılım firması mı, sizin bilgi işlem ekibiniz mi? Sorumluluğun taraflar arasında kaldığı gri alan, açıkların en sık çıktığı yer.

7. Bir saldırı olursa bunu nereden ve ne zaman öğreniriz?

Loglama ve izleme eksikliği, açığın kendisi kadar zarar verir; çünkü saldırı fark edilmeden uzun süre devam edebilir. Başarısız giriş denemeleri, yetki hataları, yönetici işlemleri ve toplu veri indirmeleri kayıt altına alınmalı. Kayıtlar uygulamadan ayrı bir yerde, kolayca silinemeyecek biçimde tutulmalı; olağandışı bir durumda birine uyarı gitmeli. Parola ya da kart bilgisi gibi veriler ise kayıtlarda hiç yer almamalı.

Yanına bir soru daha ekleyin: saldırıdan sonra sistemi ne kadar sürede ve hangi tarihteki veriyle geri getirebiliriz? Cevap yedekleme düzenine bağlı; ayrı yerde duran ve düzenli olarak geri yüklenip denenen yedeğin neden gerektiğini yedekleme yazımızda anlattık. Kişisel veri içeren bir ihlalde KVKK kapsamındaki bildirim yükümlülükleri de gündeme gelir; süreleri ve adımları hukuk danışmanınızla önceden netleştirin.

8. Güvenlik tasarım aşamasında konuşuluyor mu?

Bazı açıklar kodda değil, iş kuralında olur. İndirim kodunun sınırsız kez kullanılabilmesi, sepete eksi adet girilince tutarın düşmesi, bir kullanıcının başkası adına randevu iptal edebilmesi. Otomatik tarama araçları bunları genellikle yakalamaz. Sistem teknik olarak “doğru” çalışıyordur; sadece yanlış bir şeye izin veriyordur.

İyi bir ekip analiz aşamasında her önemli özellik için “bu nasıl kötüye kullanılabilir?” diye sorar. Giriş, ödeme ve form gönderimi gibi akışlara hız sınırı koyar; kodun canlıya kimin, hangi onayla çıkarabildiğini de kontrol altında tutar. Önemli sistemlerde yayından önce ve büyük değişikliklerden sonra bağımsız bir sızma testi yaptırmak da bu sorunun parçası.

Yazılımın ve verinin bütünlüğüyle ilgili ayrı bir kategori de var. İşletme diline çevirince soru şu: canlıya çıkan kodun gerçekten ekibin yazıp onayladığı kod olduğundan, otomatik güncellemelerin ve dışarıdan alınan paketlerin güvenilir bir kaynaktan geldiğinden nasıl emin oluyorsunuz? Cevapta kod inceleme, otomatik derleme ve yayın süreci, canlı sunucuya elle dosya atılmaması gibi alışkanlıklar duymayı beklersiniz.

Listede bu sekiz soruyla doğrudan karşılamadığımız kategoriler de var; örneğin sunucunun dışarıdan verilen bir adrese istek göndermesiyle ilgili açıklar. Onlar teknik ekibinizin ya da bir güvenlik uzmanının gündeminde olmalı.

Sözleşmeyi imzalamadan önce

Görüşmelerden sonra şu maddelerin karşısına işaret koyabiliyor olmalısınız:

• Yetki kontrolünün sunucu tarafında yapıldığını ve farklı rollerle test edildiğini duydunuz.
• Parolaların nasıl saklandığı ve yönetici hesaplarında iki adımlı doğrulama olup olmayacağı belli.
• Yayın sonrası güvenlik güncellemelerini kimin, hangi sıklıkla yapacağı bakım anlaşmasında yazıyor.
• Sunucu, yedek ve log sorumluluğunun kimde olduğu yazılı.
• Kaynak kod ve sunucu erişim bilgileri size teslim edilecek.

Bu maddelerden birine net cevap alamıyorsanız imzayı bir hafta ertelemek, yıllarca bir açıkla yaşamaktan ucuzdur. Aynı soruları bize sorduğunuzda da cevapları yazılı istemenizi öneririz.