Offene Türen und Abwehr
Debug-Ausgaben, Fehlerseiten mit Programmcode, öffentliche Quellkarten, Methoden wie TRACE, erreichbare Pfade und die Antwort des Servers auf auffällige Anfragen.
11 Prüfpunkte
Diagnoseseiten antworten öffentlich
Versionen, Servernamen und Datenbankstand liegen für jeden offen. Angreifer lesen dort, was sie sonst mühsam suchen müssten.
Was zu tun ist: Ihre Agentur schaltet Diagnosewerkzeuge im Betrieb ab und kürzt Statusseiten auf ein knappes „ok“.
Die Fehlerseite zeigt das Innenleben des Servers
Pfade, Versionen und Dateinamen stehen offen. Angreifer erhalten damit eine Karte des Systems, ohne selbst zu suchen.
Was zu tun ist: Ihre Agentur schaltet die Fehleranzeige im Betrieb ab und richtet eine eigene Fehlerseite ohne technische Details ein.
Hilfsdateien verraten den Aufbau des Programmcodes
Hilfsdateien aus der Entwicklung sind für jeden abrufbar. Sie nennen Dateien und Namen aus dem Originalcode, in der üblichen Einstellung auch den lesbaren Programmcode samt Kommentaren.
Was zu tun ist: Ihre Agentur schließt diese Hilfsdateien vom Veröffentlichen aus oder lässt den Server sie sperren.
Der Server nimmt Befehle an, die eine Website nicht braucht
Jeder zusätzliche Befehlstyp ist eine Tür, die niemand nutzt und niemand bewacht. Angreifer probieren sie zuerst.
Was zu tun ist: Ihr Hoster schaltet am Server alle Befehlstypen ab, die für Lesen und Formulare nicht gebraucht werden.
Der Server spiegelt Anfragen samt Cookies zurück
Ein Diagnosebefehl gibt jede Anfrage samt Cookies zurück. In Verbindung mit einer zweiten Schwäche lassen sich so Anmeldungen abgreifen.
Was zu tun ist: Ihr Hoster schaltet den Diagnosebefehl am Server und am vorgeschalteten Verteiler ab.
Vertrauliche Dateien sind für jeden abrufbar
Konfiguration, Sicherungen oder die Versionsverwaltung liegen im Netz. Darin stehen oft Passwörter und Schlüssel.
Was zu tun ist: Ihr Hoster sperrt die Pfade sofort; danach wechselt Ihre Agentur alle betroffenen Passwörter und Schlüssel.
Bekannte Angriffsflächen sind offen erreichbar
Die genannten Adressen des Systems sind für jeden erreichbar. Automatisierte Angriffe probieren dort rund um die Uhr Passwörter durch oder lesen die Version aus.
Was zu tun ist: Ihr Hoster sperrt die genannten Adressen, schützt die Anmeldung zusätzlich und begrenzt Fehlversuche.
Die Firewall hat die Prüfung als Angriff abgewehrt
Ihre Website wehrt Abtast-Versuche ab. Das ist richtig eingestellt; die Sicherheitsprüfung blieb dadurch unvollständig.
Was zu tun ist: Lassen Sie die Prüfadresse beim Hoster freigeben, damit der nächste Durchgang vollständig messen kann.
Abtast-Versuche blieben ohne Reaktion
Nach verdächtigen Abrufen antwortete der Server wie zuvor. Sperrt er solche Muster nie, kann ein Angreifer die Website nach Schwachstellen absuchen. Manche Sperren greifen erst später oder nehmen bekannte Prüfadressen aus.
Was zu tun ist: Ihr Hoster sagt Ihnen, ob eine Web-Firewall oder eine Sperre nach zu vielen Fehlversuchen aktiv ist, und richtet sie sonst ein.
Die tiefe Sicherheitsprüfung war abgeschaltet
Offene Dateien, Angriffsflächen und Diagnoseseiten wurden nicht abgefragt. Solche Abrufe sehen für eine Firewall wie ein Angriff aus und sperren die Prüfadresse.
Was zu tun ist: Lassen Sie die Prüfadresse beim Hoster freigeben und schalten Sie die Tiefenprüfung im Auftrag ein.
Die tiefe Sicherheitsprüfung braucht Ihren Domain-Nachweis
Offene Dateien, Angriffsflächen und Diagnoseseiten fragt die Prüfung nur bei Websites ab, deren Domain nachgewiesen ist. Solche Abrufe sehen für eine Firewall wie ein Angriff aus.
Was zu tun ist: Weisen Sie Ihre Domain in der Akte nach. Der nächste Durchgang fragt dann auch diese Adressen ab.
