In breve: quando il sito reindirizza verso pagine estranee, la causa si trova in uno di sei strati: DNS, CDN o proxy, configurazione del server web, codice PHP, database o script incorporati. Poiché molti reindirizzamenti scattano solo a certe condizioni, provi in modo mirato con identificativi e pagine di provenienza diversi. Protegga anzitutto i visitatori, conservi le tracce e, dopo la rimozione, chiuda il punto d'ingresso.
Quando i clienti finiscono su pagine di concorsi a premi
La segnalazione arriva di solito dall'esterno. Un cliente scrive di essere finito, aprendo la Sua pagina, su un concorso a premi o su un negozio discutibile. Lei controlla dal proprio computer e tutto sembra normale. Non è una contraddizione, ma un'intenzione: i reindirizzamenti dopo un attacco sono costruiti in modo che i gestori li notino il più tardi possibile.
Per la Sua azienda è una situazione delicata. I visitatori perdono fiducia, motori di ricerca e browser possono mostrare avvisi e sulle pagine di destinazione talvolta attendono truffe o software dannoso. Inoltre un reindirizzamento non è quasi mai l'unica cosa che un aggressore lascia.
Dopo PHP2Shell, le vulnerabilità CVE-2026-109618 e CVE-2026-109619 con esecuzione di codice senza autenticazione, i reindirizzamenti rientrano tra le conseguenze visibili che i gestori dovrebbero prendere sul serio. Non sono un indizio specifico di PHP2Shell, perché non esistono Indicators of Compromise confermati. Ma mostrano che qualcuno ha potuto modificare i contenuti del Suo sito.
Spesso i reindirizzamenti non arrivano da soli. Chi reindirizza i visitatori crea di frequente anche pagine di spam per i motori di ricerca, per intercettare ancora più traffico. Se Google mostra già un avviso su un sito violato, la guida rimuovere l'avviso di Google descrive la via per la verifica. Le pagine estranee nell'indice di ricerca sono trattate dall'articolo SEO spam e pagine estranee nell'indice Google.
Perché il sito reindirizza solo a volte
I reindirizzamenti condizionati valutano caratteristiche della richiesta. Di frequente sono queste:
- Provenienza: viene reindirizzato solo chi arriva da un risultato di ricerca. Le chiamate dirette mostrano la pagina normale.
- Dispositivo: sono interessati solo i dispositivi mobili o determinati browser.
- Ripetizione: il reindirizzamento scatta una volta per visitatore, poi imposta un cookie e tace.
- Accesso: chi è connesso al CMS non vede mai nulla.
- Tempo o caso: il reindirizzamento scatta solo per una parte delle chiamate.
Non provi quindi solo dalla Sua postazione. Con una richiesta in sola lettura vede come il server risponde a chiamate diverse:
# Chiamata normale: codice di stato e destinazione di un possibile reindirizzamento
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.ihre-domain.de/
# Chiamata come da un dispositivo mobile che arriva da una ricerca
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
-A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 Mobile/15E148" \
-e "https://www.google.com/" https://www.ihre-domain.de/
Se una destinazione estranea compare solo nella seconda richiesta, il reindirizzamento si trova sul server. Se entrambe sono nella norma, può avvenire nel browser tramite JavaScript. In tal caso è utile guardare il codice sorgente della pagina consegnata o la vista di rete degli strumenti per sviluppatori del browser, meglio in una finestra privata.
Il sito reindirizza: verificare i sei strati
Proceda dall'esterno verso l'interno. Così evita di cercare per ore nel codice mentre la causa è in un record DNS:
| Strato | Causa tipica | Verifica |
|---|---|---|
| Dominio e DNS | record A o name server modificato | confrontare i record DNS con il valore atteso noto, verificare l'accesso al registrar |
| CDN o proxy | regola estranea di reindirizzamento o di pagina | esaminare le regole nell'area clienti del fornitore |
| Server web | regole in .htaccess o nella configurazione del server |
cercare regole Rewrite e Redirect con condizioni |
| Codice PHP | codice aggiuntivo in file di ingresso, template o estensioni | confrontare i file core con l'originale |
| Database | impostazioni di indirizzo modificate, script nei contenuti o nelle opzioni | cercare in modo mirato indirizzi e script estranei |
| Script esterni | integrazione di terze parti compromessa | elencare e valutare le sorgenti degli script incorporati |
Gli strati esterni vengono volentieri saltati perché non si trovano sul proprio server. Proprio per questo sono pericolosi: chi ha preso il controllo dell'account presso il registrar o presso il fornitore di CDN non ha bisogno di accedere al server. Controlli lì, oltre alle regole, anche chi ha accesso e se l'autenticazione a due fattori è attiva.
Per lo strato del server web sono adatte ricerche in sola lettura di regole che reagiscono a provenienza o dispositivo:
# Regole di reindirizzamento con condizioni in tutti i file .htaccess
grep -rn --include='.htaccess' -iE 'Rewrite(Cond|Rule)|Redirect' /var/www/ihre-website
# Reindirizzamenti nella configurazione del server (Apache e Nginx)
grep -rn -iE 'Rewrite|Redirect|return 30[12]' /etc/apache2/ /etc/nginx/ 2>/dev/null
Per lo strato PHP, Confrontare i file core del CMS con l'originale descrive la procedura. Per il database vale l'articolo Verificare la presenza di codice iniettato nel database.
Quando la causa è fuori dal server
Non ogni reindirizzamento significa un server compromesso. Gli script di terze parti incorporati, ad esempio per chat, statistiche o pubblicità, vengono eseguiti direttamente nel browser dei visitatori. Se un fornitore di questo tipo viene compromesso, o scade un dominio da cui la Sua pagina carica ancora uno script, può nascere un reindirizzamento senza che sul Suo server sia stato modificato alcun file.
Una Content Security Policy limita da quali fonti il browser può caricare script e rende visibili casi simili. Indicazioni si trovano in Header di sicurezza per i siti web. Molto raramente la causa è il visitatore stesso: software pubblicitario o dannoso sul suo computer reindirizza allora anche su altri siti.
L'ordine giusto dopo la scoperta
- Proteggere i visitatori: mettere il sito in modalità di manutenzione o bloccare le aree interessate.
- Conservare le tracce: copiare con data e ora regole, file e contenuti del database sospetti prima di rimuoverli.
- Rimuovere: eliminare il reindirizzamento e sostituire i file core con una fonte pulita.
- Chiudere il punto d'ingresso: portare PHP a una versione corretta, aggiornare CMS ed estensioni, riavviare tutti i worker, rinnovare gli accessi.
- Ritestare: verificare di nuovo con tutte le varianti della seconda sezione e osservare la Search Console.
Una regola di reindirizzamento rimossa non è la prova di un sito pulito. Se la regola ritorna dopo giorni, da qualche parte c'è ancora una backdoor che la riscrive.
Come aiuta PHP SOS in concreto?
- Riproduciamo il reindirizzamento con identificativi e pagine di provenienza diversi e circoscriviamo lo strato.
- Conserviamo le tracce e rimuoviamo reindirizzamenti, codice dannoso e backdoor in file, configurazione e database.
- In caso di compromissione acuta, il nostro intervento di emergenza per siti violati si occupa del contenimento finché l'incidente non è chiuso e documentato.
- Verifichiamo gli script di terze parti incorporati e consigliamo una Content Security Policy adeguata.
Domande frequenti
Perché non vedo io stesso il reindirizzamento?
Molti reindirizzamenti scattano solo a certe condizioni: per i visitatori provenienti dalla ricerca di Google, solo sui dispositivi mobili, solo alla prima visita o non per gli amministratori connessi. Provi quindi con dispositivi diversi, senza accedere e tramite il link di un risultato di ricerca.
Un reindirizzamento può nascere anche senza un attacco?
Sì. Un plugin scaduto, uno script esterno compromesso, record DNS errati o software dannoso sul computer del visitatore possono avere effetti simili. Se la causa è sul proprio computer, il reindirizzamento di norma compare anche su altri siti.
Dove nascondono più spesso i reindirizzamenti gli aggressori?
Tipiche sono le regole in .htaccess o nella configurazione del server, codice aggiuntivo nei file di ingresso dell'applicazione, impostazioni di indirizzo modificate nel database e frammenti JavaScript iniettati nei contenuti o nei template.
Che cosa devo fare subito se il mio sito reindirizza?
Proteggere i visitatori, ad esempio con una modalità di manutenzione, e conservare le tracce prima di cancellare qualsiasi cosa. Poi cercare la causa strato per strato e chiudere il punto d'ingresso. Una regola rimossa senza chiudere la falla di solito ritorna.