Bir panelde en zararsız görünen alan hangisidir? Çoğu kişi "görsel yükleme" der. Ürün kapağı, bayi logosu, destek talebine eklenen ekran görüntüsü, fatura dekontu. Hepsi rutin, hepsi günlük iş. Oysa güvenlik tarafında bakıldığında bu alan panelin en tehlikeli yeri; çünkü orada kullanıcı sana bir metin değil, doğrudan dosya sistemine yazılacak veri gönderiyor. Enjeksiyon açığında saldırgan veritabanına soru soruyor; dosya yükleme açığında sunucuya komut bırakıyor.
Bu farkı anlamak önemli, çünkü tek bir başarılı yükleme, diğer tüm güvenlik önlemlerini anlamsız kılar. Sunucu üzerinde çalışabilen bir dosya bıraktıysa saldırganın artık veritabanı bağlantı bilgilerine, ödeme sağlayıcı anahtarlarına, satılmamış kodlara ve yedeklere erişimi var. Bu yazıda bir e-pin scriptinde yükleme alanlarının nasıl istismar edildiğini, hangi kontrollerin gerçekten koruduğunu, hangilerinin sadece rahatlama sağladığını ve kendi panelinde ne sınamalısın sorusunun cevabını anlatacağım.
Uzantı kontrolü niçin gerçek bir savunma değil?
Klasik yaklaşım, dosya adının sonuna bakmaktır. "Sadece jpg, png, webp kabul ediyorum" denir ve konu kapanır sanılır. Ne var ki dosya adı tamamen kullanıcının kontrolünde. Adın içine birden fazla uzantı yerleştirmek, sonuna görünmez karakter veya boşluk eklemek, büyük küçük harf oynamak ya da sunucunun yapılandırmasındaki çoklu uzantı davranışından yararlanmak mümkün. Sunucu bazı yapılandırmalarda dosyayı ortadaki uzantıya göre yorumlayabiliyor; bu durumda "resim" sandığın dosya çalıştırılabilir hâle geliyor.
İkinci sık yanılgı MIME türüne güvenmek. Tarayıcının gönderdiği içerik türü başlığı da istemci tarafından belirlenir; isteyen istediği değeri yazar. Üçüncü yanılgı ise dosyanın ilk baytlarına bakıp geçmek. Doğru bir adım ama tek başına yeterli değil, çünkü geçerli bir görsel başlığının ardına kod eklenmiş dosyalar üretilebiliyor. Bu üç kontrol birlikte faydalıdır; ancak hiçbiri, asıl savunma olan çalıştırma yasağının yerini tutmaz. Sağlam bir dijital ürün satış scriptinde mantık şudur: yüklenen dosya ne olursa olsun, bulunduğu yerde çalıştırılamaz.
Asıl savunma nerede duruyor: depolama konumu
Yükleme güvenliğinin kalbi, dosyanın nereye yazıldığıdır. Eğer yüklenen dosyalar web kökünün içinde, tarayıcıdan doğrudan erişilebilen bir dizinde duruyorsa, savunman tamamen içerik kontrollerine bağlı kalır ve bu kontrollerin her biri atlatılabilir. Doğru kurulum, yükleme dizinini web kökünün dışına almak ve dosyaları bir aracı betik üzerinden, yetki kontrolünden geçirerek servis etmektir. Böylece saldırgan yüklediği dosyanın adresine gitse bile onu çalıştıramaz; en fazla indirmiş olur.
Bunu tamamlayan ikinci karar, dosya adını kullanıcıdan almamak. Sunucu tarafında rastgele bir kimlik üretip dosyayı o adla saklamalı, gerçek adı ise yalnızca veritabanında bir etiket olarak tutmalısın. Bu tek değişiklik, dizin geçişi denemelerini, çift uzantı oyunlarını ve üzerine yazma saldırılarını aynı anda ortadan kaldırır. Üçüncü karar ise sunucu düzeyinde o dizinde yorumlayıcıyı kapatmak. Modern bir e-pin satış yazılımı kurulumunda bu üç maddenin varsayılan olarak yapılandırılmış gelmesi beklenir; sonradan eklemek her zaman daha pahalı ve daha eksik olur.
| Kontrol yöntemi | Atlatılabilirlik | Tek başına yeterli mi | Uygulama zorluğu | Rolü |
|---|---|---|---|---|
| Uzantı beyaz listesi | Yüksek | Hayır | Kolay | İlk eleme |
| İstemci MIME başlığı | Çok yüksek | Hayır | Kolay | Neredeyse yok |
| İçerik imzası okuma | Orta | Hayır | Orta | İkinci eleme |
| Görsel yeniden üretme | Düşük | Büyük ölçüde | Orta | Gömülü kodu temizler |
| Web kökü dışı depolama | Çok düşük | Evet, birlikte | Orta | Ana savunma |
| Dizinde yorumlayıcı kapatma | Çok düşük | Evet, birlikte | Kolay | Ana savunma |
| Rastgele dosya adı | Çok düşük | Hayır | Kolay | Yan saldırıları kapatır |
Kabuk yüklendiğinde tam olarak ne kaybediyorsun?
Bu soruyu net konuşmak lazım, çünkü soyut kaldığında insan tedbir almıyor. Sunucuda komut çalıştırabilen biri sırayla şunlara ulaşır: yapılandırma dosyasındaki veritabanı bilgileri, ödeme sağlayıcı gizli anahtarları, tedarikçi API kimlikleri, henüz satılmamış kod stoğun, müşteri iletişim listesi ve varsa aynı sunucudaki diğer siteler. Ardından kalıcılık kurar; yani sen dosyayı bulup silsen bile geri dönebileceği ikinci bir yol bırakır.
En can sıkıcı kısım yedekler. Arka kapı bırakıldıktan sonra alınan her yedek, o arka kapıyı da içeriyor. Temiz bir noktaya dönmek için olayın ne zaman başladığını bilmen gerekir ve bunu bilmenin tek yolu düzgün kayıt tutmaktır. Bu yüzden yükleme dizinindeki her yeni dosyanın kim tarafından, hangi oturumda ve hangi kayıt için oluşturulduğunun kayda geçmesi, bir lüks değil temel gereklilik. Bir epin yazılım değerlendirirken "yükleme kayıtları tutuluyor mu" sorusunu mutlaka sor.
Yükleme kaynaklı olaylarda kök nedenlerin dağılımı
- Web kökü içinde çalıştırılabilir dizin 50%
- Sadece uzantı veya MIME kontrolü 25%
- Kullanıcı dosya adının korunması 15%
- Arşiv açma ve içe aktarma hataları 10%
İçe aktarma ve arşiv dosyaları neden ayrı bir bahis?
E-pin panellerinde toplu kod yükleme, ürün içe aktarma ve bayi listesi aktarımı gibi ekranlar bulunur. Buralara metin tabanlı tablo dosyaları ya da sıkıştırılmış arşivler yüklenir ve risk profili görsel yüklemeden farklıdır. Arşiv açarken içindeki dosya yolları dizin dışına çıkabilir, sembolik bağlantılar başka konumlara işaret edebilir, sıkıştırma oranı yüksek bir dosya diski doldurabilir. Tablo dosyalarında ise hücre içeriği başka bir programda formül olarak yorumlanabilir; bu, doğrudan sunucuyu değil raporu açan kişiyi hedefleyen bir risktir ama sonuçları ciddidir.
Doğru yaklaşım şu: arşivleri geçici ve izole bir dizine açmak, her girdinin hedef yolunu doğrulamak, dizin dışına çıkan veya bağlantı olan girdileri reddetmek, açılmış toplam boyuta üst sınır koymak. Tablo dosyalarında ise hücreleri metin olarak işlemek ve formül başlatıcı karakterle başlayan değerleri etkisizleştirmek. Bu kontroller olmadığında, "sadece ürün listesi yüklüyorum" dediğin ekran panelin en zayıf halkası hâline gelir.
| Kontrol maddesi | Nasıl test edersin | Beklenen davranış |
|---|---|---|
| Uzantı eleme | Çift uzantılı bir dosya yükle | Reddedilsin |
| İçerik doğrulama | Görsel başlığı taklit eden metin dosyası gönder | Geçersiz dosya hatası alsın |
| Depolama konumu | Yüklediğin dosyanın adresine tarayıcıdan git | Çalışmasın, indirme veya erişim reddi olsun |
| Dosya adı üretimi | Aynı adla iki dosya yükle | İkisi de ayrı kimlikle saklansın |
| Boyut sınırı | Çok büyük bir dosya dene | Sınır aşıldı uyarısı gelsin |
| Arşiv yol doğrulaması | Dizin dışına çıkan yol içeren arşiv yükle | Girdi atlanıp uyarı verilsin |
| Yükleme kaydı | Kayıt ekranını kontrol et | Kim, ne zaman, hangi dosya görünsün |
Yükleme alanını kim kullanabilmeli?
Teknik kontrollerin yanında çok basit bir yetki sorusu var ve sıklıkla atlanıyor: bu ekrana kimin erişmesi gerekiyor? Ürün görselini yalnızca yönetici yüklüyorsa, o alanın kayıtlı olmayan kullanıcıya açık olmasının hiçbir gerekçesi yok. Destek talebine ek dosya özelliği müşteriye açıksa, izin verilen türleri en dar kümede tutmak ve boyut sınırını düşük belirlemek mantıklı. Bayi logosu yüklemesi varsa, bunu onay akışına bağlamak makul bir denge.
Yetki daraltmanın ek faydası, gürültüyü azaltması. Az sayıda yetkili kullanıcı, az sayıda yükleme, kayıtlarda kolay okunabilen bir tablo demek. Anormal bir hareket olduğunda gözüne çarpar. Panelin rol ve yetki yapısının ne kadar ayrıntılı olduğunu özellik bölümünde inceleyebilir, kendi ekip yapına uygun kurulumu fiyat sayfasında değerlendirebilirsin.
Bugün yapabileceğin en etkili tek hamle, yükleme dizininde sunucu tarafı kod çalıştırmayı kapatmak. Bu ayar, yüklenen dosya hangi kontrolü atlatırsa atlatsın çalışmasını engeller ve uygulamada tek satır değişiklik gerektirmez.
Bir olay yaşandıysa doğru sıra nedir?
Panik en pahalı tepki. Doğru sıralama şöyle: önce yükleme dizinine erişimi tamamen kapat, sonra yeni yüklemeleri durdur, ardından kayıtlardan olayın başlangıç zamanını tespit et. Bu zamanı bulmadan yedekten dönmek, arka kapıyı geri yüklemek anlamına gelebilir. Üçüncü adımda tüm gizli değerleri döndür: veritabanı şifresi, ödeme sağlayıcı anahtarları, tedarikçi kimlikleri ve yönetici oturumları. Dördüncü adımda stoğu denetle; hangi kodlar okundu, hangileri teslim edildi, hangileri iptal edilmeli.
Son adım kalıcı düzeltme: yükleme konumunu web kökü dışına taşı, dosya adı üretimini sunucuya al, içerik doğrulamasını ekle, çalıştırmayı kapat ve yükleme kaydını devreye sok. Bu beş madde tamamlandığında aynı olayın tekrarlanma olasılığı büyük ölçüde ortadan kalkar. Sıfırdan kurulum yapıyorsan, bu beş maddenin zaten yapılmış olduğu bir altyapıdan başlamak hem zaman hem risk tasarrufu.
Yükleme katmanı doğru kurgulanmış bir panelle başla
Pinova'da yüklenen dosyalar web kökü dışında, sunucu tarafında üretilmiş adlarla saklanır ve yetki kontrolünden geçerek servis edilir. Görsel alanları risk kaynağı olmaktan çıkar.
Sadece görsel kabul ediyorum, yine de risk var mı?
Var. Dosya adı ve içerik türü istemci tarafından belirlenir, geçerli görsel başlığının ardına kod eklenmiş dosyalar üretilebilir. Belirleyici olan dosyanın nereye yazıldığı ve orada çalıştırılıp çalıştırılamadığı.
Yükleme dizinini web kökü dışına almak zorunlu mu?
En güvenli yol bu. Mümkün olmadığı durumlarda en azından o dizinde sunucu tarafı kod çalıştırmayı kapatmak ve dizin listelemeyi engellemek gerekir. İkisi birlikte uygulanırsa risk ciddi biçimde düşer.
Görseli yeniden üretmek gömülü kodu temizler mi?
Büyük ölçüde evet. Dosyayı okuyup yeniden kaydettiğinde meta alanlarına ve dosya sonuna gömülmüş içerik kaybolur. Yine de bunu tek savunma olarak değil, çalıştırma yasağının yanındaki bir katman olarak düşün.
Toplu içe aktarma ekranı için ne yapmalıyım?
Arşivleri izole bir geçici dizinde aç, her girdinin hedef yolunu doğrula, dizin dışına çıkan ve bağlantı olan girdileri reddet, açılmış toplam boyuta sınır koy. Tablo dosyalarında hücreleri metin olarak işle.
Dosya yükleme, e-pin işinde küçük görünen ama sonuçları en büyük olan konu. İyi haber şu: kontrol listesi kısa ve bir kez doğru kurulduğunda bakımı neredeyse sıfır. Konum, ad üretimi, içerik doğrulama, çalıştırma yasağı ve kayıt. Bu beş maddenin bir panelde nasıl uygulandığını görmek, teorik açıklamadan çok daha öğretici olur; ürün görseli, bayi logosu ve destek eki akışlarını canlı demo üzerinde kendi dosyalarınla test edip yükleme katmanının nasıl davrandığını doğrudan gözlemleyebilirsin.