.Htaccess'te HSTS Önerileri
Lütfen aşağıdaki köprüdeki önceki gönderime bakın
.htaccessDosyamı önerilen değişikliklerin birçoğuyla birlikte bir HSTS'yi hesaba katacak şekilde güncelledim . Aşağıdaki parçacığa bakın. Bir HSTS'nin uygulanmasının, yeni başlayanlar için hafife alınmaması gerektiğini vurgulamak isterim . Bununla birlikte, bilgi sahibi olanlardan farklı olarak neler yapılabileceği konusunda tavsiye arıyorum .htaccess.
#IMPLEMENT HSTS
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>
#CUSTOM ERROR PAGES
ErrorDocument 400 /allerror.php
ErrorDocument 401 /allerror.php
ErrorDocument 403 /allerror.php
ErrorDocument 404 /allerror.php
ErrorDocument 405 /allerror.php
ErrorDocument 408 /allerror.php
ErrorDocument 500 /allerror.php
ErrorDocument 502 /allerror.php
ErrorDocument 504 /allerror.php
RewriteEngine On
#REDIRECT TO SECURE HTTPS CONNECTION
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
#FORCE WWW TO NON-WWW
RewriteCond %{HTTP_HOST} ^www.example.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]
#URL EXTENSION REMOVAL
RewriteCond %{THE_REQUEST} /([^.]+)\.html [NC]
RewriteRule ^ /%1 [NC,L,R]
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^ %{REQUEST_URI}.html [NC,L]
#HOTLINKING PROTECTION
RewriteCond %{HTTP_REFERER} !^https://(www\.)?example\.com(/.*)*$ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(css|flv|gif|ico|jpe|jpeg|jpg|js|mp3|mp4|php|png|pdf|swf|txt)$ - [F]
#CONTENT SECURITY POLICY
<FilesMatch "\.(html|php)$">
Header set Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data: 'unsafe-inline'; media-src 'self' data: 'unsafe-inline'; connect-src 'self';"
</FilesMatch>
#REDIRECT FOR DATE PAGE
RewriteRule ^date$ /storage/date-202010 [R=301,L]
#REDIRECT FOR HOME PAGE
RewriteRule ^home$ / [R=301,L]
#PREVENT DIRECTORY BROWSING
Options All -Indexes
#FILE CACHING
#cache html and htm files for one day
<FilesMatch "\.(html|htm)$">
Header set Cache-Control "max-age=43200"
</FilesMatch>
#cache css, javascript and text files for one week
<FilesMatch "\.(js|css|txt)$">
Header set Cache-Control "max-age=604800"
</FilesMatch>
#cache flash and images for one month
<FilesMatch "\.(flv|swf|ico|gif|jpg|jpeg|mp4|png)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>
#disable cache for script files
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
#BLOCKS FILE TYPES FOR USERS
<FilesMatch "\.(ht[ap]|ini|log|sh|inc|bak)$">
Require all denied
</FilesMatch>
HSTS Uygulaması
HSTS'yi araştırırken öğrendiğim birkaç şeyi not etmek gerekirse:
- SSL sertifikası gerekli
- Siteleriniz HTTP aracılığıyla kullanılabiliyorsa, tüm istekleri 301 Kalıcı Yönlendirme ile HTTPS'ye yönlendirin.
- Senin şu ekleyin
.htaccessdosyanın:Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. Maksimum yaş, en az 10886400 saniye veya 18 Hafta olmalıdır. İki yıllık değeri seçin. - Aşağıdaki ilk bağlantıyı kullanarak alanınızı bir önyükleme listesine ekleyin.
Herkesi daha fazla bilgi için aşağıdaki her bir kaynağı okumaya teşvik ediyorum.
Yanıtlar
HTTP Katı Taşıma Güvenliği'nin (HSTS) iki yönü vardır:
- Sitenize HSTS uygulamak.
- Zaten HSTS'nin etkin olduğu sitenizi HSTS önyükleme listesine gönderme . Bu, "HSTS sitelerinin listesi" nin doğrudan tarayıcıda derlendiği yerdir ve bu da ilk isteğin HTTP üzerinden yapılmasını önler (burada istek MITM saldırılarına karşı potansiyel olarak savunmasızdır).
2 numaraya doğru gidiyor gibisin. Bu mutlaka tavsiye edilmiyor. "Ön yükleme listesini" tek yönlü bir yolculuk olarak düşünün. Teknik olarak önyükleme listesinden çıkarılması mümkündür; gerçekçi olarak bu, düşünmek bile isteyeceğiniz bir şey değil. (Zor - yavaş - yalnızca HSTS'den yeterince geri adım atmak.)
Önyükleme listesi gönderim sayfasının kendisi doğrudan "önyükleme listesi gönderimi" ne gitmenizi tavsiye etmez. Öneri, max-ageönyük listesine göndermek için son adımı atmadan önce parametrenin belirli bir süre (aylar) boyunca artırılmasıdır . Bu arada, SSL sertifikalarının güvenilir bir şekilde yenilendiğinden, karışık içerik uyarıları vb. Olmadığından emin olmak için test testi testi.
Ayrıca , SSL yapılandırması üzerinde tam kontrole sahip olmadığınız paylaşılan bir sunucuda HSTS önyükleme listesi gönderimi (veya hatta bir dereceye kadar HSTS'nin kendisi) konusunda dikkatli olurdum . Aslında paylaşılan bir sunucuda olup olmadığınızı .htaccessbelirtmiyorsunuz , ancak tüm bu yapılandırmayı yaptığınız için , öyle olduğunuzu varsayıyorum. Kendi sunucunuz ve sunucu yapılandırmasına erişiminiz varsa, bunun çoğu sunucu / sanal ana bilgisayar yapılandırmasında yapılandırılmalıdır (ve bunu yapmak muhtemelen daha kolay ve daha güvenilirdir).
HSTS yoluna gittiğinizde (ve kullanıcılar HTTPS sitesine eriştikten veya "önyükleme listesi" ndeyseniz) sitenize yalnızca HTTPS üzerinden erişilebileceğini unutmayın. Bu sadece siteniz için değil, aynı zamanda kullanıyor olabileceğiniz 3. taraf hizmetleri için de geçerlidir (karışık içerik tarayıcı uyarıları vb.).
#IMPLEMENT HSTS <IfModule mod_headers.c> Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" </IfModule>
Bu, gerekli HSTS HTTP yanıt başlığını "çoğu" * 1 yanıtında ayarlar (ancak preloadbaşlangıçta muhtemelen atlanması gereken parametreye dikkat edin ).
* 1 Ancak, bu yönerge tüm yanıtlardagerekli başlığı ayarlamaz. HSTS'nin bir gerekliliği, başlığı "yeniden yönlendirme" yanıtlarına da ayarlamanızdır (ör. Www'dan HTTPS'de www olmayana). Şu anda yukarıdakiler bunu yapmamaktadır. Sen kullanarak olmalıdıralways koşulu ileHeader200 OK dışındaki cevaplara başlığını ayarlamak için direktif. Örneğin:
# Use "always" condition to set on "redirects" as well.
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
( preloadŞimdilik parametreyi de kaldırdım .)
<IfModule>Paketleyiciye ihtiyacınız yoktur ve çıkarmanız gerekir. mod_headers varsayılan olarak etkinleştirilmelidir. Bu sizin sunucunuz, mod_headers'ın etkin olup olmadığını biliyorsunuz. mod_headers gerekir çalışmalarına bunun için etkin olması. Mod_headers kullanılamadığında bunun sessizce başarısız olmasını istemezsiniz - günlüklerinizde bir hata ile başarısız olur olmaz bildirim almanız gerekir.
Çoğu makale , başlığı yalnızcaStrict-Transport-Security güvenli (HTTPS) yanıtlara ayarlamanız gerektiğini belirtir . Üstbilgiyi HTTP üzerinden de gönderirseniz, "önyükleme listesi gönderimi" gerçekten de bir "uyarı" (sanırım kesinlikle bir "hata" değil) verir. Bununla birlikte, yalnızca HTTPS yanıtında ayarlanması gerekmekle birlikte, uyumlu tarayıcılar, şifrelenmemiş bir HTTP bağlantısı üzerinden gönderildiğinde (MITM saldırılarını önlemek için) bu başlığı yoksayar; bu nedenle, başlığın HTTP üzerinden "gereksiz olarak" gönderilip gönderilmediği önemli olmamalıdır. Bu <VirtualHost>, ana sunucu yapılandırmasındaki uygun kaplarda daha kolay yönetilebilir . Bu başlığın yalnızca içindeki HTTPS yanıtlarında gönderilmesi .htaccessdaha karmaşıktır (ve dolayısıyla hataya daha yatkındır). HSTS yanıt başlığını koşullu olarak ayarlamak için kullanabileceğiniz ek bir ortam değişkeni kullanmanız gerekir.
Örneğin:
# Set environment var "HSTS" if accessed over HTTPS connection
RewriteCond %{HTTPS} on
RewriteRule ^ - [E=HSTS:1]
# Conditionally set only on HTTPS connections (ie. when "HSTS" env var is set)
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains" env=HSTS
Aksi takdirde, kalan direktiflerinizin HSTS açısından uygun olduğuna inanıyorum. Ama her zaman olduğu gibi, test testi testi.
Birden çok (gereksiz) yeniden yönlendirmeyi çözün
#FORCE WWW TO NON-WWW RewriteCond %{HTTP_HOST} ^www.example.com [NC] RewriteRule ^(.*)$ https://example.com/$1 [L,R=301] #URL EXTENSION REMOVAL RewriteCond %{THE_REQUEST} /([^.]+)\.html [NC] RewriteRule ^ /%1 [NC,L,R]
Buradaki olası bir sorun (yukarıdaki 2. ve 3. kanonik yönlendirmelerde, HTTP'den HTTPS'ye yönlendirmeden sonra), www+ .htmlistenirse bunun potansiyel olarak iki ek yeniden yönlendirmeyle sonuçlanmasıdır . Bu, iki yeniden yönlendirmeyi tersine çevirerek ve standart ana bilgisayar adını "URL UZANTISI KALDIRMA" yönlendirmesine dahil ederek çözülebilir ( önceki sorunuza verdiğim yanıtta belirtildiği gibi ).
Örneğin:
#URL EXTENSION REMOVAL
RewriteCond %{THE_REQUEST} /([^.]+)\.html [NC]
RewriteRule ^ https://example.com/%1 [R=301,L]
#FORCE WWW TO NON-WWW
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule (.*) https://example.com/$1 [R=301,L]
Bkz önceki cevabı "URL YAYIM ÇIKARMA" yönlendirme olduğunu adresleri bazı potansiyel sorunlar için alternatif bir yaklaşım için.
Eğer kullanmıyorsanız wwwdiğer ana makine adlarında alt alanı (örn. www.subdomain.example.com) O zaman basitleştirmek olabilir CondPattern basitçe için www olmayan yönlendirmek için www ^www\.yani. www.tüm ana bilgisayar adını kontrol etmek yerine basitçe başlayan herhangi bir istenen ana bilgisayar adı.
Ek Düzeltmeler
URL Uzantısı Kaldırma / Yeniden Yazma Döngüsü (500 Dahili Sunucu Hatası)
Daha önceki sorunuzda ele almadığım, aşağıda ele alacağım HSTS ile ilgili olmayan birkaç başka konu var ...
#URL EXTENSION REMOVAL : RewriteCond %{REQUEST_FILENAME}.html -f RewriteRule ^ %{REQUEST_URI}.html [NC,L]
Bu (ve benzeri), uzantısız URL'leri kullanırken dosya uzantısını eklemenin (URL'yi yeniden yazmanın) "standart" yolu olarak her yere (ve her yere ) "körü körüne" kopyalanan / yapıştırılan kod parçacıklarından biridir . Bununla birlikte, muhtemelen geçerli URL'leriniz için "çalışıyor" olsa da, geçersiz URL'ler isterken ciddi bir kusuru vardır ...
Eğer /about.htmlextensionless URL'yi isterken sunmak istediğiniz geçerli bir dosyadır /abouto zaman Tamam çalışır. Ancak, (kötü niyetle) istersem /about/veya /about/<anything>sunucunuzu sarmal bir yeniden yazma döngüsüne gönderir ve 500 Dahili Sunucu Hatası yanıtıyla sonuçlanır. Son kullanıcı, böyle bir yanıtı (DDOS saldırılarına ve diğer düşmanca davranışlara karşı potansiyel olarak daha savunmasız) başlatamamalıdır.
Bunun nedeni, REQUEST_FILENAME(eşlenen dosya sistemi yolunun) REQUEST_URI(istenen URL-yolu) değişkeni ile aynı genel URL-yoluna başvurmamasıdır .
Bunu çözmek için baştan sona kullanın REQUEST_URI. Örneğin:
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI}.html -f
RewriteRule ^ %{REQUEST_URI}.html [L]
( NCBayrak buradaki RewriteRuledirektifte gereksizdir .)
Bkz Cevabımı için aşağıdaki ServerFault soru Bu konuda daha fazla ayrıntı için.
Hotlink Koruması - Durumu Basitleştirin
#HOTLINKING PROTECTION RewriteCond %{HTTP_REFERER} !^https://(www\.)?example\.com(/.*)*$ [NC]
Bu nispeten önemsizdir. Yukarıdaki durumdaki normal ifade basitleştirilebilir. .htaccessDosyanın bu noktasında , ana bilgisayar adı www alt etki alanını kaldırmak için zaten standartlaştırılmıştır, bu nedenle (www\.)?yukarıdaki alt model gereksizdir. Diğer her şeyle eşleşen sondaki (/.*)*$alt şablonda olduğu gibi. Burada hiçbir şeyi eşleştirmenize gerek yok, sadece başlığın uygun (şema +) ana bilgisayar adıyla başladığını belirtmeniz yeterli .Referer
Örneğin:
RewriteCond %{HTTP_REFERER} !^https://example\.com
NCBayrağı burada da gereksizdir. Gerekmediğinde büyük / küçük harfe duyarlı olmayan bir eşleşmeyi zorlamak yalnızca sunucunuz için (birazcık) daha fazla iş yaratır ve bazı durumlarda sizi güvenlik açıklarına açabilir ("yinelenen içerik" yaygın olanıdır - ancak burada bir sorun değildir) .
Gereksiz etkinleştirmek Options
#PREVENT DIRECTORY BROWSING Options All -Indexes
Bu sadece "dizine göz atmayı" engellemez. AllArgüman sağlar muhtemelen sunucu tarafı içerir gibi, gerekmez diğer şeyler bir grup ( Includes) ve CGI komut dosyalarını yürütme yeteneğine ( ExecCGI). (Bu arada, argümanları a ile +veya -içermeyenlerle karıştırabileceğiniz tek zamandır .) Yalnızca dizin taramasını (yani, mod_autoindex tarafından dizin indekslerinin otomatik olarak oluşturulmasını ) önlemek için Allargümanı kaldırın .
Ancak, muhtemelen yalnızca ihtiyacınız vardır FollowSymLinks (sunucu yapılandırmasında zaten ayarlanmış olabilir), bunun yerine aşağıdakileri ayarlayabilirsiniz:
Options FollowSymLinks
+Veya yokluğuna dikkat edin -. Bu yalnızca ayarlar FollowSymLinks, yani Indexeszaten ayarlanmışsa devre dışı bırakılır ("dizine göz atma").