Schwierig ist selten, dass ein Scanner etwas findet. Schwierig ist die Entscheidung, ob es Kundendaten gefährdet, Verkäufe unterbricht oder bis zur nächsten Wartung warten kann. Zwanzig rote Markierungen ohne reproduzierbare Belege erzeugen Aufgaben, ohne diese Entscheidung zu erleichtern.
Ein Sicherheitsaudit untersucht ein definiertes Ziel zu einer bestimmten Zeit aus einer bestimmten Netzposition. Sitelemetry verbindet ausgewählte Module mit Befunden, Belegen und einer Prüfliste. Lesen Sie alles zusammen: Ein abgeschlossener Auftrag bedeutet nicht, dass sämtliche Angriffe versucht oder alle Kontoabläufe untersucht wurden.
Umfang dieser Prüfung
Was messbar ist
- Je nach Modulen: DNS und E-Mail-Richtlinien, TLS, HTTP-Header, Technologiesignale, öffentliche Offenlegungen und API-Oberflächen.
- Soweit Tarif und Profil es erlauben: ausgewählte TCP-Ports, Authentifizierungsoberflächen, Lieferkettensignale und zusätzliche Sicherheits-Engines.
- Unterstützte erfolgreiche Prüfungen und unvollständige Beobachtungen neben den Befunden.
Was sie nicht belegt
- Ein externer Scan beweist nicht, dass alle Berechtigungen, privaten Endpunkte und Geschäftsabläufe sicher sind.
- Zeitüberschreitungen, Filter, Anmeldung und nicht verfügbare Engines begrenzen die Abdeckung; sie sind keine bestandenen Prüfungen.
- Ein Technologie-Fingerabdruck oder eine offene Verbindung beweist allein keine ausnutzbare Schwachstelle.
Bestätigen Sie Eigentum und Berechtigung vor dem Scan. Tarif, Profil, ausdrücklich gewählte Module und verfügbare Engines bestimmen den Umfang. Ein vollständiges Audit umgeht diese Bedingungen nicht; prüfen Sie die tatsächliche Abdeckung.
Mit Belegen beginnen, nicht mit der Punktzahl
Suchen Sie Hostname oder URL, Zeitpunkt, Modul, Antwort- oder Verbindungsbeleg, Zuverlässigkeit und Lösungsvorschlag. Ein in einer echten HTTP-Antwort fehlender Header ist etwas anderes als eine nie abgeschlossene Anfrage. Scheitert TLS, wurden Header nicht gemessen. Fünf vermeintlich fehlende Header würden das Ergebnis dann überzeichnen.
Bewahren Sie im internen Ticket nur die nötigen Belege auf. Bei einem offengelegten Geheimnis genügen Fundort und maskierte Kennung; kopieren Sie nicht den Schlüssel selbst. Ein Versionsabgleich ist ein Ermittlungsansatz. Prüfen Sie installierte Version und Herstellerhinweis, bevor Sie von einem bestätigten Einbruch sprechen.
Schweregrad um geschäftlichen Kontext ergänzen
| Beobachtung | Praktische Priorität | Nächste Entscheidung |
|---|---|---|
| Nutzbare Zugangsdaten öffentlich | Dringend; je nach Rechten möglicherweise kritisch | Widerrufen oder erneuern, Zugriffe untersuchen |
| Abgelaufenes oder nicht vertrauenswürdiges TLS-Zertifikat | Hoch | Vertrauenswürdigen Zugang und Erneuerung herstellen |
| Browser-Richtlinie fehlt | Meist mittel oder niedrig, je nach Kontrolle | Anwendungsverhalten vor Durchsetzung prüfen |
| Technologieoffenlegung oder Framework erkannt | Meist niedrig oder informativ | Relevanz und Patchstand klären |
| Port 443 nimmt Verbindungen an | Erwartete Dienstbeobachtung | TLS und Anwendung bewerten |
Das sind Priorisierungsbeispiele, kein Ersatz für Belege. Eine Kundenanmeldung und eine öffentliche Datei haben verschiedene Anforderungen. Zuverlässigkeit beschreibt die Gewissheit der Beobachtung, Schweregrad die möglichen Folgen. Beides beweist keine bereits erfolgte Ausnutzung.
Offene Ports und Informationsmeldungen einordnen
Eine öffentliche HTTPS-Website benötigt einen HTTPS-Dienst. Port 443 allein ist keine Schwachstelle. Auch Port 80 kann angemessen sein, wenn er auf HTTPS weiterleitet; prüfen Sie das Verhalten. Verwaltungs-, Datenbank- und ältere Transferdienste benötigen Verantwortliche und eine begründete öffentliche Erreichbarkeit. TCP-Erfolg beweist Erreichbarkeit, nicht anonymen Zugriff oder eine Softwareversion.
Fassen Sie allgemeine Portbeobachtung und spezifischen Dienstbefund zu einer Maßnahme zusammen, wenn beide dieselbe Offenlegung beschreiben. Ein Timeout beweist keinen geschlossenen Port. ZAPs Meldung Modern Web Application ist informativ: Sie empfiehlt eine Crawling-Strategie, keinen Sicherheitspatch.
Ursachen beheben und legitimen Verkehr erhalten
- Bestätigte Offenlegung begrenzen. Ungewollten Zugriff entfernen, Zugangsdaten erneuern und Logs prüfen. Eine gelöschte Datei widerruft keinen geleakten Schlüssel.
- Die zuständige Schicht ändern. TLS kann am CDN enden, Header können vom Proxy stammen und Dienste auf anderen Hosts laufen.
- Richtlinien schrittweise einführen. CSP-Meldungen, Anmeldeweiterleitungen, eingebettete Zahlung und Integrationen vor Durchsetzung testen.
- Unnötigen Zugriff reduzieren. Verwaltung auf erforderliche Netzwege beschränken und einen erprobten Wiederherstellungsweg behalten.
Jede Aufgabe braucht Verantwortliche, Termin und Abnahmebeleg. Schalten Sie nicht für eine bessere Punktzahl sämtliche Dienste ab. Ziel ist eine kleinere, begründete Angriffsfläche bei funktionierenden Kundenabläufen.
Den erneuten Test vergleichbar machen
Wiederholen Sie mit identischem Hostnamen, Schema, Profil und Modulen. Dokumentieren Sie beide Berichte und die Änderung dazwischen. Bei DNS, CDN oder Cache muss der Scan den aktualisierten Dienst erreichen. Eine höhere Punktzahl nach Abschalten eines Moduls belegt keine Behebung.
- Prüfen, ob sich der ursprüngliche Beleg nicht mehr reproduziert.
- Betroffene Anmeldung, Registrierung, Zahlung und Einbettung testen.
- Übersprungene, fehlgeschlagene und teilweise Module einschließlich Engine-Verfügbarkeit prüfen.
- Mit neuer Beobachtung abschließen und offene Abdeckungsgrenzen gesondert festhalten.
Erkennen, wann menschliche Tests nötig sind
Kontotrennung, Rechteausweitung über Geschäftsprozesse und Autorisierung zwischen zwei Nutzern benötigen meist gezielte angemeldete Testfälle. Ein öffentlicher Scan kann eine Anmeldeoberfläche finden, ohne deren Regeln zu bestätigen. Planen Sie ergänzende autorisierte Untersuchungen mit dem OWASP-Testleitfaden und nutzen Sie für Browser-Kontrollen die Header-Hinweise.
Erstellen Sie vor wichtigen Releases einen Ausgangsstand und wiederholen Sie betroffene Prüfungen nach Infrastruktur-, Authentifizierungs- oder Abhängigkeitsänderungen. Automatisierung unterstützt Wartung, vergibt aber keine Zertifizierung, garantiert keine Angriffsfreiheit und ersetzt keinen abgegrenzten Penetrationstest.
Häufige Fragen
Bedeutet eine hohe Punktzahl, dass die Website sicher ist?
Sie beschreibt die gemessenen Kontrollen im dokumentierten Umfang. Prüfen Sie Belege, ausgelassene Module und ungetestete Kontoabläufe, bevor Sie weitergehende Aussagen treffen.
Braucht jede Informationsmeldung eine Reparatur?
Nein. Bewahren Sie nützliche Bestandsinformationen auf. Maßnahmen sind bei relevanten Schwächen oder betrieblichen Anforderungen nötig; erwartete HTTPS-Erreichbarkeit ist kein Defekt.
Kann ich das Audit über MCP durchführen?
Unterstützte MCP-Werkzeuge nutzen Rechte und Tarif Ihres Kontos. Prüfen Sie Umfang und Abschlussdetails: Ein verfügbares Werkzeug bedeutet nicht, dass jedes Modul oder jede externe Engine lief.
Quellen und weiterführende Links
- OWASP-Leitfaden für Web-Sicherheitstestsowasp.org
- ZAP: Informationsmeldung Modern Web Applicationwww.zaproxy.org
- OWASP-Hinweise zu HTTP-Headerncheatsheetseries.owasp.org
Vom Sitelemetry-Team mit dem Prüfumfang des Produkts und verlinkten Primärquellen abgeglichen. Beispiele dienen der Veranschaulichung, sofern kein beobachteter Fall ausdrücklich genannt wird.
