Montag, 2. Januar 2012


Topthema

Donnerstag, 24. April 2008 | Topthema

About Security #152: Schwachstellensuche: Contra Cookie Poisoning

(Link zum Artikel: http://www.entwickler.de/php/kolumnen/042891)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

Wie Sie die in About Security #151 vorgestellten Cookie-Poisoning-Schwachstellen finden und was Sie gegen derartige Angriffe unternehmen k�nnen, erfahren Sie in dieser Folge.

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

Schwachstellen finden

Wenn Sie eine Webanwendung auf Schwachstellen in der Zustandsverwaltung untersuchen, m�ssen Sie au�er den eigenen Parametern der Webanwendung auch die Parameter pr�fen, die vom Webbrowser automatisch an den Server gesendet werden. In diesem Fall ist es die G�ltigkeitsdauer der Cookies, sp�ter kommen auch noch verschiedene HTTP-Header dazu. Die entscheidende Frage ist wieder: �ndert sich bei einer Manipulation eines solchen Parameters unerlaubt ein Zustand? Bei der Manipulation der G�ltigkeitsdauer des Cookies ist das oft nicht sofort ersichtlich, im Beispiel aus About Security #151 w�rde die erschlichene l�ngere Nutzungsdauer evtl. erst nach dem 16.05. auffallen. Statt so lange zu warten, ist meist ein genauer Blick auf die entsprechenden Programmteile zielf�hrender: Wird die Lebensdauer des Cookies irgendwo als Eingabeparameter verwendet, und wenn ja, wozu?

Wurden Schwachstellen gefunden, geht es an deren Beseitigung:

Cookie Poisoning verhindern...

... ist unm�glich: Die Cookies werden auf dem Client gespeichert, und ein Angreifer kann alle auf dem Client gespeicherten Daten nach Belieben manipulieren. Und das gilt nicht nur f�r seinen eigenen Client, sondern mit Einschr�nkungen auch f�r die Daten eines normalen Benutzers. Cross-Site Scripting und Cross-Site Request Forgery sind in diesem Zusammenhang die bekanntesten Probleme. Cookies lassen sich au�erdem �ber das sog. Cross-Site Cooking manipulieren. Dabei nutzt der Angreifer eine Schwachstelle im Webbrowser aus, um einen Cookie f�r eine andere Domain zu setzen. W�hrend normalerweise der Webserver von boese.example keinen Cookie f�r eine andere Domain, z.B. gut.example, setzen darf, f�hrt eine Schwachstelle dazu, das ein solcher Cookie gesetzt werden kann.

Den Erfolg des Cookie Poisonings verhindern...

... ist eine erfolgversprechendere Strategie: Da man eine Manipulation der Cookies nicht verhindern kann, muss man die Folgen der Manipulation verhindern oder zumindest einschr�nken.

Dabei gilt wie immer: Den vom Client gelieferten Daten darf nicht vertraut werden. Wenn ein Benutzer z.B. nur f�r einen bestimmten Zeitraum auf die Anwendung zugreifen darf, dann muss die entsprechende Information auf dem Server gespeichert (und nat�rlich auch gepr�ft) werden. Das Gleiche gilt f�r die Anzahl durchgef�hrter Login-Versuche sowie alle anderen derartigen F�lle: Wann immer m�glich, sollten Zustandsinformationen auf dem Server gespeichert werden.

About Security: Die komplette Serie
Manipulationen erkennen

Ist eine Speicherung der Daten auf dem Client unumg�nglich, muss eine Manipulation des Parameters erkannt werden. Die Frage ist nur, wie. Im Folgenden soll der zu sch�tzende Parameter foo hei�en.

Um Manipulationen an Daten zu erkennen, verwendet man normalerweise Authentikationssysteme (siehe About Security #66). Dabei wird, vereinfacht ausgedr�ckt, eine Pr�fsumme berechnet, zusammen mit den Daten gespeichert und sp�ter mit der erneut berechneten Pr�fsumme verglichen. Wurden die Daten manipuliert, stimmen die beiden Werte nicht �berein. Die Webanwendung m�sste also f�r alle ausgegebenen foo Pr�fsummen berechnen und diese zusammen mit foo speichern. Sendet sp�ter ein Client ein foo samt Pr�fsumme an den Server, w�rde die Pr�fsumme erneut berechnet und mit der gespeicherten verglichen. Stimmen die Werte �berein, wurde foo nicht manipuliert. Das ist ziemlich aufw�ndig: Statt eines Werts m�ssen nun zwei auf dem Client gespeichert und von der Webanwendung ausgewertet werden.

Authentikationssysteme sind in diesem Fall also nicht die erste Wahl. Wie sieht es denn mit Konzelationssystemen (siehe About Security #66) aus? W�rde eine Verschl�sselung der Daten zum gew�nschten Ergebnis f�hren? Spielen wir das doch mal durch:

1. Die Webanwendung verschl�sselt foo, bevor sie den Parameter an den Client sendet
2. Der Client speichert den verschl�sselten Wert in einem Cookie
3. Der Client sendet den gespeicherten Wert im Rahmen eines Requests an den Server
4. Die Webanwendung entschl�sselt den empfangenen Wert und verwendet das Ergebnis als foo

OK, das funktioniert. Und was passiert, wenn ein Angreifer den Cookie manipuliert?

3. Der Angreifer manipuliert den Wert und sendet ihn dann an den Server
4. Die Webanwendung versucht, den empfangenen Wert zu entschl�sseln. Das schl�gt fehl � und damit auch der Angriff

Fazit: Wenn Sie die Daten vor der �bertragung an den Client verschl�sseln, kann der Angreifer sie nicht manipulieren. Eine Manipulation f�hrt dann nur dazu, dass es beim Entschl�sseln zu einem Fehler kommt und der manipulierte Wert verworfen wird.

Dass auch die Verschl�sselung nicht vor jedem Angriff sch�tzt, werden Sie in zuk�nftigen Folgen noch sehen. In der n�chsten Folge wird ein weiterer zustandsbasierter Angriff auf die Webanwendung behandelt: Das URL Jumping, bei dem ein Angreifer die vorgesehene Reihenfolge der besuchten Seiten verl�sst.

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 � II. Zustandsbasierte Angriffe"

Kommentare

Folgende Links könnten Sie auch interessieren