Raccomandazioni HSTS in .htaccess

Question

Si prega di consultare il mio post precedente nel collegamento ipertestuale sottostante

Ho aggiornato il mio .htaccessfile per tenere conto di un HSTS, insieme a molte delle modifiche consigliate. Vedi lo snippet di seguito. Vorrei sottolineare che l' implementazione di un HSTS non è da prendere alla leggera per nessun altro nuovo. Detto questo, sto cercando consigli su cosa si può fare in modo diverso da coloro che hanno conoscenza .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>

Implementazione HSTS

Per notare alcune cose che ho imparato durante la ricerca di HSTS:

1. È richiesto un certificato SSL
2. Se i tuoi siti sono disponibili tramite HTTP, reindirizza tutte le richieste a HTTPS con un reindirizzamento permanente 301.
3. Includere quanto segue nel .htaccessfile di: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. L'età massima deve essere di almeno 10886400 secondi o 18 settimane. Scegli il valore di due anni.
4. Aggiungi il tuo dominio a un elenco di precaricamento utilizzando il primo collegamento di seguito.

Incoraggio tutti a leggere ogni fonte di seguito per ulteriori informazioni.

• Invio elenco precaricamento HSTS
• Cos'è l'HSTS e perché dovrei usarlo? | Acunetix
• Cos'è HSTS e dovrei implementarlo? | Dinamiche di rete
• Perché i siti web dovrebbero utilizzare HSTS per migliorare la sicurezza e la SEO

Answer 1

Ci sono due aspetti in HTTP Strict Transport Security (HSTS):

1. Implementazione di HSTS sul tuo sito.
2. Invio del tuo sito già abilitato per HSTS all'elenco di precaricamento HSTS . Qui è dove l '"elenco dei siti HSTS" viene compilato direttamente nel browser, il che evita che la prima richiesta sia su HTTP (dove la richiesta è potenzialmente vulnerabile agli attacchi MITM).

Sembra che tu stia andando dritto per il n. 2. Questo non è necessariamente consigliato. Pensa alla "lista di precarico" come a un viaggio di sola andata. Tecnicamente è possibile essere rimosso dalla lista dei precarichi; realisticamente non è qualcosa a cui vuoi nemmeno pensare. (È difficile - lento - abbastanza fare un passo indietro dal solo HSTS.)

La stessa pagina di invio dell'elenco di precaricamento non consiglia di andare direttamente a "invio di elenco di precaricamento". La raccomandazione è di aumentare il max-ageparametro per un periodo di tempo (mesi), prima di eseguire il passaggio finale per l'invio all'elenco di precarico. Testare il test di prova nel frattempo per garantire che i certificati SSL siano rinnovati in modo affidabile, nessun avviso di contenuto misto ecc. Ecc.

Sarei anche diffidente circa l'invio dell'elenco di precaricamento HSTS (o anche lo stesso HSTS in una certa misura) su un server condiviso , dove non hai il pieno controllo sulla configurazione SSL. In realtà non dichiari se sei su un server condiviso o meno, ma dal momento che stai facendo tutta questa configurazione .htaccess, presumo che tu lo sia. Se hai il tuo server e accedi alla configurazione del server, la maggior parte di questo dovrebbe essere configurata nella configurazione del server / virtualhost (ed è probabilmente più facile e più affidabile farlo).

Ricorda che una volta che hai seguito il percorso HSTS (e gli utenti hanno effettuato l'accesso al sito HTTPS o sei nella "lista di precaricamento"), è possibile accedere al tuo sito solo tramite HTTPS. Questo non si applica solo al tuo sito, ma anche a tutti i servizi di terze parti che potresti utilizzare (avvisi del browser di contenuti misti, ecc.).

#IMPLEMENT HSTS
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

Questo imposta l'intestazione della risposta HTTP HSTS richiesta sulla "maggior parte" ^{* 1 delle} risposte (ma nota il preloadparametro, che probabilmente dovrebbe essere omesso inizialmente).

^{* 1} Tuttavia, questa direttiva non imposta necessariamente l'intestazione richiesta su tutte le risposte. Un requisito di HSTS è che imposti anche l'intestazione sulle risposte di "reindirizzamento" (ad es. Da www a non-www su HTTPS). Attualmente quanto sopra non lo fa. Dovresti usare laalways condizione sullaHeaderdirettiva per impostare l'intestazione su risposte diverse da 200 OK. Per esempio:

# Use "always" condition to set on "redirects" as well.
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

(Ho anche rimosso il preloadparametro per ora.)

Non è necessario il <IfModule>wrapper e deve essere rimosso. mod_headers dovrebbe essere abilitato per impostazione predefinita. Questo è il tuo server, sai se mod_headers è abilitato o meno. mod_headers deve essere abilitato affinché funzioni. Non vuoi che questo fallisca silenziosamente se mod_headers non fosse disponibile: hai bisogno di una notifica non appena questo fallisce con un errore nei tuoi log.

Molti articoli affermano che si dovrebbe solo impostare l' Strict-Transport-Securityintestazione delle risposte sicure (HTTPS). E l '"invio dell'elenco di precaricamento" emette effettivamente un "avviso" (non strettamente un "errore" credo) se si invia anche l'intestazione tramite HTTP. Tuttavia, anche se deve essere impostato solo sulla risposta HTTPS, i browser conformi ignorano questa intestazione quando viene inviata su una connessione HTTP non crittografata (per prevenire attacchi MITM), quindi non dovrebbe importare se l'intestazione viene inviata "inutilmente" anche tramite HTTP. Questo sarebbe più facile da gestire nei <VirtualHost>contenitori appropriati nella configurazione del server principale. L'invio di questa intestazione solo su risposte HTTPS in .htaccessè più complesso (e quindi più soggetto a errori). È necessario utilizzare una variabile di ambiente aggiuntiva che è possibile utilizzare per impostare in modo condizionale l'intestazione della risposta HSTS.

Per esempio:

# 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

Altrimenti, credo che le tue restanti direttive vadano bene per quanto riguarda l'HSTS. Ma come sempre, prova prova prova.

---

Risolvi più reindirizzamenti (non necessari)

#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]

Un potenziale problema qui (con il secondo e il terzo reindirizzamento canonico sopra, dopo il reindirizzamento da HTTP a HTTPS) è che questo potenzialmente si traduce in due reindirizzamenti aggiuntivi se viene richiesto www+ .html. Questo potrebbe essere risolto semplicemente invertendo i due reindirizzamenti e includendo il nome host canonico nel reindirizzamento "RIMOZIONE ESTENSIONE URL" (come menzionato nella mia risposta alla tua domanda precedente ).

Per esempio:

#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]

Vedere la mia risposta precedente per un approccio alternativo al reindirizzamento "RIMOZIONE ESTENSIONE URL" che risolve alcuni potenziali problemi.

Se non si utilizza il wwwsottodominio su altri nomi host (ad es. www.subdomain.example.com), È possibile semplificare il CondPattern sul reindirizzamento www in non www semplicemente ^www\., ad es. qualsiasi nome host richiesto che si avvia semplicemente www., anziché controllare l'intero nome host.

---

Correzioni aggiuntive

Rimozione / riscrittura estensione URL loop (errore server interno 500)

Ci sono un paio di altri problemi che non sono riuscito a risolvere nella tua domanda precedente , non relativi all'HSTS, che tratterò di seguito ...

#URL EXTENSION REMOVAL
:
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^ %{REQUEST_URI}.html [NC,L]

Questo (e simili) è uno di quegli snippet di codice che vengono copiati / incollati "ciecamente" ovunque (e intendo ovunque ) come metodo "standard" per aggiungere (riscrivere URL) l'estensione del file quando si utilizzano URL senza estensione. Tuttavia, anche se probabilmente "funziona" per i tuoi URL validi, presenta un grave difetto quando si richiedono URL non validi ...

Se /about.htmlè un file valido che desideri servire quando richiedi l'URL senza estensione, /aboutallora funziona bene. Tuttavia, se ho (maliziosamente) richiesto /about/o /about/<anything>invierà il tuo server in un ciclo di riscrittura a spirale, con conseguente risposta di 500 Errore interno del server. L'utente finale non dovrebbe essere in grado di invocare tale risposta (potenzialmente più vulnerabile agli attacchi DDOS e ad altri comportamenti ostili).

Questo perché REQUEST_FILENAME(il percorso del filesystem mappato) non si riferisce necessariamente allo stesso percorso URL pubblico della REQUEST_URIvariabile (percorso URL richiesto).

Per risolvere questo problema, usa REQUEST_URItutto. Per esempio:

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI}.html -f
RewriteRule ^ %{REQUEST_URI}.html [L]

(La NCbandiera è superflua sulla RewriteRuledirettiva qui.)

Vedi la mia risposta alla seguente domanda ServerFault per maggiori dettagli su questo.

Protezione Hotlink - Semplifica la condizione

#HOTLINKING PROTECTION
RewriteCond %{HTTP_REFERER} !^https://(www\.)?example\.com(/.*)*$ [NC]

Questo è relativamente minore. La regex nella condizione di cui sopra può essere semplificata. A questo punto del .htaccessfile, il nome host è già stato canonizzato per rimuovere il www dal sottodominio, quindi il (www\.)?subpattern sopra è superfluo. Come lo schema (/.*)*$secondario finale , che corrisponde semplicemente a tutto il resto. Non è necessario che corrisponda effettivamente a nulla qui, è sufficiente affermare che l' Refererintestazione inizia con il nome host appropriato (schema +).

Per esempio:

RewriteCond %{HTTP_REFERER} !^https://example\.com

Anche qui la NCbandiera è superflua. Forzare una corrispondenza senza distinzione tra maiuscole e minuscole quando non è richiesta crea solo (un po ') più lavoro per il tuo server e in alcuni casi può aprirti a vulnerabilità ("contenuto duplicato" è comune, anche se questo non è un problema qui) .

Abilitazione non necessaria Options

#PREVENT DIRECTORY BROWSING
Options All -Indexes

Questo non solo impedisce la "navigazione nelle directory". L' Allargomento abilita un sacco di altre cose che probabilmente non ti servono, come include ( Includes) lato server e la possibilità di eseguire script CGI ( ExecCGI). (Per inciso, questa è l'unica volta in cui puoi mescolare argomenti con a +o -con quelli senza.) Per impedire solo la navigazione nelle directory (cioè la generazione automatica degli indici delle directory da mod_autoindex), rimuovi l' Allargomento.

Tuttavia, probabilmente hai solo bisogno FollowSymLinks (che potrebbe essere già impostato nella configurazione del server), quindi potresti invece impostare quanto segue:

Options FollowSymLinks

Notare l'assenza di +o -. Questo solo set FollowSymLinks, in modo invalidante Indexes( "esplorazione directory") se è stato già impostato.