Bir dosyanın yüklenebilmesiyle sonradan kim tarafından indirilebileceği aynı özelliğin iki yarısı. Yalnız uzantıyı kontrol edip dosyayı genel bir klasöre koyarsam yükleme ekranındaki yetkiyi indirme sırasında kaybetmiş olabilirim. Dosya paylaşımı örneklerinde önce kabul edilen içerik ile erişim sözleşmesini birlikte tanımlarım.
Dosya adı, içerik türü ve byte içeriği
Kullanıcının gönderdiği ad açıklayıcı bir etikettir; depolama yolu veya güvenilir tür bilgisi değildir. .png uzantısı ve image/png Content-Type başlığı da istemciden gelir. Bağımsız .NET 10 konsol örneğinde bu yüzden PNG imzasını byte düzeyinde kontrol ediyor ve saklama adı için GUID üretiyorum.
static bool LooksLikePng(byte[] bytes) => bytes.Length >= 8 &&
bytes.AsSpan(0,8).SequenceEqual(new byte[]{137,80,78,71,13,10,26,10});
var header = new byte[]{137,80,78,71,13,10,26,10};
var storedName = Guid.NewGuid().ToString("N") + ".png";
var ownerId = 7; var callerId = 9;
Console.WriteLine(LooksLikePng(header));
Console.WriteLine(ownerId == callerId ? storedName : "forbidden");Örneğin iki çıktısı True ve forbidden. Burada bilerek yalnız sekiz byte içeren bir başlık kullanıldı. İmzanın eşleşmesi, dosyanın geçerli ve tamamen çözülebilir bir PNG olduğunu kanıtlamaz. Bu nokta önemli: LooksLikePng bir ön eleme yardımcısıdır; tek başına güvenli yükleme servisi değildir. Gerçek görsel işleme akışında geçerli yapı, boyut ve çözme sınırları da gerekir.
İsteği kabul ederken sınır koymak
İzin verilen türleri allowlist ile belirlerim. Uzantı ve imza birlikte değerlendirilebilir, fakat dosya boyutu sınırı da yalnız tarayıcıda kalmamalı. HTTP sunucusu ve uygulama katmanı bunu kontrol etmeli; stream okunurken de kabul edilebilir üst sınır korunmalı. Küçük sıkıştırılmış bir dosyanın çok büyük piksel alanına açılması gibi durumlarda byte sınırı tek başına yeterli değildir.
Dosyanın saklama adını uygulama üretir; özgün ad metadata olarak kalır. Son hedef yolun izin verilen depolama kökü içinde kaldığını doğrularım. Kullanıcıdan gelen klasör veya tam yolu doğrudan kullanmam. Aynı ada sahip iki dosyanın çakışması ile aynı içeriğin tekrar yüklenmesi ise farklı sorunlar: GUID ad çakışmasını azaltır, mükerrer iş kaydını çözmez.
İndirmede yeniden yetkilendirmek
Konsoldaki ownerId == callerId kontrolü yalnız bir yetki fikrini gösteriyor. Gerçek uç, callerId değerini formdan değil doğrulanmış oturumdan almalı; dosya sahibini de güvenilir kayıttan okumalıdır. Grup, paylaşım veya rol kuralları varsa bunları aynı karar noktasında uygularım. İstek sahibi dosyanın kimliğini bilse bile erişim hakkı tekrar kontrol edilir.
Özel belgeyi genel statik dosya dizinine koyup sonradan gizli bağlantı saymak bu kontrolü atlatır. Yetkili indirme endpoint'i dosyayı kontrollü şekilde açıp uygun Content-Type ve Content-Disposition ile sunabilir. Kullanıcının dosya adındaki özel karakterlerin yanıt başlığını bozmamasını da framework'ün güvenli dosya yanıtı üzerinden ele alırım.
Dosya ile veritabanı kaydı aynı anda oluşmayabilir
Diske yazma başarılı, metadata kaydı başarısız olabilir. Bunun tersi de mümkündür. Dosya sistemi yazmasının SQL transaction'ına kendiliğinden katıldığını varsaymam. Geçici kayıt ve tamamlandı durumu, başarısız yazmayı telafi eden silme veya sahipsiz dosya temizliği gibi açık bir yaşam döngüsü seçerim. Temizleme yordamı da hâlâ kullanılan dosyayı yanlışlıkla silmemeli.
İşlem iptal edilirse yarım dosya başarılı kayıt gibi görünmemeli. İlerleme yüzdesi dosyanın kalıcı hale geldiği anlamına gelmez; “yükleniyor”, “işleniyor” ve “hazır” farklı durumlardır. Kullanıcıya bunları gereksiz teknik ayrıntıya boğmadan doğru göstermek mümkündür.
Testi yalnız doğru uzantıyla sınırlamamak
Geçerli dosya, sahte uzantı, yalnız PNG başlığı, aşırı boyut ve yarıda kesilen yüklemeyi ayrı denerim. İndirmede dosya sahibi, yetkili paylaşım ve başka kullanıcı senaryolarını kontrol ederim. Silinmiş kayıtla kalan dosyanın URL'si de denemeye dahildir. Bu örneklerde gerçek kullanıcı belgesi yerine küçük test dosyaları yeterlidir.
ASP.NET Core dosya yükleme sınırları; Kaynak bazlı yetkilendirme.