Krótko: Gdy strona przekierowuje na obce witryny, przyczyna leży w jednej z sześciu warstw: DNS, CDN lub proxy, konfiguracja serwera WWW, kod PHP, baza danych albo dołączone skrypty. Ponieważ wiele przekierowań działa tylko pod pewnymi warunkami, proszę testować celowo z różnymi identyfikatorami i stronami źródłowymi. Najpierw należy chronić odwiedzających, zabezpieczyć ślady, a po usunięciu przekierowania zamknąć furtkę, którą wszedł atakujący.
Gdy klienci trafiają na strony z konkursami
Zgłoszenie zwykle przychodzi z zewnątrz. Klient pisze, że po wejściu na Państwa stronę trafił na konkurs lub wątpliwy sklep. Sprawdzają Państwo to na własnym komputerze i wszystko wygląda normalnie. To nie sprzeczność, lecz zamierzone działanie: przekierowania po włamaniu są zbudowane tak, aby operatorzy zauważyli je jak najpóźniej.
Dla Państwa firmy to sytuacja delikatna. Odwiedzający tracą zaufanie, wyszukiwarki i przeglądarki mogą wyświetlać ostrzeżenia, a na stronach docelowych czasem czyhają oszustwa lub złośliwe oprogramowanie. Przekierowanie jest przy tym prawie nigdy jedynym, co zostawia po sobie atakujący.
Po PHP2Shell, czyli lukach CVE-2026-109618 i CVE-2026-109619 umożliwiających wykonanie kodu bez logowania, przekierowania należą do widocznych skutków, które operatorzy powinni traktować poważnie. Nie są one specyficzną wskazówką dotyczącą PHP2Shell, ponieważ potwierdzonych wskaźników włamania (Indicators of Compromise) nie ma. Pokazują jednak, że ktoś mógł zmieniać treści Państwa strony.
Przekierowania często nie występują samotnie. Kto przekierowuje odwiedzających, zwykle zakłada też strony spamowe dla wyszukiwarek, by przechwycić jeszcze więcej ruchu. Jeśli Google wyświetla już informację o zhakowanej stronie, poradnik Usuwanie ostrzeżenia Google opisuje drogę do ponownej weryfikacji. Obce strony w indeksie wyszukiwarki omawia artykuł SEO spam i obce strony w indeksie Google.
Dlaczego strona przekierowuje tylko czasami
Warunkowe przekierowania analizują cechy żądania. Najczęściej są to:
- Źródło: przekierowywany jest tylko ten, kto przychodzi z wyników wyszukiwania. Bezpośrednie wejścia pokazują normalną stronę.
- Urządzenie: dotyczy to tylko urządzeń mobilnych lub określonych przeglądarek.
- Powtórzenie: przekierowanie działa raz na odwiedzającego, potem ustawia ciasteczko i milczy.
- Logowanie: kto jest zalogowany w CMS, nigdy nic nie widzi.
- Czas lub przypadek: przekierowanie działa tylko przy części wywołań.
Dlatego proszę nie testować wyłącznie na własnym stanowisku. Za pomocą zapytania tylko do odczytu zobaczą Państwo, jak serwer odpowiada na różne wywołania:
# Zwykłe wywołanie: kod statusu i cel ewentualnego przekierowania
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.ihre-domain.de/
# Wywołanie jak z urządzenia mobilnego, które przychodzi z wyszukiwarki
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/
Jeśli obcy cel pojawia się tylko przy drugim zapytaniu, przekierowanie siedzi na serwerze. Jeśli oba wyglądają normalnie, może następować w przeglądarce za pomocą JavaScriptu. Wtedy pomoże wgląd w kod źródłowy wyświetlanej strony lub w widok sieci w narzędziach deweloperskich przeglądarki, najlepiej w oknie prywatnym.
Strona przekierowuje: sprawdzanie sześciu warstw
Proszę działać od zewnątrz do wewnątrz. Unikną Państwo w ten sposób godzin szukania w kodzie, podczas gdy przyczyna leży we wpisie DNS:
| Warstwa | Typowa przyczyna | Sprawdzenie |
|---|---|---|
| Domena i DNS | zmieniony wpis A lub serwer nazw | porównać wpisy DNS ze znanym stanem właściwym, sprawdzić dostęp do rejestratora |
| CDN lub proxy | obca reguła przekierowania lub strony | przejrzeć reguły w panelu klienta dostawcy |
| Serwer WWW | reguły w .htaccess lub konfiguracji serwera |
szukać reguł Rewrite i Redirect z warunkami |
| Kod PHP | dodatkowy kod w plikach wejściowych, szablonach lub rozszerzeniach | porównać pliki rdzenia z oryginałem |
| Baza danych | zmienione ustawienia adresów, skrypty w treściach lub opcjach | szukać celowo obcych adresów i skryptów |
| Skrypty zewnętrzne | przejęte dołączenie od zewnętrznego dostawcy | wypisać dołączane źródła skryptów i je ocenić |
Zewnętrzne warstwy chętnie się pomija, bo nie leżą na własnym serwerze. Właśnie dlatego są niebezpieczne: kto przejął konto u rejestratora lub dostawcy CDN, nie potrzebuje dostępu do serwera. Proszę tam sprawdzić nie tylko reguły, lecz także to, kto ma dostęp i czy włączone jest uwierzytelnianie dwuskładnikowe.
Dla warstwy serwera WWW nadają się wyszukiwania tylko do odczytu reguł, które reagują na źródło lub urządzenie:
# Reguły przekierowania z warunkami we wszystkich plikach .htaccess
grep -rn --include='.htaccess' -iE 'Rewrite(Cond|Rule)|Redirect' /var/www/ihre-website
# Przekierowania w konfiguracji serwera (Apache i Nginx)
grep -rn -iE 'Rewrite|Redirect|return 30[12]' /etc/apache2/ /etc/nginx/ 2>/dev/null
Dla warstwy PHP postępowanie opisuje artykuł Porównywanie plików rdzenia CMS z oryginałem. Dla bazy danych warto przeczytać artykuł Sprawdzanie bazy danych pod kątem wstrzykniętego kodu.
Gdy przyczyna leży poza serwerem
Nie każde przekierowanie oznacza przejęty serwer. Dołączane skrypty zewnętrznych dostawców, na przykład do czatu, statystyk lub reklam, są wykonywane bezpośrednio w przeglądarce odwiedzających. Jeśli taki dostawca zostanie przejęty albo wygaśnie domena, z której Państwa strona nadal ładuje skrypt, przekierowanie może powstać bez zmiany jakiegokolwiek pliku na Państwa serwerze.
Content Security Policy ogranicza, z jakich źródeł przeglądarka może ładować skrypty, i czyni takie przypadki widocznymi. Wskazówki znajdują się w artykule Nagłówki bezpieczeństwa dla stron WWW. Bardzo rzadko przyczyna leży po stronie samego odwiedzającego: oprogramowanie reklamowe lub złośliwe na jego komputerze przekierowuje wtedy także na innych stronach.
Właściwa kolejność po wykryciu
- Chronić odwiedzających: przełączyć stronę w tryb konserwacji lub zablokować dotknięte obszary.
- Zabezpieczyć ślady: skopiować podejrzane reguły, pliki i zawartość bazy danych ze znacznikiem czasu, zanim zostaną usunięte.
- Usunąć: wyeliminować przekierowanie i zastąpić pliki rdzenia czystymi z wiarygodnego źródła.
- Zamknąć furtkę: doprowadzić PHP do naprawionej wersji, zaktualizować CMS i rozszerzenia, zrestartować wszystkie procesy robocze, odnowić dostępy.
- Przetestować ponownie: sprawdzić jeszcze raz wszystkimi wariantami z drugiego rozdziału i obserwować Search Console.
Usunięta reguła przekierowania nie jest dowodem na czystą stronę. Jeśli reguła wróci po kilku dniach, gdzieś nadal siedzi tylna furtka, która zapisuje ją na nowo.
Jak konkretnie pomaga PHP SOS?
- Odtwarzamy przekierowanie z różnymi identyfikatorami i stronami źródłowymi oraz zawężamy warstwę, w której występuje.
- Zabezpieczamy ślady i usuwamy przekierowania, złośliwy kod i tylne furtki w plikach, konfiguracji i bazie danych.
- W przypadku ostrego zainfekowania nasza pomoc awaryjna przy zhakowanych stronach przejmuje powstrzymanie ataku, aż incydent zostanie zamknięty i udokumentowany.
- Sprawdzamy dołączone skrypty zewnętrznych dostawców i zalecamy odpowiednią Content Security Policy.
Częste pytania
Dlaczego sam nie widzę przekierowania?
Wiele przekierowań działa tylko w określonych warunkach: dla odwiedzających z wyszukiwarki Google, tylko na urządzeniach mobilnych, tylko przy pierwszej wizycie albo nie dla zalogowanych administratorów. Dlatego proszę testować na różnych urządzeniach, bez logowania i przez link z wyników wyszukiwania.
Czy przekierowanie może powstać także bez włamania?
Tak. Podobne skutki mogą mieć wygasły wtyczka, przejęty zewnętrzny skrypt, błędne wpisy DNS lub złośliwe oprogramowanie na komputerze odwiedzającego. Jeśli przyczyna leży na własnym komputerze, przekierowanie zwykle występuje także na innych stronach.
Gdzie atakujący najczęściej ukrywają przekierowania?
Typowe są reguły w .htaccess lub konfiguracji serwera, dodatkowy kod w plikach wejściowych aplikacji, zmienione ustawienia adresów w bazie danych oraz wstrzyknięte fragmenty JavaScriptu w treściach lub szablonach.
Co powinienem zrobić od razu, gdy moja strona przekierowuje?
Chronić odwiedzających, na przykład trybem konserwacji, i zabezpieczyć ślady, zanim cokolwiek zostanie usunięte. Następnie szukać przyczyny warstwa po warstwie i zamknąć furtkę. Usunięta reguła bez zamkniętej luki zwykle wraca.