Kort sagt: Om webbplatsen omdirigerar till främmande sidor sitter orsaken i ett av sex lager: DNS, CDN eller proxy, webbserverns konfiguration, PHP-kod, databas eller inkluderade skript. Eftersom många omdirigeringar bara slår till under vissa villkor bör ni testa riktat med olika identiteter och hänvisande sidor. Skydda först besökarna, säkra spår och stäng ingången efter borttagningen.
När kunder hamnar på tävlingssidor
Larmet kommer oftast utifrån. En kund skriver att han hamnade på en tävling eller en tvivelaktig butik när han öppnade er sida. Ni kontrollerar det på den egna datorn, och allt ser normalt ut. Det är ingen motsägelse utan avsikt: omdirigeringar efter ett intrång är byggda så att driftansvariga märker dem så sent som möjligt.
För ert företag är det känsligt. Besökare tappar förtroende, sökmotorer och webbläsare kan visa varningar, och på målsidorna väntar ibland bedrägeri eller skadlig programvara. En omdirigering är dessutom nästan aldrig det enda en angripare lämnar efter sig.
Efter PHP2Shell, sårbarheterna CVE-2026-109618 och CVE-2026-109619 med kodkörning utan inloggning, hör omdirigeringar till de synliga följder som driftansvariga bör ta på allvar. De är inget specifikt tecken på PHP2Shell, eftersom det inte finns några bekräftade Indicators of Compromise. Men de visar att någon har kunnat ändra innehåll på er webbplats.
Ofta kommer omdirigeringar inte ensamma. Den som omdirigerar besökare lägger ofta också upp spamsidor för sökmotorer för att fånga ännu mer trafik. Visar Google redan en varning för en hackad webbplats beskriver guiden Ta bort Googles varning vägen till omprövning. Främmande sidor i sökindexet behandlar inlägget SEO-spam och främmande sidor i Googles index.
Varför webbplatsen bara ibland omdirigerar
Villkorade omdirigeringar utvärderar kännetecken hos förfrågan. Ofta är det dessa:
- Ursprung: Bara den som kommer via ett sökresultat omdirigeras. Direkta anrop visar den normala sidan.
- Enhet: Bara mobila enheter eller vissa webbläsare berörs.
- Upprepning: Omdirigeringen slår till en gång per besökare, sätter sedan en cookie och tystnar.
- Inloggning: Den som är inloggad i CMS:et ser aldrig något.
- Tid eller slump: Omdirigeringen slår bara till vid en del av anropen.
Testa därför inte bara vid arbetsplatsen. Med en läsande förfrågan ser ni hur servern svarar på olika anrop:
# Vanligt anrop: statuskod och mål för en eventuell omdirigering
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.ihre-domain.de/
# Anrop som från en mobil enhet som kommer via en sökning
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/
Dyker ett främmande mål upp först vid den andra förfrågan sitter omdirigeringen på servern. Är båda oförargliga kan den ske i webbläsaren via JavaScript. Då hjälper en titt i den levererade sidans källkod eller i nätverksvyn i webbläsarens utvecklarverktyg, helst i ett privat fönster.
Webbplatsen omdirigerar: granska de sex lagren
Gå från utsidan och inåt. Så slipper ni leta i koden i timmar medan orsaken finns i en DNS-post:
| Lager | Typisk orsak | Kontroll |
|---|---|---|
| Domän och DNS | ändrad A-post eller namnserver | Jämför DNS-poster med det kända börvärdet, kontrollera åtkomsten hos registratorn |
| CDN eller proxy | främmande omdirigerings- eller sidregel | Gå igenom reglerna i leverantörens kundområde |
| Webbserver | regler i .htaccess eller serverkonfigurationen |
Sök efter Rewrite- och Redirect-regler med villkor |
| PHP-kod | extra kod i startfiler, mallar eller tillägg | Jämför kärnfiler med originalet |
| Databas | ändrade adressinställningar, skript i innehåll eller alternativ | Sök riktat efter främmande adresser och skript |
| Externa skript | komprometterad inbäddning från tredje part | Lista och bedöm inkluderade skriptkällor |
De yttre lagren hoppas gärna över eftersom de inte ligger på den egna servern. Just därför är de farliga: den som har tagit över kontot hos registratorn eller CDN-leverantören behöver ingen åtkomst till servern. Kontrollera där, vid sidan av reglerna, även vem som har åtkomst och om tvåfaktorsinloggning är aktiv.
För webbserverlagret passar läsande sökningar efter regler som reagerar på ursprung eller enhet:
# Omdirigeringsregler med villkor i alla .htaccess-filer
grep -rn --include='.htaccess' -iE 'Rewrite(Cond|Rule)|Redirect' /var/www/ihre-website
# Omdirigeringar i serverkonfigurationen (Apache och Nginx)
grep -rn -iE 'Rewrite|Redirect|return 30[12]' /etc/apache2/ /etc/nginx/ 2>/dev/null
För PHP-lagret beskriver Jämför CMS-kärnfiler med originalet tillvägagångssättet. För databasen lönar sig inlägget Kontrollera databasen efter inplanterad kod.
När orsaken ligger utanför servern
Inte varje omdirigering innebär en komprometterad server. Inkluderade skript från tredje part, till exempel för chatt, statistik eller reklam, körs direkt i besökarnas webbläsare. Komprometteras en sådan leverantör, eller löper en domän ut som er sida fortfarande laddar ett skript från, kan en omdirigering uppstå utan att någon fil på er server har ändrats.
En Content Security Policy begränsar från vilka källor webbläsaren får ladda skript och gör sådana fall synliga. Tips om det finns under Säkerhetsrubriker för webbplatser. Mycket sällan ligger orsaken hos besökaren själv: reklam- eller skadeprogram på hans dator omdirigerar då även på andra webbplatser.
Rätt ordning efter fyndet
- Skydda besökarna: Sätt webbplatsen i underhållsläge eller spärra de berörda delarna.
- Säkra spår: Kopiera misstänkta regler, filer och databasinnehåll med tidsstämpel innan ni tar bort dem.
- Ta bort: Åtgärda omdirigeringen och ersätt kärnfiler från en ren källa.
- Stäng ingången: Ta PHP till en rättad version, uppdatera CMS och tillägg, starta om alla workers och förnya åtkomsterna.
- Testa igen: Kontrollera på nytt med alla varianter från det andra avsnittet och följ Search Console.
En borttagen omdirigeringsregel är inget bevis för en ren webbplats. Kommer regeln tillbaka efter några dagar sitter det fortfarande en bakdörr någonstans som skriver den på nytt.
Hur hjälper PHP SOS konkret?
- Vi återskapar omdirigeringen med olika identiteter och hänvisande sidor och avgränsar lagret.
- Vi säkrar spår och tar bort omdirigeringar, skadlig kod och bakdörrar i filer, konfiguration och databas.
- Vid akut angrepp tar vår akuta hjälp vid hackade webbplatser hand om begränsningen tills incidenten är avslutad och dokumenterad.
- Vi granskar inkluderade skript från tredje part och rekommenderar en lämplig Content Security Policy.
Vanliga frågor
Varför ser jag inte omdirigeringen själv?
Många omdirigeringar slår bara till under vissa villkor: för besökare från Googles sökning, bara på mobila enheter, bara vid första besöket eller inte för inloggade administratörer. Testa därför med olika enheter, utan inloggning och via en länk från ett sökresultat.
Kan en omdirigering uppstå även utan intrång?
Ja. Ett utgånget tillägg, ett komprometterat externt skript, felaktiga DNS-poster eller skadlig programvara på besökarens dator kan ge liknande effekter. Ligger orsaken på den egna datorn uppträder omdirigeringen oftast även på andra webbplatser.
Var gömmer angripare oftast omdirigeringar?
Typiskt är regler i .htaccess eller serverkonfigurationen, extra kod i applikationens startfiler, ändrade adressinställningar i databasen och inplanterade JavaScript-snuttar i innehåll eller mallar.
Vad bör jag göra direkt om min webbplats omdirigerar?
Skydda besökarna, till exempel med ett underhållsläge, och säkra spår innan ni raderar något. Leta sedan lager för lager efter orsaken och stäng ingången. En borttagen regel utan stängd sårbarhet kommer oftast tillbaka.