- Konu sahibi
- #1
Hata mesajlarında hangi bilgiler açıklanmamalıdır?
Kullanıcıya gösterilen hata mesajlarında sunucunun dosya yolları, yazılım sürümleri, veritabanı sorguları, stack trace ayrıntıları, dahili IP ve host adları, oturum veya hesap bilgileri, erişim belirteçleri ve yapılandırma sırları açıklanmamalıdır. Dışarıya yalnızca sorunun oluştuğunu anlatan, sonraki adımı belirten ve gerekiyorsa destek ekibinin olayı bulmasını sağlayan rastgele bir hata kimliği gösterilmelidir. Sır içermeyen gerekli teknik ayrıntılar erişim kontrollü uygulama loglarına yazılabilir; ham istisna nesnesi de sır taşıyabileceğinden kayıttan önce filtrelenmelidir.
Hata mesajı nasıl ayrıştırılmalıdır?
Bir hata için iki ayrı çıktı düşünün: kullanıcının tarayıcıda gördüğü güvenli mesaj ve yetkili ekiplerin incelediği ayrıntılı kayıt. Kullanıcı mesajı sorunu teşhis ettirecek kadar açıklayıcı, saldırgana sistem hakkında keşif yaptırmayacak kadar sınırlı olmalıdır.
Kurgu bir örnekte dışarıya şu mesaj uygun değildir: “MySQL bağlantısı 10.0.0.12 üzerindeki db-prod sunucusunda başarısız oldu; /var/www/magaza/config/database.php dosyasındaki kullanıcı adıyla bağlantı kurulamadı.” Bu metin dahili ağ adresini, sunucu rolünü, dosya sistemini ve yapılandırma konumunu açığa çıkarır.
Bunun yerine “İşlem şu anda tamamlanamadı. Lütfen tekrar deneyin. Sorun devam ederse destek ekibine HATA-7F3K kodunu iletin.” denebilir. Log kaydında ise zaman, istek kimliği, istisna türü, çağrı zinciri ve ilgili teknik bağlam erişim kontrollü biçimde tutulur.
Özellikle gizlenmesi gereken bilgiler
| Bilgi türü | Neden risklidir? | Kullanıcıya gösterilecek yaklaşım |
|---|---|---|
| Stack trace ve kaynak kodu satırları | Dosya yapısını, sınıf adlarını ve kullanılan bileşenleri açığa çıkarabilir. | Genel hata açıklaması ve hata kimliği verin. |
| SQL sorgusu ve veritabanı hatası | Tablo, sütun, sorgu mantığı veya veri yapısı hakkında ipucu verebilir. | “Veri işlemi tamamlanamadı” gibi sınırlı mesaj kullanın. |
| Sürüm, işletim sistemi ve sunucu bilgisi | Eski veya bilinen zafiyetleri hedeflemeyi kolaylaştırabilir. | Ürün ve sürüm ayrıntılarını dış yanıta koymayın. |
| Parola, token, cookie ve bağlantı bilgileri | Doğrudan hesap veya sistem erişimine yol açabilir. | Mesajda ve loglarda maskelenmiş değer kullanın; sırrı hiç kaydetmemek daha iyidir. |
Tablodaki son satır özellikle önemlidir: Bir sırrın yalnızca hata mesajından gizlenmesi yeterli değildir. Uygulama loglama, izleme veya hata takip sistemine yazarken de parola, erişim belirteci, cookie, ödeme verisi ve kişisel veriler filtrelenmelidir.
Uygulanabilir hata mesajı düzeni
- Kullanıcıya görünen metni tek başına değerlendirin. Mesaj, işlemin başarısız olduğunu ve kullanıcının beklemesi, tekrar denemesi veya destekle iletişime geçmesi gerekip gerekmediğini anlatsın.
- Stack trace, SQL, dosya yolu, dahili IP, host adı, ortam adı, framework bilgisi ve sürüm bilgisini dış yanıttan çıkarın.
- Her olayı loglarda aramak için tahmin edilmesi zor bir hata veya istek kimliği üretin. Bu kimlik tek başına yetki vermemeli ve gizli veri içermemelidir.
- Ayrıntılı kaydı yalnızca yetkili yöneticilerin erişebildiği kanala yazın. Kullanıcı girdilerini loglarken sırları ve gereksiz kişisel verileri maskeleyin.
- Üretim ortamında ayrıntılı hata gösterimini kapatın. Geliştirme ortamında bile gerçek parola, token veya canlı kullanıcı verisiyle test yapmayın.
- Hatalı ve başarılı akışları kontrol edin. İstemciye dönen HTTP durum kodu ve mesaj, gerçek durumu yansıtmalı; her hatayı başarılı yanıt gibi göstermemelidir.
Sonucun yorumlanması
Mesaj yalnızca “Bir hata oluştu” diyorsa kullanıcı ne yapacağını anlayamaz; bu da tekrar denemeleri ve destek taleplerini artırabilir. “Dosya bulunamadı” gibi fazla ayrıntılı bir mesaj yerine “İstenen içerik bulunamadı” demek, hem kullanıcıya yön verir hem de sunucudaki gerçek dosya yapısını saklar. Kimlik doğrulama hatalarında da hesabın mevcut olup olmadığını açığa çıkaran farklı mesajlar yerine, saldırganın hesapları tahmin etmesini zorlaştıran tutarlı yanıtlar tercih edilmelidir.
Bir hata koduyla birlikte destek ekibine aktarılacak zaman aralığı veya işlem adı verilebilir; ancak bu bilgiler sunucunun iç mimarisini, kullanıcı sırrını veya güvenlik politikasını açığa çıkarmamalıdır. Sorun düzeltildikten sonra aynı hata kimliğinin eski loglarda bulunup bulunmadığını ve hassas bilgilerin dışarı sızıp sızmadığını da kontrol edin.
Sık sorulan sorular
Ayrıntılı hata mesajı yalnızca yönetici oturumunda gösterilebilir mi?
Gerekliyse yöneticiye özel ve yetkilendirilmiş bir tanılama ekranı kullanılabilir; ancak bu ekran da parola, token ve benzeri sırları göstermemeli, erişim denetimi ve kayıt altına alma ile korunmalıdır.
