Andrea Danti - Fotolia

Die Risiken bei automatisierten Scans von Webschwachstellen

Die automatisierte Suche nach Schwachstellen in Webumgebungen ist unabdingbar. Blind vertrauen sollte man den Lösungen aber nicht, sondern beim Einsatz einige Punkte beachten.

Automatisierung ist ein ganz entscheidender Faktor in der IT-Sicherheit. Patch-Management, Systemüberwachung, Alarmmeldungen – all dies wird versucht, weitestgehend automatisiert abzuwickeln – mit gutem Grund. Und auch die Reaktion auf Vorfälle und einige forensische Herangehensweisen lassen sich automatisieren. In der Gesamtheit sorgt diese Automatisierung für ein verbessertes Sicherheitsniveau.

In kaum einem Unternehmen existieren noch die Ressourcen, um all diese Aufgaben manuell zu erledigen. Und wenn die eine oder andere Pflichtaufgabe manuell abgewickelt wird, stehen die Chancen gut, dass dies bereits ein Grund für einen Sicherheitsvorfall gewesen sein kann.

Und ein weiteres Segment der IT-Sicherheit lässt sich ganz trefflich automatisieren und wird auch häufig so betrieben – das Aufspüren von Webschwachstellen. Viele Unternehmen verlassen sich seit Jahren auf automatisierten Webschwachstellenscanner wie Netsparker und Acunetix Vulnerability Scanner. Mit Hilfe solcher Werkzeuge lassen sich in kurzer Zeit die relevanten Schwachstellen in Sachen Websicherheit finden. Dies sorgt häufig dafür, dass sich die Verantwortlichen in Sachen Webschwachstellen in Sicherheit wiegen.

Das Scannen von Webschwachstellen automatisieren

Es ist in der Tat unproblematisch, im Hinblick auf Webschwachstellen und Penetrationstests einen Großteil des Prozesses zu automatisieren. Aufgrund der Komplexität heutiger Netzwerkumgebungen haben sich viele Admins und Sicherheitsbeauftragte längst daran gewöhnt, Websicherheitstests auf Knopfdruck durchführen zu können.

Ein ordentlicher Test in Sachen Websicherheit geht allerdings über die reine Ausgabe einer URL durch einen Schwachstellenscanner hinaus. Es gibt so viele Feinheiten bei der Ausführung von Schwachstellenscans zu beachten, dass meist ein Fachmann für die Konfiguration vonnöten ist, um wirklich veritable Ergebnisse zu erreichen. Daher müssen Anwender dieser Produkte den jeweiligen Scanner kennen und wissen, was von diesem zu erwarten ist. Andernfalls werden sie nicht die gewünschten Ergebnisse erzielen.

Häufig wird vorausgesetzt, dass sich diese Tools ohne weiteres einfach mit den Werkseinstellungen nutzen lassen. Und zugegebenermaßen haben viele der Anbieter ihre Produkte, insbesondere in Sachen Schnittstellen, sehr gut für den Einsatz vorbereitet. Aber im Detail steckt dann oft mehr dahinter.

Beispielsweise gilt es die Frage nach den Scanrichtlinien zu klären. Soll der Scanner nach allen Schwachstellen Ausschau halten oder sich auf jene mit einem hohen Risiko beschränken? Begrenzt man den Scan auf die risikoreichen Schwachstellen, werden vermutlich eine Reihe nicht zu vernachlässigender Sicherheitslücken übersehen. Unter Umständen sollen bestimmte Tests nicht ausgeführt werden, weil diese Einfluss auf die produktive Umgebung haben könnten, beispielsweise wenn authentifizierte Tests durchgeführt werden.

Und apropos authentifizierte Tests: Soll diese als Gastnutzer oder als vertrauenswürdiger, einloggter Anwender durchgeführt werden? Für ein ordentliches Gesamtergebnis sind beide Durchläufe vonnöten. Darüber hinaus sollte der Admin sich darüber im Klaren sein, welche Scanrichtlinien für die beiden Varianten jeweils am besten geeignet sind.

Bei den meisten Schwachstellenscannern wird sich häufig für die Scanrichtlinie entschieden, bei der alles aus der Position des Außenstehenden ohne Authentifizierung geprüft wird. Angesichts der Komplexität und Abläufe vieler Anwendungen in Verbindung mit den Schwierigkeiten, die viele Scanner beim Einloggen haben, ist es häufig der praktikable Weg, diesen weniger umfassenden Test durchzuführen. Andernfalls kann es passieren, dass der Scanner Schleifen dreht und seine eigentliche Aufgabe niemals wirklich beendet.

Best Practices für das Scannen von Webschwachstellen

Die Erfahrung lehrt zudem, dass die unterschiedlichen Schwachstellenscanner ihre eigenen Stärken und Schwächen haben. Der eine liefert großartige Leistungen beim Erkennen von Cross Site Scripting ab, der andere erkennt bevorzugt SQL Injections. Das ein Scanner eine SQL Injection findet und ein anderer nicht, ist durchaus Alltag. Will heißen, mehrere Scanner liefern teils sehr unterschiedliche Ergebnisse. Wenn man einen wirklich guten Überblick über die eigene Situation in Sachen Websicherheit haben will, sollte man mehrere Scanner einsetzen.

Zudem gibt es eine Vielzahl von Stellschrauben, die es bei der Einrichtung des Scanners zu beachten gilt. So etwa die gleichzeitige Anzahl der Anfragen, die der Scanner an die Anwendung schickt. Jede Änderung kann sich auf die Testergebnisse auswirken.

Das Gleiche gilt für Scans von Anwendungen, die Kontakt- oder andere Formulare enthalten, die nicht mit CAPTCHAs geschützt sind. Hier entsteht schnell eine Art Denial-of-Service-Situation gegen die Produktivumgebung. Ganz zu schweigen von möglichen Auswirkungen auf Nutzer, deren E-Mail-Konten mit dieser Website verknüpft sind.

Und natürlich gilt es zu berücksichtigen, ob Testumgebungen oder Produktivumgebungen auf Schwachstellen untersucht werden. Wer produktive Umgebungen testet, muss darauf achten, dass das System nicht vollständig ausgebremst wird oder Datenbanken mit Testdaten geflutet werden. Wer hingegen Scans gegen Testumgebungen fährt, erhält unter Umständen nicht das Ergebnis, dass der Situation der produktiven Umgebung entspricht. Diese Fragen gilt es bereits während der Konzeptionierung der eigenen Penetrationstests und Schwachstellenscans zu beantworten.

Selbst wenn gute Schwachstellenscanner zum Einsatz kommen, müssen sich Sicherheitsverantwortliche immer auch noch in die Denkweise der Angreifer hineinversetzen können, um die richtigen Schwachstellen zu finden. Die Webschwachstellenscanner werden einen hohen Prozentsatz der vorhandenen Sicherheitslücken erkennen, aber eben nicht alle. Um alle Fehler zu finden sind altmodische, manuelle Analysen per Browser, Web-Proxy oder anderen Tools nach wie vor ein praktikabler Ansatz.

Fazit

CISOs und Sicherheitsverantwortliche müssen die Unterschiede zwischen manuellem und automatisiertem Scannen in Einklang bringen. Man sollte sich immer darüber im Klaren sein, dass man unter Umständen kein wirklich zu 100 Prozent vollständiges Bild der Situation hat. Vermutlich gäbe es immer noch einen anderen Test, der weitere Schwachstellen aufdecken würde. Selbst eingehende Scans von Webschwachstellen liefern in manchen Fällen aufgrund gewisser Versäumnisse nicht die optimalen Ergebnisse.

Daher sollten Sicherheitsverantwortliche im Hinblick auf die Schwachstellensuche immer nach neuen Verfahren, Tools und Informationen Ausschau halten. Mit den beschriebenen Vorgehensweisen und einem gesunden Mix an Richtlinien und Tools lässt sich jedoch die Gesamtsicherheit verbessern und die Websicherheit erhöhen.

Folgen Sie SearchSecurity.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Webanwendungen richtig absichern

Schwachstellen auf Webseiten erlauben Datendiebstahl

Webschwachstellen richtig aufspüren

 

Artikel wurde zuletzt im November 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Anwendungsangriffe (Cross-Site Scripting, Buffer Overflows)

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close