Mit dem Sicherheits-Scan können Sie die Websites Ihrer Mandanten auf Sicherheitskriterien überprüfen.
Erkennen Sie Schwachstellen und minimieren Sie die Angriffsfläche für Ihre Mandanten.
Einführung in den Sicherheits-Scan
In der heutigen Zeit ist die Website eines Unternehmens oftmals der erste Angriffspunkt - insbesondere, wenn Angreifer wissen, dass potentiell wertvolle Daten zu holen sind. Daher ist es wichtig, frühstmöglich über die zugrundeliegenden Sicherheitsrisiken, die einen solchen Vorfall ermöglichen, informiert zu sein. Zugegebenermaßen ist das Thema IT-Security komplex und zeitaufwendig.
Unser Ziel ist es, den Einstieg so einfach wie möglich zu machen.
Unser Sicherheits-Scan führt für Sie auf Knopfdruck einen aktiven Penetrationstest durch, weshalb es enorm wichtig ist, dass Sie die Einwilligung des Websitebetreibers haben, bevor Sie einen Scan durchführen.
Tipp: Wenn Sie einen Sicherheits-Scan ausprobieren möchten, nutzen Sie die Website von Vulnweb. Diese Seite ist absichtlich mit Sicherheitslücken gestaltet worden und dient als Demo für unsere Zwecke.
Angriffsbeispiele
Wir nutzen die OWASP Top Ten als wichtigste Grundlage der Überprüfung von Sicherheitsmerkmalen. Zum aktuellen Zeitpunkt haben wir 65 Angriffskategorien mit über 400 Angriffsszenarien zusammengetragen und automatisiert.
Nachfolgend tauchen wir in zwei Angriffskategorien ein und führen zwei Angriffsszenarien manuell durch, die unser Sicherheits-Scan automatisiert, um Ihnen eine Vorstellung zu geben, wie unser Sicherheits-Scan die Fehleranfälligkeit von Websites überprüft.
Beispiel 1: (No)SQL Injections
Aufgrund des Bedarfs an dynamischen Inhalten heutiger Webanwendungen sind die meisten Betreiber auf ein Datenbank-Backend angewiesen, um Daten zu speichern, die von der Webanwendung (oder anderen Programmen) abgerufen und verarbeitet werden. Webanwendungen rufen Daten aus der Datenbank ab, indem sie SQL-Abfragen (z.B. für MySQL, MSSQL, PostgreSQL und Oracle) oder NoSQL-Abfragen (z.B. für MongoDB) verwenden.
Was ist eine (No)SQL Injection?
Eine (No)SQL Injection tritt auf, wenn ein Außenstehender von ihm stammende Werte innerhalb einer (No)SQL-Abfrage verwenden kann, ohne dass vorher eine Validierung dieser Werte durchgeführt wird. Dadurch kann er beliebigen (No)SQL-Code ausführen, um beispielsweise Datenbankabfragen vorzunehmen und Daten einzusehen.
Die erfolgreiche Ausnutzung einer (No)SQL-Injection kann für ein Unternehmen verheerend sein und ist eine der am häufigsten ausgenutzten Schwachstellen von Webanwendungen.
Wie wird eine (No)SQL Injection durch den Sicherheits-Scan ausgeführt?
Mit dem Sicherheits-Scan simulieren wir im Prinzip die Vorgehensweise eines Angreifers. Nehmen wir dafür die Seite von Vulnweb als simples und fiktives Beispiel: http://testphp.vulnweb.com/listproducts.php?artist=1.
Auf dieser Seite können wir Produkte von Künstlern aufrufen. Die Website versteht, dass wenn wir /listproducts.php?artist=1 aufrufen, alle Produkte des Künstlers mit der ID 1 angezeigt werden sollen.
Das heißt, wenn wir alle Produkte des Künstlers mit der ID 2 aufrufen wollen, können wir das über die URL /listproducts.php?artist=2 machen.
Das ist eine sehr einfache und darum häufig verwendete, aber fehleranfällige Art Programmcode zu schreiben.
Unser Sicherheits-Scan erkennt automatisiert, dass wir als Nutzer der Website in der Lage sind, durch das Austauschen von Parametern den Inhalt der Website verändern. Anschließend versucht unser Sicherheits-Scan einen Datenbankfehler auszulösen. Wenn der Entwickler keine Validierung für die Parameter, die wir übergeben können eingebaut hat, wird es gefährlich.
Was passiert zum Beispiel, wenn wir eine ungültige ID übergeben, indem wir ein Hochkomma (') an die URL anhängen? /listproducts.php?artist=2'
Wir sehen, dass wir einen SQL Syntax Fehler ausgelöst haben. Das ist ein Beweis dafür, dass unsere fehlerhafte Angabe ohne Validierung von der Website verarbeitet wird und wir mit dieser Methode beliebige SQL Anfragen ausführen könnten. Wir wollen selbstverständlich keinen Schaden anrichten, weshalb unser Sicherheits-Scan nach dem Beweis eines Sicherheitsfehlers von weiteren Datenverarbeitungen absieht - im Fall eines echten Angriffes würde der Angreifer jetzt weitere SQL Abfragen ausführen, um an die sensiblen Daten zu gelangen, die er haben möchte.
Beispiel 2: Cross-Site Scripting
Client-seitiges JavaScript wird von modernen Webanwendungen ausgiebig genutzt. Die Nutzung reicht von einfachen Funktionen (wie der Formatierung von Text) bis hin zur vollständigen Manipulation von Daten auf der Client-Seite und der Interaktion mit dem Betriebssystem.
Cross-Site Scripting (XSS) ermöglicht es Angreifern, Skripte in eine Anfrage einzufügen und den Server das Skript in der Antwort an den Client zurücksenden zu lassen. Dies geschieht, weil die Anwendung nicht vertrauenswürdige Daten (in diesem Beispiel vom Client) entnimmt und sie wiederverwendet, ohne eine Validierung oder Bereinigung durchzuführen.
Wie wird Cross-Site Scripting durch den Sicherheits-Scan ausgeführt?
Nehmen wir als Beispiel ein Gästebuch, in dem Besucher Kommentare zur Website hinterlassen können (http://testphp.vulnweb.com/guestbook.php).
Auch in diesem Beispiel simuliert unser Sicherheits-Scan einen Angreifer.
Unser Ziel als Angreifer ist es, dieses Formular so auszunutzen, dass wir beliebigen JavaScript Code auf der Website ausführen können. Dafür stellen wir uns vor, dass wir ein bösartiges Script unter der URL "https://beispiel.de/datendiebstahl.js" vorbereitet und gespeichert haben. Dieses Script versuchen wir nun in das Gästebuch zu injizieren, sodass das Script nach der Injection bei jedem Besucher ausgeführt wird.
Falls der Entwickler ebenfalls keine Validierung für das Eingabefeld der Gästebucheinträge vorgenommen hat, sollten wir in der Lage sein, beliebige HTML-Elemente (z.B. Script-Tags) übersenden können, die dann auf der Website im Gästebuch eingefügt werden.
Auf den ersten Blick sieht es nach dem Absenden des Formulars so aus, als wäre nichts passiert. Schauen wir uns jedoch den Code der Website an, stellen wir fest, dass unser Script erfolgreich in den Eintrag injiziert wurde und ab jetzt bei jedem Besucher des Gästebuchs ausgeführt wird.
Damit haben wir bewiesen, dass dieses Formular anfällig für Cross-Site Scripting ist.
Wir hoffen, dass diese zwei simplen Angriffsszenarien Ihnen verdeutlichen konnten, wie unser Sicherheits-Scan arbeitet.
Ein Blick in die Zukunft
In naher Zukunft werden wir dem Sicherheits-Scan weitere Funktionalitäten hinzufügen.
Port Scanner
Offene Ports können Einblick auf die Infrastruktur und verwendete Services eines Servers geben. So wird von Angreifern beispielsweise überprüft, ob ein Server einen geöffneten Port für beliebte SQL Datenbanken vorzuweisen hat. Falls ja, können Bruteforce-Attacken mit regelmäßig vewendeten Benutzername/Passwort-Kombinationen gestartet werden.
Wir entwickeln einen Port Scanner, der offene Ports zu verwendeten Anwendungen zuordnen kann.
SSL Scanner
Teilweise deckt unser DSGVO Scan bereits eine Überprüfung des SSL Zertifikates ab. Diese wollen wir nun im Sicherheits-Scan vertiefen und einen genaueren Einblick auf die Sicherheit des verwendeten SSL Zertifikates ermöglichen.
Berichte
Wie auch beim DSGVO Scan werden Sie die bald die Möglichkeit haben, eine Berichtvorlage für den Sicherheits-Scan zu erstellen, sodass Sie Ihren Mandanten einen verständlichen Nachweis Ihrer Funde anbieten können.
Vielen Dank für das Lesen dieses Artikels! Sollten Sie Fragen oder Anregungen haben, kontaktieren Sie uns gerne jederzeit.