Mittwoch, 6. Oktober 2010


Topthema

Donnerstag, 6. M�rz 2008 | Topthema

About Security #146: Schwachstellensuche: Infos im Client sammeln

(Link zum Artikel: http://www.entwickler.de/php/kolumnen/041832)

Nach dem Sammeln von Informationen auf dem Server (siehe About Security #144) und deren Auswertung (siehe About Security #145) geht es diesmal zuerst weiter um die Suche nach nicht offensichtlichen Informationen auf dem Server und danach um die Untersuchung des Clients.

Interessante Informationen k�nnen auch in nicht verlinkten, separaten Verzeichnissen liegen. Vielleicht gibt es ja ein ungesch�tztes Verzeichnis test/ mit einer noch nicht ausgereiften Testversion der Anwendung, oder ein Verzeichnis admin/ mit einer Administrationsoberfl�che. Oft sind auch nicht ben�tigte Beispielanwendungen oder nicht ben�tigte Bibliotheken der verwendeten Entwicklungsumgebung und �hnliches noch auf dem Webserver gespeichert. Auch diese Seiten k�nnen Schwachstellen enthalten oder unn�tige Informationen preisgeben.

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

Ebenfalls in diesem Schritt kann nach weiteren Diensten auf dem zu untersuchenden Server gesucht werden: Gibt es einen SSH-Zugang, l�uft auf einem anderen Port des Webservers eine Administrationsanwendung usw., kurz: Ein Portscan ist f�llig. Dazu eignet sich z.B. Nmap.

Findet man bei der Analyse der eigenen Webanwendung in diesem Schritt irgendetwas, hat man wahrscheinlich vorher einen Fehler gemacht. Und der sollte dann gleich korrigiert werden: Nicht ben�tigte Dienste werden deaktiviert und der Webserver so konfiguriert, dass nur die gew�nschten Seiten ausgeliefert werden. Ebenso ist es nun an der Zeit, einen eventuell fehlenden Zugriffsschutz f�r sensitive Teile der Anwendung, wie z.B. den Administrationsbereich, nachzur�sten bzw. zu aktivieren. Nicht ben�tigte Komponenten m�ssen gel�scht oder mit einem Zugriffsschutz versehen werden. Es w�re doch �rgerlich, wenn die eigene Anwendung absolut sicher ist und dann ein Angreifer eine Schwachstelle in einer unbenutzten, veralteten Bibliothek ausnutzt, um die Kontrolle �ber den Server zu �bernehmen. Ein gutes Tool, um nach bekannten Schwachstellen zu suchen, ist Nikto.

Schritt 3: Untersuchung des Clients

Bei der Untersuchung des Clients gibt es gro�e Unterschiede zwischen klassischen, statischen Websites und den dynamischen (AJAX-)Anwendungen des Web 2.0. AJAX-Anwendungen haben im Gegensatz zu statischen Webseiten interne Zust�nde, die ihr Verhalten beeinflussen. Die Reihenfolge der Benutzerinteraktionen hat Auswirkungen auf den Ablauf des JavaScript-Codes, dazu kommen u.U. automatische Requests zur Aktualisierung von z.B. Aktienkursen oder Wetterdaten. Hinzu kommen �nderungen w�hrend der Laufzeit: Serverantworten enthalten neuen JavaScript-Code, der das Verhalten der Seite �ndern kann. Doch bevor die sich daraus ergebenden Probleme betrachtet werden, wird die Untersuchung der statischen Seiten beschrieben.

Schritt 3a: Untersuchung statischer Seiten

Bei der Untersuchung statischer Seiten richtet sich das Interesse prim�r darauf, weitere Hinweise f�r den Angriff auf die Webanwendung zu erlangen. Im Wesentlichen geht es dabei um Beschr�nkungen der Benutzereingaben: Wenn die Eingaben bereits auf dem Client gepr�ft oder auf bestimmte Werte beschr�nkt werden, findet ja vielleicht auf dem Server keine weitere Pr�fung mehr statt. Da der Angreifer den Client beliebig manipulieren oder sogar simulieren kann, kann er auch die an den Server gesendeten Parameter beliebig manipulieren und damit Schaden anrichten.

About Security: Die komplette Serie

Der erste Blick gilt Eingaben wie Text- oder Auswahlfeldern, Radio-Buttons und Select-Tags. Sind Textl�ngen begrenzt, welche Werte stehen bei Auswahlfeldern, Radio-Buttons und Select-Tags zur Verf�gung? Danach geht es darum, diese Werte zu manipulieren und die Reaktion der Webanwendung auszuwerten. Dazu stehen drei M�glichkeiten zur Verf�gung: Per GET �bertragene Parameter k�nnen direkt in dem URL manipuliert werden. POST-Parameter k�nnen entweder vor dem Senden in der lokal gespeicherten Seite ge�ndert oder nach dem Senden "on the fly" �ber einen Proxy wie Paros oder ein Tool wie die Firefox-Erweiterung Firebug manipuliert werden. Bei einer �nderung in der gespeicherten Seite m�ssen ggf. relative Links in der Seite in passende absolute umgewandelt werden.

Ein (zugegeben etwas konstruiertes) Beispiel: In einem Webshop wird die Anzahl der gew�nschten Artikel �ber ein Drop-Down-Men� ausgew�hlt, das Werte von 0 bis 10 vorgibt. Was passiert, wenn f�r diesen Parameter ein negativer Wert �bertragen wird? Eventuell findet auf dem Server keine weitere Pr�fung statt, weil ja nur Werte von 0 bis 10 ausgew�hlt werden k�nnen. Wird dann der Rechnungsbetrag nach dem Muster "Anzahl * Preis in der Datenbank" berechnet, w�rde eine negative Anzahl zu einem negativen Rechnungsbetrag bzw. einer Verminderung des Gesamtbetrags f�hren.

Falls die L�nge eines freien Textfeldes begrenzt ist, k�nnte ein l�ngerer Wert f�r den betreffenden Parameter auf dem Server zu einem Puffer�berlauf f�hren, sofern dort keine Pr�fung des Wertes erfolgt.

W�hrend sich die Schwachstellensuche bisher auf den Server und auf die vom Benutzer im Client zumindest in bestimmten Grenzen manipulierbaren Parameter konzentriert hat, geht es in der n�chsten regul�ren Folge u.a. um die Werte in versteckten Feldern. Davor gibt es in der n�chsten Woche den schon traditionellen Bericht �ber Neuigkeiten von der CeBIT.

Wenn Sie Fragen oder Themenvorschl�ge haben, k�nnen Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

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

Kommentare

Folgende Links könnten Sie auch interessieren