Test-Feld
Tools und Proxies helfen bei Penetrationstests gegen Web-Applikationen, um SicherheitslĂĽcken aufzudecken und zu beseitigen.
Mangelnde Sorgfalt beim Programmieren von Web-Applikationen, insbesondere wenn Nutzerinteraktion möglich sein soll, kann schnell zu einem Sicherheitsproblem führen -- bis hin zum Einbruch in den Server. Kleine Schwachstellen im Code können da große Wirkung haben: XSS (Cross-Site-Scripting) [1] und SQL-Injection [2] sind in aller Munde. Gleiches gilt für das Ausspähen der Server-Struktur durch Verzeichnis-Sprünge (Directory-Traversals) und so womöglich vielleicht der Zugriff auf eigentlich geschützte Dateien. Auch gegen so genannte Unicode-Attacken, bei der ein Angreifer versucht, den Server zu überlisten, indem er anstelle von ASCII-Zeichen deren Unicode als hexadezimale Zahl (%c0%af) sendet, muss die Software resistent sein. Wie man sie vermeidet, sollte mittlerweile zum Standard-Wissen jedes Programmierers zählen.
Vertrauen in die eigenen Programmierfähigkeiten ist gut, Kontrolle ist besser. Um zu überprüfen, wie widerstandsfähig eine Web-Applikation gegen Angriffe ist und wie sie auf provozierte Fehlersituationen und gezielte Manipulationen reagiert, sollte man sie vor dem Produktivbetrieb einem Penetrationstest unterziehen. Neben dem Wissen um die Hintergründe von Schwachstellen ist zusätzlich noch die Kreativität und Intuition des Testers beim Eingeben von Formulardaten, dem Aufrufen von Webseiten und der Interpretation der zurückgelieferten Ergebnisse gefragt. Natürlich stehen für derartige Tests auch spezielle Werkzeuge zu Verfügung, die die Arbeit erleichtern.
Versteckte Freunde
Um Informationen über ein System oder eine Applikation zu sammeln, lohnt sich der Blick in den übertragenen HTML-Quelltext. Der kann oft mehr Auskunft geben, als die Ausgabe des Browsers vermuten lässt. Klartext-Zugangsdaten in HTML-Kommentaren sind zwar zur Seltenheit geworden, Copyright-Infos verraten aber zumindest verwendete Module und mögliche Schwachstellen. Weitere Informationen lauern in INCLUDE-Dateien. HIDDEN-Felder sind ebenfalls gang und gäbe und werden vom Programmierer hin und wieder bei der Validierung vergessen. Dabei lassen sich hier andere Werte sogar recht einfach einschleusen: Entweder direkt über eine GET-Anfrage, also als Parameterwert in dem URL, oder in einer lokalen Kopie des HTML-Dokumentes.
Bei letzterer Methode muss der Tester allerdings noch den Pfad des ACTION-Tags in seiner lokalen Kopie anpassen. Noch leichter geht es mit UnterstĂĽtzung durch einen speziellen Proxy (siehe unten, 'Werkzeugkasten'): Den dort angezeigten Wert kann man einfach ĂĽberschreiben und dann die Anfrage abschicken.
Anfällig sind generell Parameter mit serverseitig vorgefüllten Werten. Insbesondere gilt dies für Menüs, die viele Auswahlmöglichkeiten bieten:
<form action"kontostand.asp" method="get">
...
<select name="konto">
<option value="12000123">12 000 123
<option value="12555666">12 555 666
...
</select>
...
</form>
Ist keine Autorisierung erforderlich oder hat sie bereits stattgefunden, kann man jede beliebige gültige Kontonummer selbst angeben. Bei der oben genannten Proxy-Methode ändert man also lediglich den konto-Parameter im GUI des Proxy auf den gewünschten Wert und schickt die Anfrage ab. Ähnlich problematisch sind Prüffunktionen, die direkt im HTML-Code, normalerweise in Form von JavaScript, untergebracht sind. Sie verifizieren beispielsweise Kreditkartennummern oder stellen sicher, dass der Nutzer wirklich alle gewünschten Angaben (Zahlungsweise, Kontonummer etc.) macht, bevor der Zugang für ihn freigeschaltet wird. Wurde die anschließende Validierung auf dem Server vergessen, reicht es aus, den entsprechenden JavaScript-Code einfach in einer lokalen Kopie zu entfernen. Verwendet die zu testende Site gar gekapselte Inhalte wie Flash, um Anmeldungen oder ähnliches durchzuführen, helfen Paket-Schnüffler wie Ethereal bei der Kontrolle, welche Verbindungsdaten und Passwörter über die Leitung gehen.
