Site WordPress care redirecționează către alt site: găsiți redirecționarea

De ce nu vedeți redirecționarea

O redirecționare pusă în timpul unei spargeri își alege cui i se aplică. De cele mai multe ori o ocolește pe persoana care administrează site-ul, ca să rămână pe loc cât mai mult timp. Condițiile cele mai frecvente:

• Proveniența: sunt redirecționați doar vizitatorii care vin de la un motor de căutare sau de pe o rețea socială. Codul citește antetul Referer al cererii.
• Dispozitivul: sunt redirecționate doar telefoanele. Codul citește antetul User-Agent.
• Autentificarea: un administrator conectat la WordPress vede site-ul normal.
• Prima vizită: un cookie reține că vizitatorul a fost deja redirecționat, iar vizita următoare decurge normal. Defecțiunea pare atunci intermitentă.

Un mesaj de la un client care spune „site-ul dumneavoastră mă trimite în altă parte” merită deci luat în serios, chiar dacă la dumneavoastră totul se afișează corect.

Reproduceți redirecționarea

Puneți-vă în locul vizitatorului care o întâlnește:

1. Deschideți o fereastră de navigare privată, căutați numele firmei dumneavoastră într-un motor de căutare și dați clic pe rezultatul dumneavoastră.
2. Repetați de pe un telefon, pe date mobile în loc de Wi-Fi.
3. Notați adresa de destinație, ora și dispozitivul: aceste trei informații îi folosesc furnizorului de găzduire și, mai târziu, cererii de examinare adresate Google.

Dacă aveți acces la un terminal, această comandă cere pagina de pornire a site-ului prezentându-se ca un iPhone venit de pe 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.site-ul-dumneavoastra.com/

Citiți primele rânduri ale răspunsului. Un cod 301 sau 302 urmat de un rând Location: către o adresă necunoscută semnalează o redirecționare făcută de server: se află în .htaccess sau într-un fișier PHP. Un cod 200, în timp ce browserul este redirecționat, semnalează o redirecționare făcută în pagină, în JavaScript: se află de cele mai multe ori în baza de date sau într-un fișier al temei.

Înainte de a atinge site-ul: trei gesturi

1. O copie completă în starea actuală. Fișiere și bază de date, datată, păstrată în afara serverului. Servește drept dovadă, drept punct de comparație și drept plasă de siguranță dacă o curățare scoate ceva util.
2. Parolele, de pe un dispozitiv neinfectat. Contul de client la furnizorul de găzduire, conturile FTP sau SFTP, utilizatorul bazei de date (treceți noua parolă în wp-config.php, constanta DB_PASSWORD), apoi fiecare cont de administrator WordPress.
3. Cheile de securitate. Înlocuiți cele opt rânduri de la AUTH_KEY la NONCE_SALT din wp-config.php cu un set nou, generat la https://api.wordpress.org/secret-key/1.1/salt/. Toate sesiunile deschise sunt închise, inclusiv cea a intrusului.

wp config shuffle-salts

Unde se ascunde redirecționarea

1. Fișierul .htaccess

La rădăcina site-ului, și uneori într-un subdosar, .htaccess poate primi reguli de rescriere adăugate de intrus. Blocul pe care WordPress îl scrie singur este scurt, încadrat de # BEGIN WordPress și # END WordPress:

# BEGIN WordPress
# Directivele (liniile) între „BEGIN WordPress” și „END WordPress” sunt
# generate dinamic și ar trebui modificate numai prin filtrele WordPress.
# Toate modificările la directivele cuprinse între acești marcatori vor fi suprascrise.
<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

O regulă RewriteCond care testează %{HTTP_REFERER} (google, bing, facebook) sau %{HTTP_USER_AGENT} (android, iphone, mobile), urmată de o RewriteRule către o adresă externă, este redirecționarea. Modulele de cache și de securitate își scriu și ele propriile blocuri, marcate cu numele lor: comparați fiecare bloc cu lista modulelor dumneavoastră înainte de a-l elimina.

2. Fișierele PHP

WP-CLI compară fișierele nucleului WordPress și ale modulelor cu sumele de control publicate de WordPress.org și listează fiecare fișier modificat sau adăugat:

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

A doua comandă acoperă modulele distribuite prin directorul WordPress.org. Un modul cumpărat de la editorul său se compară cu o copie proaspătă, descărcată din contul dumneavoastră de la acesta. Este un caz frecvent: din cele 540 de site-uri WordPress ale IMM-urilor din măsurarea noastră din 1 septembrie 2026, 66 % poartă cel puțin un modul absent din directorul public.

Fără WP-CLI, două căutări fac o primă triere:

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

Prima listează fișierele PHP modificate în ultimele 30 de zile, a doua fișierele PHP aflate în dosarul de fișiere media, unde sunt suspecte din principiu (unele module pun acolo un index.php gol, care este legitim). O dată de modificare se poate falsifica: un fișier vechi rămâne de examinat dacă se află în locul greșit.

Deschideți mai întâi wp-config.php, index.php de la rădăcină, functions.php și header.php ale temei active și dosarul wp-content/mu-plugins: modulele care se află acolo se încarcă automat și nu se dezactivează din administrare. Semnele de căutat: eval(, base64_decode(, gzinflate(, str_rot13(, șiruri lungi ilizibile sau window.location urmat de o adresă pe care nu o cunoașteți.

3. Baza de date

O redirecționare în JavaScript se strecoară ușor în conținutul paginilor sau în setări, unde niciun fișier nu o arată. WP-CLI caută un șir de caractere în toate tabelele WordPress:

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

Fără WP-CLI, aceleași căutări se lansează în phpMyAdmin, în fila SQL:

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

Unele rezultate sunt legitime: un instrument de măsurare a audienței, un banner de cookie-uri sau un widget pus de dumneavoastră. Ce nu corespunde cu nimic din ce ați instalat este de examinat, în special un script care construiește o adresă pornind de la coduri de caractere.

4. Setările de adresă și conturile

În Setări > Generale, „Adresă WordPress (URL)” și „Adresă site (URL)” trebuie să conțină domeniul dumneavoastră. Aceleași valori pot fi impuse în wp-config.php prin constantele WP_HOME și WP_SITEURL: verificați ambele locuri.

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

Când constantele sunt definite, primele două comenzi returnează valoarea lor. Ultima listează administratorii, cu data înregistrării; în administrare, aceeași listă se obține din meniul Utilizatori, filtrată pe rolul Administrator. Un cont pe care nu îl recunoaște nimeni se șterge, atribuind conținuturile lui unui cont legitim.

Eliminați redirecționarea, apoi accesul care a pus-o

Ștergerea rândului care redirecționează oprește simptomul. Accesul folosit de intrus rămâne însă deschis cât timp nu a fost găsit, iar redirecționarea revine în zilele următoare. Ordinea care ține:

1. Înlocuiți fișierele nucleului cu o copie nouă: ștergeți dosarele wp-admin și wp-includes, apoi rulați wp core download --skip-content --force, care rescrie nucleul fără să atingă modulele, temele și fișierele media. Comanda suprascrie fișierele existente, dar nu șterge fișierele adăugate: de aceea cele două dosare se șterg mai întâi, iar fișierele PHP necunoscute de la rădăcină se elimină manual.
2. Reinstalați tema și fiecare modul din sursa lor oficială și ștergeți-le pe cele pe care site-ul nu le mai folosește, inclusiv pe cele dezactivate: fișierele lor rămân pe server.
3. Eliminați fișierele PHP străine din wp-content/uploads, regulile adăugate în .htaccess și scripturile găsite în baza de date.
4. Verificați sarcinile programate cu wp cron event list: o sarcină cu nume necunoscut poate pune codul la loc.
5. Actualizați WordPress, tema și modulele.
6. Refaceți testele de la început, de pe mai multe dispozitive și timp de mai multe zile.

Dacă site-ul păstrează date cu caracter personal (formulare, conturi de clienți, comenzi), notați ora la care ați constatat spargerea. În Uniunea Europeană, Regulamentul general privind protecția datelor (GDPR) prevede notificarea încălcării securității datelor cu caracter personal către autoritatea de supraveghere în termen de cel mult 72 de ore de la data la care ați luat cunoștință de aceasta, cu excepția cazului în care este puțin probabil să genereze un risc pentru drepturile și libertățile persoanelor fizice.

Google și ce văd vizitatorii dumneavoastră

Când Google detectează redirecționarea, Chrome poate afișa o pagină roșie „Site periculos” înainte de a deschide site-ul, iar Google poate scrie sub rezultatul dumneavoastră „Este posibil ca acest site să fie compromis”. Raportul Probleme de securitate din Google Search Console arată ce a fost detectat și pe ce adrese. După curățarea site-ului, cererea de examinare, trimisă din același raport, pornește verificarea.