Sito WordPress che reindirizza a un altro sito: trovare il reindirizzamento

Perché voi non vedete il reindirizzamento

Un reindirizzamento inserito durante un attacco sceglie a chi applicarsi. Di solito risparmia chi gestisce il sito, per restare al suo posto il più a lungo possibile. Le condizioni più comuni:

• La provenienza: vengono reindirizzati solo i visitatori che arrivano da un motore di ricerca o da un social network. Il codice legge l'intestazione Referer della richiesta.
• Il dispositivo: vengono reindirizzati solo i telefoni. Il codice legge l'intestazione User-Agent.
• L'accesso: un amministratore collegato a WordPress vede il sito normale.
• La prima visita: un cookie ricorda che il visitatore è già stato reindirizzato, e la visita successiva si svolge normalmente. Il problema sembra allora intermittente.

Un cliente che vi scrive «il vostro sito mi manda altrove» va quindi preso sul serio, anche se da voi tutto si vede correttamente.

Riprodurre il reindirizzamento

Mettetevi nei panni del visitatore che lo subisce:

1. Aprite una finestra di navigazione privata, cercate il nome della vostra azienda in un motore di ricerca e fate clic sul vostro risultato.
2. Ripetete da un telefono, con i dati mobili invece del Wi-Fi.
3. Annotate l'indirizzo di destinazione, l'ora e il dispositivo: queste tre informazioni servono al provider di hosting e, più avanti, alla richiesta di esame a Google.

Se avete accesso a un terminale, questo comando chiede la vostra home page presentandosi come un iPhone arrivato da Google:

curl -s -i -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X)" -e "https://www.google.com/" https://www.vostro-sito.com/

Leggete le prime righe della risposta. Un codice 301 o 302 seguito da una riga Location: verso un indirizzo sconosciuto indica un reindirizzamento fatto dal server: si trova in .htaccess o in un file PHP. Un codice 200 mentre il browser viene reindirizzato indica un reindirizzamento fatto nella pagina, in JavaScript: di solito si trova nel database o in un file del tema.

Prima di toccare il sito: tre operazioni

1. Una copia completa così com'è. File e database, datata, conservata fuori dal server. Serve come prova, come termine di confronto e come rete di sicurezza se una pulizia toglie qualcosa di utile.
2. Le password, da un dispositivo non compromesso. Area clienti del provider di hosting, account FTP o SFTP, utente del database (riportate la nuova password in wp-config.php, costante DB_PASSWORD), poi ogni account amministratore di WordPress.
3. Le chiavi di sicurezza. Sostituite le otto righe da AUTH_KEY a NONCE_SALT di wp-config.php con un set nuovo, generato su https://api.wordpress.org/secret-key/1.1/salt/. Tutte le sessioni aperte vengono chiuse, compresa quella dell'intruso.

wp config shuffle-salts

Dove si nasconde il reindirizzamento

1. Il file .htaccess

Nella cartella principale del sito, e a volte in una sottocartella, .htaccess può contenere regole di riscrittura aggiunte dall'intruso. Il blocco che WordPress scrive da sé è breve, racchiuso tra # BEGIN WordPress e # END WordPress:

# BEGIN WordPress
# Le direttive (linee) tra "BEGIN WordPress" e "END WordPress" sono
# generate dinamicamente, e dovrebbero essere modificate solo tramite i filtri di WordPress.
# Ogni modifica alle direttive tra questi marcatori verrà sovrascritta.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Una regola RewriteCond che verifica %{HTTP_REFERER} (google, bing, facebook) o %{HTTP_USER_AGENT} (android, iphone, mobile), seguita da una RewriteRule verso un indirizzo esterno, è il reindirizzamento. Anche i plugin di cache e di sicurezza scrivono blocchi propri, contrassegnati con il loro nome: confrontate ogni blocco con l'elenco dei vostri plugin prima di toglierlo.

2. I file PHP

WP-CLI confronta i file del core di WordPress e dei plugin con i checksum pubblicati da WordPress.org, ed elenca ogni file modificato o aggiunto:

wp core verify-checksums
wp plugin verify-checksums --all

Il secondo comando copre i plugin distribuiti dalla directory di WordPress.org. Un plugin acquistato dal suo sviluppatore si confronta con una copia nuova scaricata dal vostro account presso di lui. È un caso frequente: sui 540 siti WordPress di PMI della nostra rilevazione del 1º settembre 2026, il 66 % porta almeno un plugin assente dalla directory pubblica.

Senza WP-CLI, due ricerche danno una prima selezione:

find . -name "*.php" -mtime -30
find wp-content/uploads -name "*.php"

La prima elenca i file PHP modificati negli ultimi 30 giorni, la seconda i file PHP presenti nella cartella dei media, dove sono sospetti per definizione (alcuni plugin vi mettono un index.php vuoto, che è legittimo). Una data di modifica si può falsificare: un file vecchio resta da esaminare se si trova nel posto sbagliato.

Aprite per primi wp-config.php, l'index.php della cartella principale, functions.php e header.php del tema attivo, e la cartella wp-content/mu-plugins: i plugin che vi si trovano si caricano automaticamente e non si disattivano dalla bacheca. I segnali da cercare: eval(, base64_decode(, gzinflate(, str_rot13(, lunghe stringhe illeggibili, oppure window.location seguito da un indirizzo che non conoscete.

3. Il database

Un reindirizzamento in JavaScript si inserisce volentieri nel contenuto delle pagine o nelle impostazioni, dove nessun file lo mostra. WP-CLI cerca una stringa in tutte le tabelle di WordPress:

wp db search "<script"
wp db search "fromCharCode"

Senza WP-CLI, le stesse ricerche si lanciano da phpMyAdmin, scheda SQL:

SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';
SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';

Alcuni risultati sono legittimi: uno strumento di statistiche, un banner dei cookie o un widget inserito da voi. Ciò che non corrisponde a nulla di quanto avete installato va esaminato, in particolare uno script che costruisce un indirizzo a partire da codici di caratteri.

4. Le impostazioni dell'indirizzo e gli account

In Impostazioni > Generali, «Indirizzo WordPress (URL)» e «Indirizzo sito (URL)» devono riportare il vostro dominio. Gli stessi valori possono essere imposti in wp-config.php dalle costanti WP_HOME e WP_SITEURL: controllate entrambi i punti.

wp option get home
wp option get siteurl
wp user list --role=administrator

Quando le costanti sono definite, i primi due comandi restituiscono il loro valore. L'ultimo elenca gli amministratori, con la data di registrazione; nella bacheca, lo stesso elenco si ottiene dal menu Utenti, filtrato sul ruolo Amministratore. Un account che nessuno riconosce si elimina, attribuendo i suoi contenuti a un account legittimo.

Rimuovere il reindirizzamento, poi l'accesso che lo ha inserito

Eliminare la riga che reindirizza ferma il sintomo. L'accesso usato dall'intruso, invece, resta aperto finché non viene trovato, e il reindirizzamento torna nei giorni successivi. L'ordine che regge:

1. Sostituite i file del core con una copia nuova: eliminate le cartelle wp-admin e wp-includes, poi lanciate wp core download --skip-content --force, che riscrive il core senza toccare plugin, temi e media. Il comando sovrascrive i file esistenti ma non elimina i file aggiunti: per questo le due cartelle si eliminano prima, e per questo i file PHP sconosciuti della cartella principale si tolgono a mano.
2. Reinstallate il tema e ogni plugin dalla loro fonte ufficiale, ed eliminate quelli che il sito non usa più, compresi quelli disattivati: i loro file restano sul server.
3. Togliete i file PHP estranei da wp-content/uploads, le regole aggiunte a .htaccess e gli script trovati nel database.
4. Controllate le operazioni pianificate con wp cron event list: un'operazione dal nome sconosciuto può reinserire il codice.
5. Aggiornate WordPress, il tema e i plugin.
6. Ripetete i test iniziali, da più dispositivi e per più giorni.

Se il sito conserva dati personali (moduli, account clienti, ordini), annotate l'ora in cui avete constatato l'attacco. Nell'Unione europea, il GDPR (regolamento generale sulla protezione dei dati) prevede di notificare una violazione dei dati personali all'autorità di controllo entro 72 ore dal momento in cui se ne è venuti a conoscenza, a meno che sia improbabile che la violazione presenti un rischio per i diritti e le libertà delle persone fisiche.

Google, e ciò che vedono i vostri visitatori

Quando Google rileva il reindirizzamento, Chrome può mostrare una pagina rossa «Sito pericoloso» prima di aprire il sito, e Google può scrivere sotto il vostro risultato «Questo sito potrebbe essere compromesso». Il report Problemi di sicurezza di Google Search Console dice che cosa è stato rilevato e su quali indirizzi. Una volta ripulito il sito, il pulsante Richiedi esame avvia la verifica.