Güvenlik yanlış yapılandırması ve eski bileşenler

Güvenlik yanlış yapılandırması, doğru yazılmış bir uygulamanın yanlış ayarlanmasıdır. Kod hatasız olabilir, sorun kurulum ve dağıtım adımındadır. Yaygın örnekler bellidir. Kurulumda gelen varsayılan kullanıcı adı ve parola değiştirilmeden kalır.

Hata sayfaları yığın izini doğrudan kullanıcıya gösterir. İhtiyaç duyulmayan bir yönetim paneli internete açık durur. Bulut depolama herkese açık izinle bırakılır. OWASP bu sınıfı 2025 listesinde beşinci sıradan ikinciye taşıdı, çünkü test edilen uygulamaların tamamında bir tür yanlış yapılandırma bulundu.

Ortak nokta, güvenli bir varsayılan yerine gevşek bir ayarın seçilmesidir. Tek bir açık uç, altındaki sağlam kodu anlamsız kılar. Bu hatalar genelde kod incelemesinde değil, dağıtım kontrol listesinde yakalanır; çünkü kodun kendisi hiç değişmemiştir, değişen yalnız bir ayardır. Bu yüzden savunma da koda değil, kuruluş ve dağıtım adımına bakar.

Yanlış yapılandırma, ayarın gevşek bırakılmasıdır; kodun kendisi değişmez. Varsayılan parola, açık panel ve ayrıntılı hata hep aynı kökten gelir. Bir de komşu bir risk var: zafiyetli ve eski bileşenler. Uygulama, içindeki bir kütüphanenin yalnız sürümünü değil, o kütüphanenin bilinen açıklarını da miras alır.

Bir kütüphanede CVE numarasıyla yayımlanan bir açık, onu kullanan her uygulamayı etkiler. Ekip bunu fark etmeyebilir, çünkü açık kendi kodunda değil, kullandığı bir pakettedir. İki risk komşudur ama kaynakları ayrıdır: biri ayarın gevşekliğinden, öbürü paketin eskiliğinden doğar.

Eski bileşen riskinin ölçeği de farklıdır. Node.js, Python ve Java'nın paket ekosistemlerinde bir uygulama çoğu zaman yüzlerce dolaylı bağımlılık taşır; hiçbirini elle takip etmek olanaklı değildir. Yazılım bileşen listesi, yani SBOM, bu bağımlılıkları tek bir dosyada döker ve hangi sürümün üretimde çalıştığını görünür kılar.

Sürümü eski kalan bir bileşen çoğu zaman kasıtlı bir ihmal değildir; kimse o bağımlılığın sahibini üstlenmemiştir. Bir açık yayımlandığında, listeyi tutan ekip hangi ürünün etkilendiğini dakikalar içinde görür. Liste yoksa, aynı soru günler alır ve zafiyet o günler boyunca yamasız kalır.

İki riski ayrı tutmak savunmayı da ayırır. Yanlış yapılandırmayı bir kontrol listesi ve otomatik denetim kapatır: her ortam aynı sıkı varsayılanla kurulur, varsayılan hesaplar silinir, gereksiz paneller kapatılır. Eski bileşen riskini ise sürüm takibi ve tarama kapatır: hangi paketin hangi sürümde olduğunu bilir, bilinen bir açık içeren sürümleri değiştirirsin.

Bir e-ticaret ortamında bu iki disiplin birlikte yürür. Bir yanda altyapı ekibi varsayılanları sıkılaştırır, öbür yanda geliştirici ekibi bağımlılıkları güncel tutar. Birini ihmal etmek öbürünü de anlamsızlaştırır, çünkü saldırgan hangi kapı açıksa oradan girer.

Hata yönetimi de yapılandırmanın bir parçasıdır. Geliştirme ortamında ayrıntılı hata mesajı hata ayıklamayı kolaylaştırır. Aynı ayar üretimde kalırsa, yığın izi çerçeve sürümünü, dosya yolunu ve bazen sorgu metnini karşı tarafa taşır.

Saldırgan bu bilgiyle hangi bilinen açığı deneyeceğine karar verir. Yani ayrıntılı hata, saldırgana bir harita verir. Üretimde doğru davranış, kullanıcıya kısa ve kimlik vermeyen bir hata göstermek, ayrıntıyı yalnız sunucu kaydına yazmaktır. Aşağıdaki ayar dosyası, geliştirme için uygun ama üretime hiç çıkmaması gereken bir örnektir.

DEBUG = True
ALLOWED_HOSTS = ["*"]
SECRET_KEY = "degistir-beni"

Üç satırı da oku. DEBUG değeri açıkken, bir hata oluştuğunda çerçeve ayrıntılı bir sayfa döker: kod parçaları, yerel değişkenler, kullanılan kütüphaneler. Bu bilgi üretimde saldırgana gider.

ALLOWED_HOSTS değerinin yıldız olması, uygulamanın her ana makine adını kabul etmesi demektir; oysa üretimde yalnız kendi alan adların kabul edilmelidir. SECRET_KEY ise kodun içinde sabit yazılmış ve tahmin edilebilir; gizli anahtar bir ortam değişkeninden ya da ayrı bir dosyadan okunmalıdır. Bu ayar dosyası Django biçimindedir ve çerçevenin kendi dağıtım denetimi bu hataların bir kısmını yayından önce yakalar.

$ python manage.py check --deploy
System check identified some issues:

WARNINGS:
?: (security.W009) Your SECRET_KEY has less than 50 characters, less than 5 unique characters, or it's prefixed with 'django-insecure-' ...
?: (security.W018) You should not have DEBUG set to True in deployment.
...

Çıktıyı oku. W009 uyarısı, gizli anahtarın elli karakterden kısa ya da tahmin edilebilir olduğunu söyler; anahtar oturum ve imza işlerinde kullanıldığı için bu ciddi bir açıktır. W018 uyarısı, DEBUG değerinin üretimde açık kaldığını bildirir.

Dikkat et: ALLOWED_HOSTS için yalnız listenin boş olup olmadığı denetlenir, yıldız bu denetimden geçer. Yani araç her hatayı yakalamaz, kontrol listesi yine gerekir. Aynı listeye varsayılan yönetici hesabını silmek, kullanılmayan paneli kapatmak ve sunucuda dizin listelemeyi kapatmak da girer. Dizin listeleme açıksa, bir klasöre giden adres içindeki bütün dosyaları sıralar ve yedek ya da ayar dosyalarını ortaya döker.

Sırların sızması çoğu zaman loglarda da olur. Bir ödeme ya da sipariş ucu, hata ayıklama sırasında isteğin tamamını loga yazarsa, API anahtarı gibi bir değer düz metin olarak kayda düşer. Loglar uygulamadan daha uzun saklanır ve daha çok kişi okur, bu yüzden logdaki bir anahtar kalıcı bir risktir.

Tespitin bir yolu, log satırlarını düzenli olarak tarayıp anahtar biçimine uyan dizeleri yakalamaktır. Gerçek bir anahtar uzun ve rastgele görünür; kısa, elle yazılmış bir değer çoğu zaman gerçek bir sızıntı değildir. Bir sonraki alıştırma bu ayrımı yapan bir desen kurmanı ister.

Güvenlik başlıkları da yapılandırmanın bir parçasıdır. Bir başlık kodu değiştirmez, yalnız tarayıcıya ek bir kural bırakır. Strict-Transport-Security, bağlantıyı yalnız HTTPS üstünden kurmaya zorlar.

X-Content-Type-Options nosniff değeriyle, tarayıcının içerik türünü tahmin etmesini kapatır. Content-Security-Policy, sayfanın hangi kaynakları yükleyebileceğini ve hangi kökenlerce çerçeveye alınabileceğini belirler; frame-ancestors kuralı tıklama hırsızlığını doğrudan durdurur. Referrer-Policy, başka sayfalara ne kadar başvuru bilgisi gittiğini sınırlar.

Permissions-Policy, kameraya ya da konuma erişimi kapatır. Eksik bir başlık, bu kuralı hiç yazdırmaz ve tarayıcı korumayı kendiliğinden eklemez. Başlıklar ucuz bir savunmadır: kodu değiştirmeden, tek bir yapılandırma satırıyla eklenir ve pek çok saldırının işini zorlaştırır.

$ curl -sI https://portal.example/
HTTP/2 200
server: nginx/1.18.0
x-powered-by: Express
content-type: text/html; charset=utf-8

Çıktıyı oku. Durum satırının altında yalnız üç başlık var ve güvenlik başlıklarının çoğu eksik. HSTS yok, yani bir kullanıcı HTTP ile girerse bağlantı şifresiz başlar. Content-Security-Policy yok, yani sayfaya hangi betiğin yükleneceğine dair bir sınır konmamış.

X-Content-Type-Options yok, yani tarayıcı içerik türünü tahmin edebilir. Üstüne, server ve x-powered-by başlıkları çalışan yazılımın adını ve sürümünü dışarı veriyor; bu bilgi saldırgana hangi açığı deneyeceğini söyler. Doğru yapılandırma eksik başlıkları ekler ve bu iki sürüm sızdıran başlığı kaldırır. Artık kullanımdan kalkan X-XSS-Protection başlığını ise ya hiç gönderme ya da sıfır değeriyle gönder.

Eski bileşen riski elle takip edilemeyecek kadar büyür, bu yüzden yazılım bileşim analizi araçları devreye girer. Bu araçlar bağımlılık listesini bilinen açık veritabanlarıyla karşılaştırır ve etkilenen sürümü işaretler. Tarama yapı hattına eklenirse, açıklı bir sürüm üretime çıkmadan durdurulur. OSV-Scanner, OWASP Dependency-Check ve Trivy gibi araçlar bu işi yapar.

Yama her zaman hemen uygulanamaz; o zaman geçici bir azaltım ve yama takvimini izlemek gerekir. Sürüm sabitlemeden körü körüne en yeni sürüme atlamak da risklidir, çünkü yeni sürüm test edilmemiş davranış getirebilir. Taramayı yalnız yayın öncesi değil düzenli aralıklarla tekrarlamak gerekir.

Hangi açığı önce kapatacağına da karar vermen gerekir, çünkü aynı anda onlarca uyarı gelebilir. Tek başına bir CVE numarası ya da bir puan, aciliyeti tam anlatmaz. Bir açığın gerçekte sömürülüp sömürülmediği daha güçlü bir ölçüttür. CISA'nın bilinen sömürülen açıklar kataloğu, saldırganların fiilen kullandığı açıkları listeler.

Senin bir bileşenin bu listede görünüyorsa, o açık teorik değildir ve önce o kapatılır. Böylece sınırlı zamanı en çok iş gören yere ayırır, panik yerine önceliğe göre ilerlersin. Yüksek puanlı ama kimsenin denemediği bir açık, düşük puanlı ama aktif sömürülen bir açıktan sonra gelebilir.

Tarama çıktısını okumak da bir beceridir. Araç her satırda etkilenen paketi, kullandığın sürümü, açığın numarasını ve varsa düzeltilmiş sürümü verir. İlk bakılacak şey, açığın gerçekten ulaşılabilir bir yolda olup olmadığıdır. Bir paket bağımlılık ağacında dursa da hiç çağrılmıyorsa, aciliyeti daha düşüktür.

Düzeltilmiş sürüm varsa, yükseltmeyi küçük bir sürüm atlamasıyla yapıp testleri çalıştırırsın. Düzeltme yoksa, etkilenen özelliği kapatmak ya da erişimi daraltmak geçici bir çözümdür. Bu okumayı disiplinli yapan ekip, uzun uyarı listesini birkaç gerçek işe indirir ve zamanını boşa harcamaz.

Bulut ortamında yanlış yapılandırma başka bir yüze bürünür. Herkese açık bırakılan bir depolama kovası, dosya adını bilen herkese içeriği açar. Kovanın kendisi ele geçirilmez, yalnız izin ayarı unutulur. Kova adını bir arama motoru dizinlemişse, saldırgan hiçbir tarama aracı çalıştırmadan içeriğe ulaşır.

Burada teknik bir beceri bile gerekmez; iznin kendisi kapıyı açık bırakmıştır. Doğru varsayılan, bir kovayı açıkça gerekmedikçe kapalı tutmaktır. Erişim, yalnız ihtiyacı olan kimliklere ve yalnız gereken dosyalara verilir.

Bir de düzenli bir denetim, yanlışlıkla açık kalan kovaları yakalar. Aynı mantık veritabanı, kuyruk ve yönetim arayüzü için de geçerlidir: dışarıya açık olması gereken şey azdır, gerisi kapalı başlamalıdır. Açık uç listesini kısa tutmak, saldırı yüzeyini en çok küçülten adımdır. Dışarıya açık her kapı, ayrıca sıkılaştırılması ve izlenmesi gereken bir yüktür; kapalı bir kapı ise hiç yük getirmez.