PHP-Sicherheitslücke prüfen in fünf Minuten

Was es heißt, eine PHP-Sicherheitslücke prüfen zu wollen

Hinter der scheinbar einfachen Frage „Bin ich betroffen?“ stecken vier verschiedene Fragen, die sich nur zusammen beantworten lassen. Mit nur einer Antwort ist die Lage noch nicht bekannt.

Die erste Frage lautet, ob auf dem Server überhaupt PHP arbeitet. Das klingt banal, doch viele Betreiber wissen es nicht. Ein Baukasten, ein statischer Auftritt und ein klassisches Website-System verhalten sich von außen ähnlich, unterscheiden sich im Risiko aber erheblich. Die zweite Frage betrifft die Version und deren Ausprägung (welche Stände für die aktuelle Meldung maßgeblich sind, steht in unserem Beitrag zu PHP2Shell). Gemeint ist nicht nur die Nummer, sondern auch die Frage, wer sie gepflegt hat und ob Korrekturen eingearbeitet wurden, ohne dass die Nummer sich änderte.

Die dritte Frage gilt der Betriebsart. Ob PHP als Modul im Webserver, als getrennter Dienst oder in einem Container läuft, verändert die Gefährdung und die Wege, sie zu beheben. Die vierte Frage richtet sich auf Spuren. Selbst wenn heute alles korrekt ist, kann in der Vergangenheit etwas geschehen sein, das nach einem Update fortbesteht, etwa eine versteckte Datei oder ein manipulierter Seitenabschnitt.

Eine belastbare Prüfung verbindet diese Perspektiven und sagt am Ende nicht nur „gut“ oder „schlecht“, sondern benennt, was sicher festgestellt wurde, was wahrscheinlich ist und was offen bleibt. Genau diese Dreiteilung unterscheidet eine Untersuchung von einer Vermutung.

Warum sich die PHP-Version von außen nicht einfach ablesen lässt

Webserver sind nicht dazu gebaut, ihre Innereien zu erklären. Im Gegenteil, es gilt seit Jahren als gute Praxis, Angaben zur eingesetzten Software zu verbergen. Das erschwert Angreifern das Auffinden, erschwert aber auch jeder Prüfung von außen das Leben. Mehrere Umstände tragen dazu bei, dass die Version selten eindeutig sichtbar ist.

Absichtlich versteckte Angaben

Viele Hoster und Administratoren schalten die Angabe zur Programmiersprache in den Antworten des Servers ab. Dann bleibt von außen nur ein indirekter Eindruck, der aus dem Verhalten der Seite, aus Dateiendungen oder aus typischen Eigenheiten eines Website-Systems entsteht. Aus einem Eindruck wird erst durch mehrere übereinstimmende Signale eine belastbare Aussage.

Vorgeschaltete Dienste

Zwischen Besucher und Server sitzen oft weitere Stationen, etwa ein Verteilnetz, ein Schutzdienst oder ein Zwischenspeicher. Sie beantworten Anfragen teilweise selbst und entfernen oder ersetzen Angaben, bevor sie Ihren Besucher erreichen. Was von außen zu sehen ist, beschreibt dann unter Umständen die Zwischenstation und nicht Ihren Server.

Mehrere Versionen auf einem System

Auf Servern können mehrere PHP-Zweige nebeneinander installiert sein. Welche Version eine bestimmte Website bedient, entscheidet die Konfiguration des einzelnen Projekts. Ein Server, der laut Verwaltungsoberfläche eine aktuelle Version führt, kann dennoch Teilbereiche mit einer älteren ausliefern, etwa ein vergessenes Kundenportal auf einer Unterdomain.

Mitgebrachte Laufzeiten

Manche Anwendungen bringen ihren eigenen Interpreter mit, andere laufen in einem Container, der eine feste Version enthält. In beiden Fällen sagt der Zustand des umgebenden Servers wenig über das aus, was Besucher tatsächlich erreicht.

Aus alledem folgt, dass „Welche Version läuft?“ eine Frage ist, die man beantworten kann, aber nicht mit einem einzigen Blick. Sie verlangt, mehrere Indizien zu sammeln, zu gewichten und gegeneinander zu prüfen.

Fehlalarme in beide Richtungen

Bei Sicherheitsfragen gibt es zwei Arten von Fehlurteilen, und beide kosten Geld. Das eine ist die falsche Entwarnung, das andere die unnötige Panik.

Zur falschen Entwarnung kommt es, wenn eine Angabe aktuell aussieht, aber nichts über den tatsächlichen Zustand verrät. Ein Beispiel ist ein Server, auf dem die neue Software zwar installiert wurde, die alten Arbeitsprozesse aber weiterlaufen. Allein die installierte Nummer wiegt in falscher Sicherheit, während der laufende Dienst noch den alten Code ausführt. Ein anderes Beispiel ist die Seite, die selbst korrekt arbeitet, aber über eine Erweiterung fremden Code nachlädt.

Zur unnötigen Panik kommt es im umgekehrten Fall. Manche Linux-Distributionen übernehmen Korrekturen in ältere Programmstände, ohne die Nummer zu erhöhen. Der bloße Abgleich mit einer Tabelle hält einen längst geflickten Server für gefährdet und stößt Maßnahmen an, die niemand braucht. Das bindet Kapazitäten, die bei einem tatsächlich gefährdeten System fehlen.

Gute Prüfungen weisen deshalb den Grad der Sicherheit aus, mit dem eine Aussage gilt. „Nicht feststellbar“ ist dabei ein vollwertiges und ehrliches Ergebnis. Es ist unbequemer als ein grünes Häkchen, aber verlässlicher.

Um Fehlalarme zu vermeiden, gleicht der Basis-Scan für 99 € die Antworten mit der Fehlerseite der jeweiligen Website ab, bevor er einen Fund meldet.

Warum es hier keine Anleitung zur Eigenprüfung gibt

Im Netz kursieren Anleitungen, die versprechen, die Frage mit zwei, drei Handgriffen zu klären. Wir verzichten darauf, und zwar aus zwei Gründen, die mit Ehrlichkeit zu tun haben.

Erstens ist das Ergebnis solcher Kurzprüfungen häufig mehrdeutig, wie die vorangehenden Abschnitte zeigen. Ein mehrdeutiges Ergebnis ohne Einordnung führt zu schlechteren Entscheidungen als das ausdrückliche Wissen, etwas nicht zu wissen. Zweitens ist die Prüfung unsere Leistung. Wir bieten sie zum Festpreis an, weil wir sie sorgfältig und wiederholbar durchführen können, und wir sagen das offen, statt eine Anleitung als Gefälligkeit zu tarnen.

Das heißt nicht, dass Ihr Hoster oder Ihr IT-Betreuer die Antwort nicht kennen könnte. Mit Zugang zum Server lässt sich vieles direkt feststellen. Genau deshalb ergänzen sich beide Wege: die Sicht von innen durch Menschen mit Zugriff, die Sicht von außen durch den Scan. Beide zusammen ergeben ein Bild, das keine der Seiten allein liefern kann.

Der Basis-Scan im Überblick: Vier Bausteine

Der Basis-Scan ist als Untersuchung von außen angelegt. Er verhält sich wie ein aufmerksamer Besucher, der mehrere Seiten aufruft, und wie ein Prüfer, der die Antworten auswertet. Er führt keine Angriffe aus und versucht nicht, in das System einzudringen. Vier Bausteine greifen ineinander.

Baustein 1: Hinweise auf die PHP-Version und Abgleich mit den Lücken

Dazu sammelt der Scan alle öffentlich erkennbaren Hinweise darauf, ob und in welcher Version PHP arbeitet, und gleicht eine erkannte Version mit den Ständen ab, in denen CVE-2026-109618 und CVE-2026-109619 behoben sind. Weil einzelne Hinweise trügen können, wertet er mehrere zusammen aus und weist das Ergebnis mit einer Sicherheitsstufe aus. Bleibt die Version verborgen, steht im Bericht „nicht feststellbar“.

Baustein 2: Typische Spuren von Hintertüren

Angreifer legen nach einem Einbruch häufig Dateien ab, die ihnen späteren Zugang ermöglichen. Solche Dateien tragen oft wiederkehrende Namen oder liegen an auffälligen Orten. An einer begrenzten Zahl solcher Stellen fragt der Scan an, ob dort etwas öffentlich erreichbar ist, und unterscheidet dabei sorgfältig zwischen einer echten Fundstelle und einer gewöhnlichen Fehlerseite Ihres Servers, damit keine Fehlalarme entstehen. Er öffnet und verändert nichts, was nicht ohnehin für jeden Besucher sichtbar ist.

Baustein 3: Schadcode in den ausgelieferten Seiten

Nicht jede Manipulation liegt als Datei auf dem Server. Häufig steckt sie im Inhalt der Seiten, die Besucher erhalten. Deshalb untersucht der Scan die Startseite und ausgewählte Unterseiten auf verdächtige Muster, darunter verschleierte Skripte, versteckte eingebettete Fremdinhalte, auffällige Skriptquellen und ungewöhnliche Weiterleitungen. Er prüft außerdem, ob die Seite einem Besucher etwas anderes zeigt als einer Suchmaschine oder einem Mobilgerät, denn dieses Verhalten ist ein typisches Merkmal manipulierter Seiten.

Baustein 4: Die Gesamteinordnung

Aus den Einzelbefunden entsteht ein Gesamtbild. Ein einzelnes Signal ist selten ein Beweis, mehrere zusammen ergeben eine Aussage. Der Bericht gewichtet die Befunde und benennt, welche Punkte Sie zuerst klären sollten und mit wem.

Der Ablauf: Von der Adresse zum Bericht

Wer eine PHP-Sicherheitslücke prüfen lassen möchte, muss dafür keine Technik verstehen. Für Sie als Auftraggeber ist der Vorgang bewusst schlicht gehalten, und die Arbeit liegt beim Scan und nicht bei Ihnen.

Der Zusatz „in fünf Minuten“ im Titel dieses Beitrags beschreibt die übliche Größenordnung der reinen Laufzeit und ist kein Versprechen für jeden Fall. Die Dauer richtet sich nach der Antwortgeschwindigkeit Ihres Servers und nach der Zahl der zu untersuchenden Seiten. Wir nehmen uns lieber eine Minute länger, als ein Ergebnis zu liefern, das nicht trägt.

So ist der Bericht aufgebaut

Ein Prüfbericht ist nur dann nützlich, wenn ihn jemand ohne Technikstudium versteht und trotzdem damit arbeiten kann. Deshalb folgt er einer festen Gliederung.

Ganz oben steht eine Gesamteinschätzung in vier Stufen. Grün bedeutet, dass der Scan keine Auffälligkeiten festgestellt hat. Gelb steht für Hinweise, die geklärt werden sollten, aber keine akute Gefahr belegen. Rot kennzeichnet Befunde, die sofortiges Handeln nahelegen. Grau bedeutet, dass sich eine Frage von außen nicht beantworten ließ, und ist ausdrücklich keine Entwarnung.

Darunter folgen die Befunde nach den vier Bausteinen, jeweils mit einer kurzen Erklärung, was gefunden wurde, wie sicher die Aussage ist und warum sie Bedeutung hat. Den Abschluss bilden Empfehlungen, geordnet nach Dringlichkeit, und ein Vermerk mit Datum und Uhrzeit des Scans, damit sich später nachvollziehen lässt, wann welcher Stand galt.

Drei Beispielberichte aus unterschiedlichen Betrieben

Die folgenden Beispiele sind frei gewählte Konstellationen, die typische Ergebnisse veranschaulichen, und keine Berichte über reale Auftraggeber.

Die Physiotherapiepraxis: Ergebnis Gelb

Eine Praxis lässt ihre WordPress-Seite untersuchen, die ein Hosting-Paket nutzt. In der Praxis erkennt der Scan eine PHP-Version, die unter dem korrigierten Stand ihres Zweigs liegt, findet aber keine Auffälligkeiten in den Seiten und keine verdächtigen Dateien. Der Bericht ordnet das als Gelb ein, weil bei einem Hosting-Paket durchaus eine Korrektur eingearbeitet sein kann, die die Nummer nicht verändert. Empfohlen wird eine schriftliche Rückfrage beim Hoster mit einer klaren Formulierung, die wir dem Bericht beilegen. Die Antwort des Hosters entscheidet, ob aus Gelb Grün wird oder ein Wechsel der Version ansteht.

Der Weinhändler: Ergebnis Rot

Ein Händler mit eigenem Shop auf einem gemieteten Server lässt die Seite prüfen. Beim Weinhändler erkennt der Scan eine deutlich veraltete Version, und ein Seitenbaustein lädt ein Skript von einer Adresse nach, die dem Shop nicht zugeordnet werden kann. Zusätzlich antwortet eine Stelle, an der normalerweise nichts liegt, mit einer Datei. Die Kombination führt zur Einstufung Rot. Der Bericht empfiehlt, den Betreiber des Servers noch am selben Tag einzubinden, die auffällige Stelle sichern zu lassen und die Zugangsdaten zu erneuern. Eine Bereinigung ohne Klärung der Ursache würde das Problem nur verschieben.

Der Sportverein: Ergebnis Grau

Ein Verein betreibt seine Seite über einen Baukasten, den ein ehrenamtlicher Helfer eingerichtet hat. Beim Sportverein findet der Scan keinerlei Hinweise auf PHP, keine verdächtigen Inhalte und keine auffälligen Dateien. Weil die Version von außen schlicht nicht sichtbar ist, lautet das Ergebnis Grau mit dem Hinweis, dass der Anbieter des Baukastens die Technik pflegt und die Frage nach der Betroffenheit nur dort geklärt werden kann. Der Vorstand erhält dafür eine kurze Vorlage für die Anfrage an den Anbieter. Das ist kein befriedigendes, aber ein ehrliches Ergebnis.

Die drei Beispiele zeigen, warum ein einfaches „Ja“ oder „Nein“ selten die richtige Antwort ist. Die Einordnung und der nächste Schritt sind ebenso wichtig wie der Befund selbst.

Was ein Scan von außen nicht sehen kann

Jede Untersuchung hat einen Blickwinkel, und der Blickwinkel begrenzt das Ergebnis. Der Basis-Scan sieht Ihre Website so, wie sie sich einem Besucher aus dem Internet zeigt. Daraus ergeben sich Grenzen, die wir lieber vorab nennen, als sie im Kleingedruckten zu verstecken.

Auf das Dateisystem Ihres Servers hat der Scan keinen Zugriff. Er erkennt daher nur, was öffentlich erreichbar ist, und nicht, was in geschützten Ordnern liegt. Eine Hintertür, die nur mit einem geheimen Parameter reagiert, bleibt ihm verborgen, solange sie sich nicht verrät. Ebenso wenig kann er beurteilen, ob die Zugangsdaten Ihrer Verwaltung sicher sind, ob Ihre Datenbank gut abgesichert ist oder ob die Berechtigungen auf dem Server korrekt gesetzt wurden.

Ein weiterer Punkt betrifft den Zeitpunkt. Ein Scan beschreibt den Zustand zu einer bestimmten Minute. Wurde die Seite gestern manipuliert und heute bereinigt, sieht er nur das Heute. Umgekehrt kann eine Manipulation, die erst morgen erfolgt, heute nicht auffallen. Aus diesem Grund steht auf jedem Bericht das Datum, und aus diesem Grund ist eine Wiederholung nach wichtigen Änderungen sinnvoll.

Schließlich gilt für alle Aussagen über die PHP-Version, dass ein Server sich verstellen kann. Eine Website, die absichtlich falsche Angaben ausspielt, kann jede Prüfung von außen täuschen. Für den normalen Betrieb ist das selten, die Möglichkeit sollte man aber kennen. Für eine Aussage, die auch dann trägt, braucht es den Blick in den Server hinein, und der ist ein anderer Auftrag.

Wo der Scan an seine Grenzen stößt, benennt der Bericht das offen. Wer mehr Tiefe braucht, kann den Basis-Scan als Einstieg nutzen und darauf aufbauen.

Scan, Penetrationstest und Sicherheitsaudit im Vergleich

Im Gespräch über Sicherheit fallen drei Begriffe häufig durcheinander. Sie bezeichnen unterschiedlich tiefe Untersuchungen mit unterschiedlichem Aufwand und unterschiedlichem Nutzen.

Der Basis-Scan steht bewusst am Anfang. Er beantwortet die Frage, ob ein dringender Anlass besteht, und zeigt, ob eine tiefere Untersuchung nötig ist. Für viele kleine und mittlere Betriebe genügt er als Anlassprüfung, für Anwendungen mit sensiblen Daten ist er ein Einstieg und kein Abschluss.

Eine PHP-Sicherheitslücke prüfen: Drei Wege im Vergleich

Wer wissen möchte, ob er betroffen ist, hat im Prinzip drei Möglichkeiten. Jede liefert eine andere Qualität von Antwort, und keine ist grundsätzlich falsch. Entscheidend ist, dass man weiß, was man von ihr erwarten darf.

Am aussagekräftigsten ist die Kombination. Der Scan liefert eine unabhängige Außenansicht und zeigt, wo Auskunft und Wirklichkeit auseinanderfallen. Die Auskunft des Betreibers füllt die Lücken, die von außen bleiben. Beide Perspektiven zusammen ergeben ein Urteil, das keine allein tragen könnte. Wie sich eine PHP-Sicherheitslücke prüfen lässt, hängt im Einzelfall davon ab, wer die Technik betreibt, und deshalb sprechen wir im Erstgespräch über genau diese Konstellation.

Antworten des Hosters einordnen: Beruhigend ist nicht gleich belastbar

Fragt man einen Hoster, ob seine Systeme auf dem aktuellen Stand sind, erhält man oft freundliche, aber unscharfe Antworten. Sie klingen beruhigend und lassen sich trotzdem nicht überprüfen. Es lohnt sich, den Unterschied zu kennen.

Belastbar ist eine Antwort, die konkret wird. Sie nennt eine Version oder eine Paketnummer, nennt einen Zeitpunkt, an dem die Änderung wirksam wurde, und bezieht sich ausdrücklich auf die beiden Kennungen der Sicherheitsmeldung. Sie kommt schriftlich und lässt sich aufbewahren. Eine solche Antwort ist ein Beleg, auf den man sich später berufen kann.

Unscharf ist dagegen eine Antwort, die allgemein bleibt. Sätze wie „Wir halten unsere Systeme immer aktuell“ oder „Das haben wir im Griff“ beschreiben eine Haltung und keinen Zustand. Sie sind nicht unehrlich, aber sie beantworten die Frage nicht. In diesem Fall hilft eine zweite, unabhängige Sicht, weil sie zeigt, ob die Haltung sich im Ergebnis widerspiegelt.

Auch unterschiedliche Abteilungen eines Anbieters antworten unterschiedlich. Der Vertrieb kennt die Produkte, der Support kennt die Tickets, die Technik kennt die Server. Für eine verlässliche Antwort richten Sie die Frage an die Stelle, die den Zustand tatsächlich kennt, und bitten darum, sie intern weiterzugeben.

Die Technik hinter dem Scan: Vorsicht statt Brachialgewalt

Ein Prüfwerkzeug kann auf zwei Arten scheitern. Es kann zu wenig finden, oder es kann selbst Schaden anrichten. Beides wollten wir ausschließen, und deshalb folgt der Basis-Scan einigen Grundsätzen, die sein Verhalten von dem eines Angreifers unterscheiden.

Gestellt werden ausschließlich lesende Anfragen, wie sie ein gewöhnlicher Browser ebenfalls sendet. Der Scan sendet keine präparierten Eingaben, keine übergroßen Datenmengen und keine Muster, die darauf zielen, einen Fehler auszulösen. Genau dort verläuft die Grenze zwischen Prüfen und Angreifen, und wir überschreiten sie nicht, auch wenn das manche Befunde bequemer machen würde.

Die Zahl der Anfragen ist begrenzt, und der Scan arbeitet mit Rücksicht auf Ihren Server. Er wartet auf Antworten, statt sie zu bedrängen, und bricht ab, wenn der Server überlastet wirkt. Bei Seiten auf kleinen Hosting-Paketen ist das wichtig, weil dort wenige gleichzeitige Anfragen bereits spürbar sind.

Zur Vermeidung von Fehlalarmen lernt der Scan zunächst, wie Ihr Server eine nicht vorhandene Seite beantwortet. Manche Server liefern auf jede unbekannte Adresse eine freundliche Startseite mit dem Status „in Ordnung“. Ohne diese Vorbereitung würde ein Prüfer jede Anfrage als Fund werten. Mit ihr lässt sich eine echte Fundstelle von einem Echo der Fehlerseite unterscheiden.

Schließlich bleibt der Scan ehrlich in der Aussage. Wo ein Befund auf mehreren Indizien beruht, steht das im Bericht, und wo ein Indiz fehlt, steht dort „nicht feststellbar“. Ein Werkzeug, das aus Mangel an Daten Grün meldet, wäre bequemer, aber unredlich.

Die Anatomie einer Hintertür: Warum Spuren das Update überleben

Eine Hintertür ist eine unscheinbare Möglichkeit, sich ohne die üblichen Zugangsdaten Zugriff auf eine Website zu verschaffen. Sie kann aus einer winzigen Datei bestehen, die einen empfangenen Text als Befehl ausführt, oder aus einem Eintrag, der ein zusätzliches Benutzerkonto anlegt. Der Aufwand für den Angreifer ist gering, der Nutzen groß.

Entscheidend ist, dass eine Hintertür unabhängig von der Lücke existiert, durch die sie angelegt wurde. Wer die ursprüngliche Schwachstelle schließt, sperrt den Weg, den der Angreifer genommen hat, aber nicht den Schlüssel, den er sich zwischenzeitlich nachmachen ließ. Das ist der Grund, warum Fachleute nach einer Sicherheitslücke nicht nur fragen, ob aktualisiert wurde, sondern auch, ob jemand bereits da war.

Hintertüren tarnen sich. Sie tragen Namen, die Systemdateien ähneln, liegen in Ordnern, die selten jemand öffnet, oder verstecken sich in Dateien, die ohnehin zum System gehören. Manche verhalten sich nur auf einen bestimmten Auslöser hin auffällig. Eine Prüfung per Augenschein bringt deshalb wenig, und die schiere Menge der Dateien einer gewöhnlichen Website macht eine gezielte Suche ohne Hilfsmittel mühsam.

Angesetzt wird dort, wo sich Hintertüren erfahrungsgemäß öffentlich zeigen. Der Scan kann nicht alle finden, erkennt aber die, die für jeden Besucher sichtbar sind, und genau diese sind für Angreifer am wertvollsten, weil sie sich ohne Anmeldung nutzen lassen.

Schadcode in Seiten: Was Besucher und Suchmaschinen erleben

Nicht jeder Angriff zielt auf den Server. Manche Angreifer wollen die Besucher einer Website erreichen und nutzen die Seite als Verteiler. Das kann auf mehreren Wegen geschehen, und die Folgen für den Betreiber sind unterschiedlich.

Weiterleitungen auf fremde Angebote

Besucher werden ohne ihr Zutun auf andere Adressen geschickt, etwa auf Glücksspiel, Fälschungen oder betrügerische Gewinnspiele. Besonders tückisch sind Varianten, die nur Besucher aus einer Suchmaschine umleiten. Der Inhaber ruft seine Seite direkt auf, sieht nichts Auffälliges und bleibt lange ahnungslos.

Versteckte Inhalte für Suchmaschinen

Manipulierte Seiten zeigen Suchmaschinen Texte und Verweise, die menschliche Besucher nie sehen. Ziel ist es, fremden Angeboten Sichtbarkeit zu verschaffen, indem man das Vertrauen ausnutzt, das Ihre Domain aufgebaut hat. Für Sie bedeutet das im Ergebnis, dass in den Suchergebnissen Texte unter Ihrem Namen erscheinen, die Sie nie geschrieben haben.

Nachgeladene Schadsoftware

Ein eingeschleustes Skript kann Besucher auffordern, ein angebliches Update oder eine Schriftart zu installieren, und liefert stattdessen Schadsoftware aus. Der Besucher macht Sie dafür verantwortlich, zu Recht oder zu Unrecht, denn er hat Ihrer Seite vertraut.

Verdeckte Rechenleistung

Wieder andere Skripte nutzen die Geräte Ihrer Besucher, um fremde Rechenaufgaben zu erledigen. Die Folge sind Seiten, die plötzlich langsam laufen und Prozessoren auslasten, ohne dass ein erkennbarer Grund besteht.

Gemeinsam ist allen Varianten, dass sie nach außen sichtbar sind, sofern man weiß, wo man hinsehen muss. Genau das leistet der dritte Baustein des Scans. Er erkennt die typischen Spuren in den ausgelieferten Seiten und vergleicht die Ansicht für verschiedene Besucherarten.

Die Folgen reichen über das Technische hinaus. Browser und Suchmaschinen warnen vor Seiten, die Schadsoftware verbreiten, und solche Warnungen schrecken Besucher verlässlich ab. Eine Seite, die einmal als gefährlich markiert wurde, braucht erfahrungsgemäß Zeit, bis das Vertrauen zurückkehrt.

Wer ist wofür zuständig: Hoster, Agentur und Sie

Eine der häufigsten Ursachen für unbehobene Lücken ist nicht fehlendes Wissen, sondern unklare Verantwortung. Alle Beteiligten gehen davon aus, dass sich ein anderer kümmert, und am Ende kümmert sich niemand. Ein Blick auf die typische Aufteilung hilft, die Frage nach dem Ansprechpartner zu beantworten.

Der Hoster ist verantwortlich für Rechenzentrum, Netzwerk und in vielen Tarifen auch für die Grundausstattung des Servers. Ob er darüber hinaus die Programmiersprache aktualisiert, hängt vom Tarif ab. Bei einfachen Paketen bietet er neue Versionen an und die Umstellung bleibt Sache des Kunden, bei verwalteten Tarifen erledigt er sie selbst.

Die Agentur oder der Entwickler, der Ihre Seite gebaut hat, ist zuständig für das, was er geliefert hat. Das sind Design, Funktionen und gegebenenfalls Erweiterungen. Pflegt er die Seite nach dem Livegang nicht ausdrücklich weiter, endet seine Verantwortung faktisch mit der Übergabe, auch wenn viele Auftraggeber das anders erwarten.

Sie als Betreiber tragen die Gesamtverantwortung gegenüber Ihren Kunden und der Aufsichtsbehörde, gleichgültig, wie Sie die Arbeit verteilt haben. Aus diesem Grund lohnt es sich, schriftlich festzuhalten, wer was übernimmt, und die Aufteilung gelegentlich zu überprüfen. Woran sich ein verlässlicher Partner für diese Aufgaben erkennen lässt, beschreibt der Abschnitt Dienstleister im Beitrag zum Schutz der Website.

Ein Prüfbericht von außen hilft in dieser Konstellation, weil er eine neutrale Grundlage für das Gespräch liefert. Er nennt Befunde, ohne Schuldzuweisung, und macht aus einem Gefühl eine Aussage, auf die sich alle Seiten beziehen können.

Fünf Situationen, in denen sich eine Prüfung bezahlt macht

Der Anlass für eine Sicherheitsprüfung ist selten ein theoretisches Interesse. Meist steht ein konkreter Moment dahinter, in dem jemand eine belastbare Aussage braucht. Fünf Konstellationen tauchen besonders oft auf.

Die Agentur übernimmt eine Kundenseite

Wechselt ein Kunde zu einer neuen Agentur, erbt diese eine Website mit unbekannter Vorgeschichte. Bevor sie die Betreuung und damit die Verantwortung übernimmt, möchte sie wissen, in welchem Zustand das Erbe ist. Ein Bericht vom Übergabetag schützt beide Seiten vor späteren Streitigkeiten darüber, wer was verursacht hat.

Der Umzug zu einem anderen Hoster

Beim Umzug ändern sich Serverumgebung und Konfiguration, oft auch die PHP-Version. Eine Prüfung nach dem Umzug zeigt, ob die Seite sich auf dem neuen System so verhält wie erwartet und ob sich unbeabsichtigt Dateien oder Einstellungen gelöst haben.

Ein Hinweis aus dem Team

Eine Mitarbeiterin berichtet, dass die Seite am Handy anders aussieht, ein Kunde schickt einen Screenshot mit einer Warnung, oder der eigene Browser meldet ein Zertifikatsproblem. Solche Beobachtungen sind oft der einzige Hinweis auf eine Manipulation. Eine schnelle Untersuchung klärt, ob ein Verdacht begründet ist, bevor er zu einem Gerücht wird.

Der Fragebogen eines Geschäftspartners

Größere Auftraggeber fragen zunehmend nach dem Sicherheitsstand der Dienstleister. Eine datierte Prüfung erlaubt knappe und belegte Antworten. Das spart Rückfragen und signalisiert Professionalität, noch bevor das fachliche Gespräch beginnt.

Die Unternehmensnachfolge oder der Verkauf

Bei einer Übergabe oder einem Verkauf prüft die Gegenseite die digitalen Werte genauer als früher. Eine Website mit unklarem Sicherheitsstand kann Verhandlungen verzögern oder den Preis beeinflussen. Ein aktueller Bericht beseitigt diesen Unsicherheitsfaktor.

Prüfergebnisse intern und gegenüber Dritten nutzen

Ein Bericht gewinnt an Wert, wenn man ihn weiterverwendet. Er ist zunächst ein Arbeitsmittel für Ihre Technik und eine Gesprächsgrundlage mit Ihrem Dienstleister. Darüber hinaus kann er Aufgaben erfüllen, an die man beim Beauftragen nicht sofort denkt.

Gegenüber Versicherern dient er als Nachweis, dass Sie sich um das Thema kümmern. Viele Policen für Cyberrisiken stellen Fragen zu den getroffenen Vorkehrungen, und ein datierter Bericht beantwortet einen Teil davon. Gegenüber Aufsichtsbehörden und Kunden zeigt er, dass Sie Ihre Pflichten zum Schutz personenbezogener Daten ernst nehmen. Gegenüber Ihrer Geschäftsleitung macht er aus einem abstrakten Risiko eine konkrete Entscheidungsgrundlage, auf der sich Budgets begründen lassen.

Beachten Sie dabei, dass ein Bericht auch Befunde enthält, die nicht für jedes Publikum bestimmt sind. Vor der Weitergabe sollte geklärt sein, wer den Bericht lesen darf, und sensible Abschnitte lassen sich gegebenenfalls auslassen. Benötigen Sie eine gekürzte Fassung für Dritte, sprechen Sie uns an.

Wo Sicherheit und Sichtbarkeit in Suchmaschinen zusammenhängen

Wer eine PHP-Sicherheitslücke prüfen lässt, tut damit auch etwas für seine Auffindbarkeit. Bei der Beschäftigung mit Sicherheit taucht schnell ein Nebenthema auf, das viele Betreiber überrascht: Eine manipulierte Seite verliert häufig an Sichtbarkeit. Das liegt daran, dass Suchmaschinen Seiten, die Schadsoftware verbreiten oder fremde Inhalte unterschieben, herabstufen oder mit Warnhinweisen versehen.

Für Unternehmen, die über ihre Seite Anfragen gewinnen, ist das mehr als eine technische Randnotiz. Ein Sicherheitsvorfall kann Wochen später noch im Ranking spürbar sein, selbst wenn die Seite längst bereinigt ist. Umgekehrt gilt, dass eine gepflegte, aktuelle Seite eine bessere Grundlage für gute Platzierungen bietet als eine, die ständig nachgebessert werden muss. Eine Garantie für ein bestimmtes Ranking ergibt sich daraus nicht, und niemand kann sie seriös geben.

Eine regelmäßige Prüfung ist insofern auch ein Beitrag zur Pflege Ihrer Sichtbarkeit. Sie entdeckt Veränderungen, die Besucher irritieren und Suchmaschinen alarmieren, bevor beide Seiten reagieren. Verbinden Sie die Prüfung mit einer ohnehin geplanten Überarbeitung Ihrer Inhalte, nutzen Sie den Termin doppelt.

Warum Dokumentation mehr ist als Bürokratie

Zu jeder ernsthaften Prüfung gehört, das Ergebnis festzuhalten. Das klingt nach Schreibtischarbeit, hat aber handfeste Gründe. Ein dokumentierter Stand beantwortet Fragen, die erst Wochen später auftauchen, etwa wenn ein Kunde nachfragt, ob die Website zum Zeitpunkt einer Meldung geschützt war.

Außerdem erleichtert die Dokumentation die Zusammenarbeit. Wechselt der Verantwortliche, kann der Nachfolger nachvollziehen, was geprüft wurde und mit welchem Ergebnis. Und sie schützt vor dem Gefühl, ständig bei null zu beginnen. Über mehrere Prüfungen hinweg lassen sich Ergebnisse vergleichen und Entwicklungen erkennen: Verbessert sich die Lage, oder häufen sich dieselben Befunde?

Schließlich dient die Dokumentation dem Nachweis gegenüber Dritten. Versicherer, Aufsichtsbehörden und Kunden fragen nach der Sorgfalt, die ein Betrieb walten lässt, und ein datierter Bericht ist die einfachste Antwort. Aus diesem Grund trägt jeder unserer Berichte Datum und Uhrzeit des Scans und lässt sich später unverändert vorlegen.

Wen Sie scannen lassen dürfen

Das Abtasten fremder Systeme ohne Erlaubnis kann rechtliche Folgen haben, auch wenn die Absicht harmlos ist. Wir verlassen uns deshalb nicht auf Treu und Glauben, sondern lassen uns vor dem Start bestätigen, dass Sie Inhaber der Website sind oder im Auftrag des Inhabers handeln.

Das gilt auch für Agenturen und Dienstleister, die für mehrere Kunden arbeiten. Für die Seiten Ihrer Kunden benötigen Sie deren Einverständnis und sollten es in einer Form festhalten, die sich später vorzeigen lässt. Wir scannen keine Adressen, bei denen erkennbar ist, dass sie nicht zum Auftraggeber gehören, und weisen Aufträge dieser Art zurück.

Für den Datenschutz ist wichtig, dass der Scan ausschließlich Informationen verwendet, die jeder Besucher ohnehin erhält. Er greift nicht auf Kundendaten zu und legt keine Daten Ihrer Besucher ab. Der Bericht selbst enthält Angaben zu Ihrer Website und gehört Ihnen.

Was nach dem Befund geschieht

Ein Bericht ist ein Ausgangspunkt. Was daraus wird, hängt vom Ergebnis und davon ab, wer Ihre Seite technisch betreut.

Bei einem grünen Ergebnis ist in der Regel nichts Weiteres nötig, außer die Prüfung nach wichtigen Änderungen zu wiederholen. Bei Gelb und Grau geht es meist um Klärung. Wir formulieren die Anfrage an Ihren Hoster oder Ihren IT-Betreuer so, dass sie eine eindeutige Antwort verlangt, und bewerten die Rückmeldung auf Wunsch gemeinsam mit Ihnen. Bei Rot zählt Zeit. Dann sprechen wir kurzfristig mit Ihnen, ordnen die Lage ein und schlagen vor, wie sich der Schaden begrenzen lässt.

Für die eigentliche Behebung arbeiten wir mit Ihrem bestehenden Dienstleister zusammen, wenn Sie das möchten, oder übernehmen die Arbeit selbst. Wo zusätzliche Fachleute sinnvoll sind, etwa bei einem Spezialsystem oder einer besonders alten Anwendung, binden wir externe Entwickler und Partneragenturen ein, mit denen wir ohnehin regelmäßig kooperieren. Sie erhalten dafür vorab ein Angebot zum Festpreis, bevor irgendetwas beginnt.

Aus jedem Befund des Basis-Scans folgt eine Empfehlung mit Dringlichkeit, damit Sie wissen, was zuerst ansteht.

Was die 99 Euro abdecken und was nicht

Der Basis-Scan kostet 99 € als Festpreis. Darin enthalten sind der Scan Ihrer Webadresse mit den vier beschriebenen Bausteinen, der Bericht mit Gesamteinschätzung und Empfehlungen sowie die Vorlage für die Rückfrage an Ihren Hoster, falls eine nötig ist. Die Preisangabe finden Sie zusätzlich in der Übersicht der Pakete und Preise, das Gesamtangebot auf der Seite Website-Sicherheit.

Nicht enthalten sind die Behebung von Befunden, die Bereinigung einer manipulierten Seite, eine Untersuchung des Servers von innen und die laufende Betreuung. Diese Leistungen sind eigene Aufträge, die wir auf Basis des Berichts anbieten. Auch hier erfahren Sie den Preis vor dem Start.

Der Festpreis hat einen praktischen Hintergrund. Eine Frage zu Sicherheit soll nicht damit beginnen, dass zuerst über Stundensätze verhandelt wird. Ein klarer Betrag senkt die Schwelle, die Frage überhaupt zu stellen, und das ist bei Sicherheitsthemen mehr wert, als es auf den ersten Blick scheint.

Wann und wie oft ein Scan sinnvoll ist

Eine Sicherheitsprüfung ist kein Termin, den man einmal abhakt. Sinnvoll ist sie zu bestimmten Anlässen und in einem Rhythmus, der zum Risiko Ihrer Website passt.

Eine PHP-Sicherheitslücke prüfen zu lassen, lohnt sich vor allem zu bestimmten Anlässen. Zu den klaren zählen der Start einer neuen oder überarbeiteten Seite, der Wechsel des Hosters, die Übernahme einer Seite von einem früheren Dienstleister und eine öffentliche Sicherheitsmeldung zu einer eingesetzten Technik, wie sie PHP2Shell derzeit darstellt. Ein Verdachtsmoment, etwa Warnungen des Browsers oder ungewöhnliche Weiterleitungen, ist ebenfalls ein Anlass, der keinen Aufschub duldet. Der Hintergrund zur aktuellen Meldung steht in unserem Beitrag zu PHP2Shell.

Darüber hinaus bietet sich eine regelmäßige Wiederholung an. Wer eine Seite mit Kundendaten oder Zahlungsabwicklung betreibt, fährt mit kürzeren Abständen besser als jemand mit einer reinen Informationsseite. Wie sich Prüfungen in ein dauerhaftes Sicherheitskonzept einfügen, beschreibt der Beitrag Website vor Hackerangriff schützen: Strategie statt Checkliste.

Weil sich ein Zustand ändert, lohnt eine Wiederholung nach größeren Umbauten. Mit 99 € je Basis-Scan bleibt das auch für kleinere Betriebe planbar.

Missverständnisse rund um Sicherheitsprüfungen

„Ein grünes Ergebnis heißt, die Seite ist sicher.“

Ein grünes Ergebnis bedeutet, dass in den untersuchten Bereichen nichts aufgefallen ist. Es bedeutet nicht, dass es nichts gibt. Die Aussage gilt für den Zeitpunkt und für den Ausschnitt, den ein Scan von außen sehen kann.

„Ein Scanner im Browser-Plugin reicht aus.“

Erweiterungen, die innerhalb der Website laufen, können nur prüfen, was ihnen die Umgebung zeigt. Gegen Fehler in der Grundlage, auf der sie selbst laufen, sind sie blind. Eine Sicht von außen ergänzt ihre Sicht von innen.

„Wer nichts findet, hat nichts zu befürchten.“

Fehlende Funde können an einer guten Tarnung liegen. Manche Schadprogramme verhalten sich nur unter bestimmten Bedingungen auffällig, etwa bei Besuchern aus einer Suchmaschine. Deshalb sucht ein guter Scan auch nach dem Unterschied zwischen verschiedenen Besucherarten.

„Ein Hoster mit Sicherheitssiegel ist automatisch sicher.“

Siegel beschreiben, was ein Anbieter an seinem eigenen Rechenzentrum und seinen Prozessen geleistet hat. Ob Ihre konkrete Website auf aktuellem Stand ist, sagen sie nicht aus.

„Prüfen lassen ist teuer und aufwendig.“

Eine Untersuchung von außen ist weder teuer noch aufwendig. Teuer wird es, wenn ein Problem erst durch Kunden oder Suchmaschinen auffällt.

Häufige Fragen: Eine PHP-Sicherheitslücke prüfen lassen

Offizielle Informationsquellen

Die Einordnung der Lücken stützt sich auf diese öffentlich zugänglichen Veröffentlichungen. Sie nennen die korrigierten Versionen und beschreiben die technischen Hintergründe.

• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• Google Cloud: Responding to core PHP vulnerabilities