- Konu sahibi
- #1
Ortam dosyalarının webden indirilmesi nasıl engellenir?
Ortam dosyalarının indirilmesini engellemenin en güvenli yolu, bu dosyaları web sunucusunun yayın kökünün dışına taşımaktır. Dosya web kökünde kalmak zorundaysa web sunucusunda açık bir erişim kuralı tanımlayın ve sonucu gerçek bir HTTP isteğiyle test edin. Yalnızca
robots.txt kullanmak, dosyayı gizlemez; bu dosya güvenlik kontrolü değildir.Önce doğru dosya yerleşimini seçin
.env, uygulama ayarları, özel anahtarlar, veritabanı yedekleri ve hata günlükleri tarayıcıya sunulmayan bir dizinde tutulmalıdır. Örneğin uygulamanın yayınlanan dosyaları /var/www/example.com/public altındaysa ortam dosyasını /var/www/example.com/.env konumuna koymak, onu yayın kökünün dışına çıkarır. Uygulama bu dosyayı okuyacak kullanıcı ve dosya izinlerine sahip olmalı; web sunucusunun doğrudan dosya sunmasına gerek kalmamalıdır.Dosyayı taşıyamıyorsanız en azından hassas dosya adlarını web sunucusunda engelleyin. Aşağıdaki kurallar .env ailesini kapsar; .git dizini, yapılandırma kopyaları ve farklı adlı yedeklerin tamamını kapattıkları varsayılmamalıdır. Bunları da yayın paketinin dışında tutun.
Apache için en küçük uygulama
Apache kullanıyor ve yayın kökünde
.htaccess kullanımına izin veriliyorsa, mevcut .htaccess dosyanızı koruyarak aşağıdaki kuralı ekleyin:
Kod:
<FilesMatch "(?i)^\.env(?:\..*)?$">
Require all denied
</FilesMatch>.htaccessdosyasını yayın köküne yerleştirin ve Apache yapılandırmasında bu dizin için Require için gerekli AuthConfig override yetkisinin veya uygun dar AllowOverrideList izninin etkin olduğundan emin olun.- Korunması gereken dosya adlarını kurala ekleyin. Örnek desen .env, .env.production ve .env.bak gibi noktayla devam eden adları kapsar. Kendi farklı kopya adlarınızı ayrıca envanterleyin.
- Yapılandırmayı yükleyip
https://example.com/.envve bir yedek dosyayı isteyin.
Başarılı sonuç, dosyanın içeriğinin dönmemesi ve sunucunun genellikle
403 veya 404 yanıtı vermesidir. Dosya hâlâ 200 ile dönüyorsa .htaccess okunmuyor olabilir veya istek başka bir proxy, uygulama ya da sanal konfigürasyon tarafından karşılanıyor olabilir.| Önlem | Koruduğu durum | Sınırı |
|---|---|---|
| Yayın kökü dışına taşıma | Dosyanın doğrudan HTTP ile sunulmasını | Uygulamanın doğru dosya yolunu kullanması gerekir |
| Web sunucusu erişim kuralı | Yanlışlıkla yayınlanan bilinen dosya adlarını | Yeni veya unutulmuş uzantıları kendiliğinden bulmaz |
| Dosya izinleri | Yetkisiz yerel kullanıcı erişimini | Uygulama okuyabiliyorsa yanlışlıkla HTTP yanıtına yazmasını kendiliğinden önlemez |
| Dağıtım temizliği | Yedek, günlük ve sürüm kontrol artıklarını | Her dağıtımda tekrarlanmalıdır |
Nginx için en küçük uygulama
Nginx yapılandırmasında ilgili
server bloğuna hassas dosya desenlerini engelleyen bir location kuralı eklenebilir:
Kod:
location ~* (^|/)\.env(?:[./]|$) {
return 404;
}- Kuralları ilgili sitenin
serverbloğuna ekleyin; başka sitelerin kurallarına yanlışlıkla uygulamayın. Regex location sırası ile exact veya ^~ location önceliklerini inceleyin; bir kuralın dosyada bulunması tek başına bütün isteklerin ona girdiğini kanıtlamaz. - Nginx yapılandırmasını sözdizimi kontrolünden geçirin ve başarılıysa yeniden yükleyin. Sözdizimi kontrolü başarısızsa yeniden yükleme yapmayın; hatalı yapılandırma mevcut hizmeti etkileyebilir.
- Dosya adlarını hem doğrudan hem de alt dizin içinden test edin. Örneğin /.env, /.env.production ve /config/.env.bak yollarını kontrol edin. Bu örnekte app.ini veya .git/config için ayrı koruma yoktur; onları yayın kökü dışında tutmak gerekir.
Kullandığınız dağıtım, kontrol paneli veya Nginx eklentisi bu kuralları başka bir dosyadan üretiyorsa, doğrudan üretilen dosyayı değiştirmek yerine panelin kalıcı yapılandırma alanını kullanın. Aksi durumda sonraki yapılandırma üretiminde kural silinebilir.
Hangi önlem neyi çözer?
Aşağıdaki ayrım, yalnızca tek bir dosya adını engelleyip diğer sızıntıları unutmayı önler.
Kontrol ve sızıntı olduysa yapılacaklar
Tarayıcı yerine
curl -I https://example.com/.env gibi bir başlık isteğiyle başlayın; ardından gövdenin de dönmediğini kontrol edin. 403 veya 404 alınması olumlu bir işarettir, fakat dosyanın geçmişte indirilmediğini kanıtlamaz. Web sunucusu, proxy ve uygulama günlüklerinde bu yolları arayın.Bir ortam dosyası daha önce erişilebilir olduysa yalnızca erişim kuralı eklemek yeterli değildir. İçindeki veritabanı parolalarını, API anahtarlarını ve imzalama anahtarlarını geçersiz kılıp yenileyin; dosyayı dağıtım paketlerinden ve herkese açık yedeklerden kaldırın. Sonra hem eski dosya adlarını hem de alternatif uzantıları yeniden test edin.
Sık yapılan hatalar
Sadece uzantıyı engellemek:
.env kapatılıp .env.bak, config.old veya database.sql açık bırakılabilir.Sadece robots.txt'ye güvenmek: Kötü niyetli istemciler bu dosyaya uymak zorunda değildir.
Dosyayı engelleyip sırları değiştirmemek: Dosya bir kez açığa çıktıysa kural eklemek, daha önce ele geçirilmiş kimlik bilgilerini geri almaz.
Uygulama rotasını unutmak: Web sunucusu dosyayı engellese bile uygulama, ayar veya günlük dosyasını kendi endpoint'i üzerinden döndürebilir. Şüpheli indirme yollarını uygulama rotalarında da arayın.
Sık sorulan sorular
Engellenen dosya için 403 mü, 404 mü kullanılmalı?
İkisi de içeriğin dönmediği ve uygulamanın normal çalıştığı durumda kullanılabilir.
404 dosyanın varlığı hakkında daha az bilgi verebilir; ancak asıl güvenlik şartı, dosya içeriğinin hiçbir yanıt gövdesinde sunulmamasıdır.
