Drei kostenlose Website-Security-Scanner liefern drei verschiedene Ergebnisse — woran halten?

Die JavaScript-Warnung des zweiten Tools deutet sehr wahrscheinlich auf einen Conditional-Redirect hin. Schadcode versteckt sich oft vor eingeloggten Admins und springt nur an, wenn der Referer-Header von Google kommt. Zieht euch den Quelltext mal übers Terminal via curl mit verschiedenen User-Agents und Referern. Sucht in den Dateien nach verdächtigen Funktionen wie eval, base64_decode oder document.write.

Erstmal keine Panik, prüft am besten zwei Dinge: Erstens in der Google Search Console unter „Sicherheitsprobleme“ nachsehen; falls Google was entdeckt hat, steht es dort schwarz auf weiß. Zweitens das Datum des letzten sauberen Backups herausfinden. Wenn das Problem erst seit ein paar Tagen besteht ist ein Abgleich mit dem Backup meistens der schnellste Weg.

Wir haben letztes Jahr eine ähnliche Warnung ignoriert, weil zwei Scanner meinten, alles sei sauber. 48 Stunden später wurde unsere Seite von der Suchmaschine mit einer fetten roten Warnseite geblockt. Die Werbeanzeigen wurden gestoppt und wir haben in der Woche rund 4.200 Dollar Umsatz verloren. Externe Scanner wiegen einen oft in falscher Sicherheit – nehmt Berichte, die Alarm schlagen, immer ernst.

Dass der dritte Scanner wegen fehlender HTTP-Header direkt „hohes Risiko“ schreit, ist eine typische Marketingmasche. Viele kostenlose Tools stellen fehlende Security-Header so dar, als wäre der Server komplett verseucht nur um ihr kostenpflichtiges Plugin zu verkaufen. Konfigurationslücken und ein aktiver Malware-Befall sind zwei völlig verschiedene Paar Schuhe.

Edit: Ich habe ein paar Tippfehler korrigiert.

die warnung wegen des externen scripts würde ich keinesfalls ignorieren. meistens werden alte vergessene counter oder third-party chat-pixel gehackt und leiten dann weiter und also schau mal im quellcoed zwischen den head-tags nach, fremde domains stechen da sofort ins auge.

Läuft die Seite auf WordPress oder ist das ein komplett eigenes System? Und liegt die verdächtige JavaScript-Datei direkt auf eurem Server oder wird sie extern von woanders nachgeladen? Mit den beiden Infos könnte man euch deutlich gezielter weiterhelfen.

Um die widersprüchlichen Berichte aufzuklären, geht am besten so vor: 1) Den vollständigen Pfad des vom zweiten Scanner markierten Scripts notieren. 2) Den Quellcode der Datei auf dem Server öffnen und nach fremden Weiterleitungen absuchen. 3) Per FTP oder Hosting-Panel das Datum der letzten Änderung prüfen. 4) Die Zertifikats- und Header-Meldungen des dritten Tools erst mal hinten anstellen.

Lasst den Kopf nicht hängen, bei aktiven E-Commerce-Seiten kommen solche Fehlalarme oder kleine Script-Lecks immer mal wieder vor. Wenn ihr euch an den Code nicht selbst rantraut, macht einfach ein Ticket beim Support eures Hosters auf und hängt das Log vom zweiten Scanner an – einen internen Antiviren-Scan auf dem Server machen die normalerweise kostenlos.

Vor zwei Jahren habe ich genau dasselbe erlebt. Beginnt mit einem kleinen Test, bindet nicht gleich alles fest.

Wenn es jemand anders macht, würde mich das auch interessieren.

bei website security scanner kostenlos ist es meiner Meinung nach schwierig so eindeutig zu sprechen. menschen verteidigen nicht den Prozess, sondern die Gewohnheit.. dann der Widerstand kommt daher.

Funktioniert das deiner Meinung nach in jeder Größe? Die Zeit, die ihr braucht, um ein Problem zu erkennen, bestimmt direkt dessen Kosten.

Viel Erfolg.

Wir sind auch eine Zeit lang an derselben Stelle hängen geblieben. Wenn man versucht, alles gleichzeitig zu ändern, etabliert sich nichts richtig.

Beginnt mit einem kleinen Test, bindet nicht gleich alles fest. Das ist meine Meinung, ich behaupte nicht, dass es absolut richtig ist.

es gab drei verschiedene Ansichten die sich alle ergänzen... also wenn Genehmigung und Umfang nicht schriftlich vorliegen darf der Test nicht starten.

an deiner Stelle würde ich so vorgehen.

Richtig. Die Antwort hängt stark von der Branche ab, es gibt keine allgemeine Regel.

Wenn es jemand anders macht, würde mich das auch interessieren.

Ich stimme voll und ganz zu. Vergessene Testumgebungen sind häufiger das Einfallstor als das Live-System.

Wenn es jemand anders macht, würde mich das auch interessieren.

Ich stimme zu, möchte das sogar besonders betonen. Menschen verteidigen nicht den Prozess sondern die Gewohnheit. Der Widerstand kommt daher.

Aus Erfahrung weiß ich das.

Meine Frage klingt vielleicht etwas naiv, entschuldigt bitte. Die Zeit, die ihr braucht, um ein Problem zu erkennen, bestimmt direkt dessen Kosten.

Schreibe bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste. Nur als Notiz, könnte nützlich sein.

Ich schreibe das, damit ihr denselben Fehler nicht macht. Scheut euch nicht zu fragen, wer nicht fragt, zahlt am Ende mehr.

Das war's, entschuldige, wenn ich zu lang war.