Spiegazione del file .htaccess

Una configurazione che vive nella cartella

Un server web ha un file di configurazione principale che solo il suo amministratore può modificare. Su un hosting condiviso quell’amministratore non sei tu, quindi Apache ti offre un’altra porta d’ingresso. È un semplice file di testo chiamato .htaccess, messo in una cartella del sito, e le sue istruzioni valgono per quella cartella e per tutto quello che c’è sotto. I server LiteSpeed leggono lo stesso file. nginx no, e lo ignora del tutto.

Il server rilegge il file a ogni richiesta, quindi una modifica ha effetto nel momento in cui salvi. Anche un errore. Basta una direttiva scritta male e ogni pagina risponde con un errore 500 finché non correggi la riga. Tieni una copia prima di ogni modifica.

Raramente sei l’unico autore. WordPress scrive un blocco tra # BEGIN WordPress e # END WordPress, e i plugin di cache, sicurezza e immagini aggiungono i propri blocchi marcati. Lo strumento riconosce i marcatori di circa 25 di loro, tra cui WP Rocket, LiteSpeed Cache, Wordfence e Really Simple SSL, e indica il proprietario di ogni blocco.

Leggere ad alta voce una regola di rewrite

mod_rewrite è dove la maggior parte delle persone si perde. Prendi questa coppia:

RewriteCond %{HTTP_HOST} ^shop\.example\.com$ [NC]
RewriteRule ^products/(\d+)$ https://www.example.com/item?id=$1 [R=301,L]

Si legge come una frase: «Se l’host richiesto è shop.example.com, in maiuscolo o minuscolo, e il percorso è products/ seguito da cifre, manda il visitatore in modo permanente al nuovo indirizzo con quelle cifre come id, e smetti di elaborare.»

• Un RewriteCond è una condizione su una variabile del server. Vale solo per la RewriteRule successiva. Se ce ne sono diverse di fila devono essere tutte vere, a meno che una finisca con [OR].
• La prima parte di una RewriteRule è un’espressione regolare confrontata con il percorso. Le parentesi catturano del testo, e $1, $2 lo riusano nella destinazione. %1 riusa una cattura dell’ultima condizione.

Cosa viene segnalato

Chi attacca un sito e ottiene accesso in scrittura punta spesso al .htaccess, perché poche righe lì bastano per reindirizzare i visitatori o tenere raggiungibile uno script nascosto. Lo strumento confronta ogni riga con schemi visti in infezioni reali e le assegna una di due etichette.

Sospetta, in rosso:

• un reindirizzamento verso un altro dominio che vale solo per i visitatori che arrivano da un motore di ricerca, o solo per i telefoni. Il proprietario, che digita l’indirizzo direttamente da un computer, non lo vede mai;
• uno script PHP diverso servito ai crawler dei motori di ricerca;
• AddHandler, AddType o SetHandler che fanno eseguire come PHP file di immagini o di testo, o fanno eseguire file normali come script CGI;
• php_value auto_prepend_file o auto_append_file che caricano un file prima o dopo ogni script, e allow_url_include;
• un blocco FilesMatch che nega ogni file .php, .py ed .exe, seguito da un blocco che autorizza un breve elenco di file PHP che WordPress non include.

Da controllare, in arancione: righe dentro il blocco WordPress che non fanno parte delle sue regole standard, condizioni rivolte solo ai crawler o ai referrer, il flag [P], una pagina di errore ospitata su un altro dominio, l’elenco delle cartelle attivato, errori PHP mostrati ai visitatori, un firewall applicativo disattivato, righe più lunghe di 400 caratteri o piene di base64 o di caratteri codificati, e caratteri invisibili.

Vengono segnalati anche due errori di struttura, perché entrambi causano un 500: un blocco come <IfModule> che non viene mai chiuso, e direttive ammesse solo nella configurazione principale del server, come DocumentRoot o <VirtualHost>.

Se una riga è segnalata e non l’hai scritta tu

1. Scarica una copia del file come prova prima di toccare qualsiasi cosa.
2. Controlla la data di modifica del file e cerca altri file modificati nello stesso momento, soprattutto file PHP nelle cartelle di upload e i nomi citati nelle regole segnalate.
3. Elimina le righe ostili, poi ricarica il file qualche minuto dopo. Se sono tornate, uno script sul server lo sta riscrivendo e cancellare le righe non basterà.
4. Cambia le password dell’hosting, dell’FTP o SSH, del database e dell’amministratore del CMS, e aggiorna il CMS con tutti i suoi plugin e temi.
5. Usa la verifica dei siti pericolosi per vedere se il sito è già in una lista nera dei browser, e il tracciamento dei reindirizzamenti per confermare che i visitatori arrivano dove devono.