entwickler.com

In About Security #144 wurde beschrieben, wie der Aufbau der auf Schwachstellen zu untersuchenden Webanwendung ermittelt werden kann. In dieser Folge geht es um die Auswertung der dabei gesammelten Daten.

Schritt 1b: Analyse der Webseiten

Zuerst werden die gesammelten Seiten eine nach der anderen analysiert. Dazu wird der Code jeder Seite betrachtet und nach nützlichen Informationen in Kommentaren gesucht. Das können z.B. auskommentierte Codeteile in der Programmiersprache der Webanwendung sein, die durch einen falsch gesetzten Tag oder HTML-Kommentar in die ausgegebene Seite gelangt sind. Solche Codefragmente können Aufschluss über den inneren Aufbau der Webanwendung geben oder sogar Informationen über die Konfiguration wie Namen von Servern, SQL-Tabellen usw. enthalten. Die HTML-Dateien können sowohl manuell als auch mit einem Tool wie z.B. grep mithilfe von regulären Ausdrücken durchsucht werden.

Interessant sind besonders folgende Punkte:

• HTML-Kommentare (<!-- .. -->) enthalten meist nur Hinweise auf Bereiche der Seite, können aber manchmal auch interessantere Informationen enthalten.
• Programm-Kommentare (z.B. //, /* .. */, <!--- .. ---> (Coldfusion, leicht mit HTML-Kommentaren zu verwechseln) ) dürften normalerweise nicht in der ausgegebenen HTML-Seite erscheinen. Tun sie es doch, sind die Chancen groß, dass sie nützliche Informationen enthalten.
• Versteckte Eingabefelder (<input type='..' hidden>) können z.B. Tokens zum Schutz vor CSRF-Angriffen oder andere brauchbare Informationen enthalten.
• SQL-Queries (SELECT .. FROM .., UPDATE .. SET .., INSERT INTO .., DELETE FROM ..) können außer in Fehlermeldungen nur durch einen Programmier- oder Konfigurationsfehler in die ausgegebene Seite gelangen. Sie liefern unter Umständen Informationen über die Datenbankstruktur und den Aufbau der verwendeten Queries.
• IP-Adressen interner Server
• Web- oder E-Mail-Adressen, z.B. der Entwickler, die Informationen über beteiligte Unternehmen liefern. Vielleicht basiert die Webanwendung ja auf einem bekannten Programm und wurde nur optisch angepasst?

Schritt 1c: Analyse der übergebenen Parameter

Als Nächstes werden die übergebenen Parameter untersucht. Was passiert bei falschen Eingaben? Die zurückgegebenen Fehlermeldungen, egal ob vom Webserver oder der Webanwendung, können nützliche Informationen liefern. Z.B. kann in einer Fehlermeldung des SQL-Servers die fehlgeschlagene Anweisung samt Server- und Tabellennamen enthalten sein. Auch immer wieder gern gesehen sind unterschiedliche Fehlermeldungen bei einem fehlgeschlagenen Login-Versuch: Liefert die Anwendung unterschiedliche Fehlermeldungen für einen falschen Benutzernamen und ein falsches Passwort, kann der Angreifer gültige Benutzernamen ermitteln. Gibt es dann auch keinen Schutz gegen Brute-Force-Angriffe, kann das böse enden. Daher sollten solche Fehlermeldungen neutral formuliert werden, z.B. "Benutzername und Passwort passen nicht zueinander" oder "Benutzername und/oder Passwort sind falsch".

Entsprechendes gilt für alle Fehlermeldungen: Auf produktiv eingesetzten Systemen sollten die nur mitteilen, dass ein Fehler aufgetreten ist. Details sind für den Benutzer uninteressant, aber für den Angreifer Gold wert. Ebenso sollten auf produktiv eingesetzten Systemen besser keine Kommentare in den ausgegebenen HTML-Seiten enthalten sein. Ein normaler Benutzer sieht sie sowieso nicht, dafür liefern sie Angreifern unter Umständen nützliche Informationen. Alternativ könnte man nur die Kommentare mit möglicherweise für einen Angreifer nützlichen Informationen löschen. Das bedeutet aber nur unnötigen Aufwand. Einfacher ist es, alle Kommentare zu löschen.

Das klingt zwar nach "Security by Obscurity", hat damit aber nur teilweise zu tun. Die Sicherheit hängt nicht vom Verbergen der Informationen ab. Die Webanwendung darf keine Schwachstellen enthalten – unabhängig davon, ob der Angreifer nun mehr oder weniger Informationen besitzt. Aber man muss es einem Angreifer ja nicht unnötig leicht machen.

Schritt 2: Weitere Informationen sammeln

Nachdem die offensichtlichen Informationen gesammelt wurden, kann man anfangen, die nicht offensichtlichen zu suchen. Dazu wird im Wesentlichen nach nicht verlinkten Seiten gesucht. Wenn z.B. ein Verzeichnis die verlinkten Dateien geschäftsbericht04.pdf, geschäftsbericht05.pdf und geschäftsbericht06.pdf enthält, ist ja vielleicht auch der noch nicht veröffentlichte aktuelle als geschäftsbericht07.pdf vorhanden.

Die in Schritt 1a aufgebaute Sitemap kann dabei helfen, Muster in den Dateinamen und interessante Verzeichnisse zu finden. Dabei hängen die mögliche Ergebnisse sehr von der untersuchten Anwendung ab. So werden z.B. in einem Buchkatalog, in dem jedes verfügbare Buch auf einer eigenen Seite beschrieben wird, auf diesen Seiten keine für den Angreifer verwertbaren Informationen zu finden sein. Ganz anders sieht es hingegen bei einem Benutzerverzeichnis aus, bei dem die Benutzer nur die vollständigen Profile bestimmter anderer Benutzer sehen dürfen. Kann dann über z.B. benutzer-[lfd.Nr.].html oder benutzer.php?id=[lfd.Nr.] auf beliebige Profile zugegriffen werden, könnte der Angreifer dadurch nicht für ihn bestimmte Informationen erlangen.

In der nächsten Folge geht es um das Sammeln von Informationen im Client.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Schwachstellensuche – I. Informationen sammeln"

• About Security #144: Schwachstellensuche: Allgemeine Infos sammeln
• About Security #145: Schwachstellensuche: Daten auswerten
• About Security #146: Schwachstellensuche: Infos im Client sammeln
• About Security #147: Schwachstellensuche: AJAX-Clients (1)
• About Security #148: Schwachstellensuche: AJAX-Clients (2)