Pe scurt: Când site-ul redirecționează către pagini străine, cauza se află în unul dintre șase straturi: DNS, CDN sau proxy, configurația serverului web, codul PHP, baza de date sau scripturile incluse. Deoarece multe redirecționări se activează doar în anumite condiții, testați țintit cu identificatori și pagini de proveniență diferite. Protejați mai întâi vizitatorii, păstrați urmele și, după eliminare, închideți punctul de intrare.
Când clienții ajung pe pagini cu premii
Semnalarea vine de obicei din exterior. Un client scrie că, la accesarea paginii dumneavoastră, a ajuns pe un site cu premii sau într-un magazin discutabil. Verificați pe propriul calculator, iar totul pare normal. Nu este o contradicție, ci intenție: redirecționările de după un atac sunt construite astfel încât operatorii să le observe cât mai târziu.
Pentru firma dumneavoastră situația este delicată. Vizitatorii pierd încrederea, motoarele de căutare și browserele pot afișa avertismente, iar pe paginile-țintă îi așteaptă uneori fraudă sau software malițios. În plus, o redirecționare este aproape niciodată singurul lucru lăsat în urmă de un atacator.
După PHP2Shell, vulnerabilitățile CVE-2026-109618 și CVE-2026-109619, cu execuție de cod fără autentificare, redirecționările se numără printre consecințele vizibile pe care operatorii ar trebui să le ia în serios. Ele nu sunt un indiciu specific PHP2Shell, deoarece nu există Indicators of Compromise confirmați. Dar arată că cineva a putut modifica conținutul site-ului dumneavoastră.
Adesea redirecționările nu vin singure. Cine redirecționează vizitatorii creează, în plus, adesea pagini de spam pentru motoarele de căutare, pentru a prelua și mai mult trafic. Dacă Google afișează deja o indicație privind un site compromis, ghidul Eliminarea avertismentului Google descrie calea spre reexaminare. Paginile străine din indexul de căutare sunt tratate în articolul Spam SEO și pagini străine în indexul Google.
De ce site-ul redirecționează doar uneori
Redirecționările condiționate evaluează caracteristici ale cererii. Cel mai des sunt acestea:
- Proveniența: Este redirecționat doar cine vine dintr-un rezultat de căutare. Accesările directe arată pagina normală.
- Dispozitivul: Sunt afectate doar dispozitivele mobile sau anumite browsere.
- Repetarea: Redirecționarea se activează o singură dată pentru fiecare vizitator, apoi setează un cookie și tace.
- Autentificarea: Cine este autentificat în CMS nu vede niciodată nimic.
- Timpul sau întâmplarea: Redirecționarea se activează doar la o parte dintre accesări.
Nu testați de aceea doar de la locul dumneavoastră de muncă. Cu o interogare doar de citire vedeți cum răspunde serverul la accesări diferite:
# Accesare normală: codul de stare și ținta unei eventuale redirecționări
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.ihre-domain.de/
# Accesare ca de pe un dispozitiv mobil care vine dintr-o căutare
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/
Dacă o țintă străină apare doar la a doua interogare, redirecționarea se află pe server. Dacă ambele rămân neobservabile, ea se poate produce în browser, prin JavaScript. Atunci ajută o privire în codul sursă al paginii livrate sau în vizualizarea de rețea din instrumentele pentru dezvoltatori ale browserului, cel mai bine într-o fereastră privată.
Site-ul redirecționează: verificarea celor șase straturi
Procedați din exterior spre interior. Astfel evitați să căutați ore întregi în cod, în timp ce cauza se află într-o înregistrare DNS:
| Strat | Cauză tipică | Verificare |
|---|---|---|
| Domeniu și DNS | înregistrare A sau server de nume modificate | comparați înregistrările DNS cu starea cunoscută corectă, verificați accesul la registrar |
| CDN sau proxy | regulă străină de redirecționare sau de pagină | parcurgeți regulile din zona de client a furnizorului |
| Server web | reguli în .htaccess sau în configurația serverului |
căutați reguli Rewrite și Redirect cu condiții |
| Cod PHP | cod suplimentar în fișiere de intrare, șabloane sau extensii | comparați fișierele de bază cu originalul |
| Baza de date | setări de adresă modificate, scripturi în conținut sau opțiuni | căutați țintit adrese și scripturi străine |
| Scripturi externe | includere compromisă de la un terț | enumerați și evaluați sursele de scripturi incluse |
Straturile exterioare sunt omise bucuros, pentru că nu se află pe propriul server. Tocmai de aceea sunt periculoase: cine a preluat contul de la registrar sau de la furnizorul de CDN nu are nevoie de acces la server. Verificați acolo, pe lângă reguli, cine are acces și dacă autentificarea în doi factori este activă.
Pentru stratul serverului web sunt potrivite căutările doar de citire după reguli care reacționează la proveniență sau la dispozitiv:
# Reguli de redirecționare cu condiții în toate fișierele .htaccess
grep -rn --include='.htaccess' -iE 'Rewrite(Cond|Rule)|Redirect' /var/www/ihre-website
# Redirecționări în configurația serverului (Apache și Nginx)
grep -rn -iE 'Rewrite|Redirect|return 30[12]' /etc/apache2/ /etc/nginx/ 2>/dev/null
Pentru stratul PHP, Compararea fișierelor de bază ale CMS-ului cu originalul descrie procedura. Pentru baza de date merită articolul Verificarea bazei de date pentru cod introdus.
Când cauza se află în afara serverului
Nu orice redirecționare înseamnă un server compromis. Scripturile incluse de la terți, de exemplu pentru chat, statistici sau publicitate, sunt executate direct în browserul vizitatorilor. Dacă un astfel de furnizor este compromis sau expiră un domeniu de pe care pagina dumneavoastră încă încarcă un script, prin el poate apărea o redirecționare, fără ca vreun fișier să fi fost modificat pe serverul dumneavoastră.
O Content Security Policy limitează sursele din care browserul are voie să încarce scripturi și face vizibile astfel de cazuri. Indicații în acest sens găsiți la Antete de securitate pentru site-uri. Foarte rar, cauza se află la vizitatorul însuși: software publicitar sau malițios pe calculatorul lui redirecționează atunci și pe alte site-uri.
Ordinea corectă după descoperire
- Protejați vizitatorii: Puneți site-ul în modul de întreținere sau blocați zonele afectate.
- Păstrați urmele: Copiați cu marcaj de timp regulile, fișierele și conținutul bazei de date suspecte, înainte să le eliminați.
- Eliminați: Înlăturați redirecționarea și înlocuiți fișierele de bază dintr-o sursă curată.
- Închideți punctul de intrare: Aduceți PHP la o versiune corectată, actualizați CMS-ul și extensiile, reporniți toți workerii, reînnoiți accesurile.
- Retestați: Verificați din nou cu toate variantele din a doua secțiune și urmăriți Search Console.
O regulă de redirecționare eliminată nu este o dovadă că site-ul este curat. Dacă regula revine după câteva zile, undeva mai există o ușă dosnică, care o rescrie.
Cum ajută PHP SOS concret?
- Reproducem redirecționarea cu identificatori și pagini de proveniență diferite și delimităm stratul.
- Păstrăm urmele și eliminăm redirecționările, codul malițios și ușile dosnice din fișiere, configurație și baza de date.
- În caz de infectare acută, asistența de urgență pentru site-uri compromise preia izolarea, până când incidentul este încheiat și documentat.
- Verificăm scripturile incluse de la terți și recomandăm o Content Security Policy potrivită.
Întrebări frecvente
De ce nu văd eu însumi redirecționarea?
Multe redirecționări se activează doar în anumite condiții: pentru vizitatorii veniți din căutarea Google, doar pe dispozitive mobile, doar la prima vizită sau nu pentru administratorii autentificați. Testați de aceea cu dispozitive diferite, fără autentificare și printr-un link dintr-un rezultat de căutare.
Poate apărea o redirecționare și fără un atac?
Da. Un plugin expirat, un script extern compromis, înregistrări DNS greșite sau software malițios pe calculatorul vizitatorului pot avea efecte asemănătoare. Dacă cauza se află pe calculatorul propriu, redirecționarea apare de obicei și pe alte site-uri.
Unde ascund atacatorii cel mai des redirecționările?
Tipice sunt regulile din .htaccess sau din configurația serverului, codul suplimentar din fișierele de intrare ale aplicației, setările de adresă modificate în baza de date și fragmentele JavaScript introduse în conținut sau în șabloane.
Ce ar trebui să fac imediat dacă site-ul meu redirecționează?
Protejați vizitatorii, de exemplu printr-un mod de întreținere, și păstrați urmele înainte să ștergeți ceva. Apoi căutați cauza strat cu strat și închideți punctul de intrare. O regulă eliminată, fără ca vulnerabilitatea să fie închisă, revine de obicei.