Donnerstag, 7. Juni 2012


Topthema

Donnerstag, 8. November 2007 | Topthema

About Security #130: DOM-basiertes XSS abwehren

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

Zur Tarnung des �ber DOM-basiertes XSS einzuschleusenden Schadcodes gibt es mehrere M�glichkeiten. Wie bereits in About Security #129 erw�hnt, ist der Schadcode nie Bestandteil der vom Server gelieferten HTML-Seite. Nur die im Request mitgelieferten Query-Daten verraten ihn, aber auch das kann umgangen werden. Dazu wird der Schadcode als Fragmentbezeichner getarnt:

http://www.beispiel.example/index.html#name=<script>alert('XSS')</script>

Das #-Zeichen markiert den darauf folgenden Rest als Fragmentbezeichner. Der ist nicht Teil des URIs, sondern enth�lt Referenzierungsinformationen, die vom Browser nach dem Empfang der Ressource lokal ausgewertet werden. Die meisten Browser senden den Fragmentbezeichner nicht an den Server, der dadurch nur

http://www.beispiel.example/index.html

zu sehen bekommt. Dieser Trick funktioniert nicht immer. Z.B. ist eine solche Tarnung nicht m�glich, wenn der Schadcode �ber den Benutzernamen oder das Passwort eines URLs nach dem Muster http://Benutzername:Passwort@www.beispiel.example eingeschleust wird. Der Schadcode wird dann als Bestandteil des Authorization-Headers an den Server gesendet, wo er erkannt werden kann. Er wird aber auch bei diesem Angriff nicht vom Server in die Antwort eingebettet, das erledigt sp�ter der Browser beim Parsen der empfangenen Seite.

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

Wird der zum Einschleusen des Schadcodes verwendete Parameter vom Server gepr�ft, kann er durch das Einf�gen eines zus�tzlichen Parameters getarnt werden:

http://www.beispiel.example/index.html?noname=
<script>alert('XSS')</script>

Muss der Parameter name vorhanden sein, kann er einfach angeh�ngt werden:

http://www.beispiel.example/index.html?noname=
<script>alert('XSS')</script>&name=Anton

Darf name nicht Bestandteil des zus�tzlichen Parameters sein, kann er evtl. �ber einen Parameter mit anderen, zul�ssigen Namen getarnt werden:

http://www.beispiel.example/index.html?nix=name=
<script>alert('XSS')</script>&name=Anton

Der nicht verwendete Parameter nix kommt zuerst, als dessen Wert wird der f�r das Einschleusen verwendete Parameter samt Schadcode verwendet: name=<script>alert('XSS')</script>.

Schwachstellen finden

Wie zu sehen ist, kann der eingeschleuste Schadcode vor dem Server und allen serverseitigen Schutzeinrichtungen wie IDS/IPS oder Web Application Firewall verborgen werden. Dementsprechend funktionieren auch keine serverseitigen Filter. Auch die Erkennung durch die meisten Fuzzing nutzenden Schwachstellenscanner ist schwierig, da diese nur die Antworten des Servers auf die eingeschleusten Testdaten pr�fen. Au�er einer (ggf. automatisierten) Analyse des JavaScript-Codes k�nnen nur manuelle Tests �ber einen Browser und automatisierte Tests, die auch die Codeausf�hrung auf dem Client pr�fen, DOM-basierte XSS-Schwachstellen finden. Bei den letzten beiden m�ssen dabei alle DOM-Objekte mit passenden Werten besetzt sein.

Gegenma�nahmen

Potenziell gef�hrlich sind alle F�lle, in denen die HTML-Seite selbst oder das DOM manipuliert werden. Dabei ist darauf zu achten, woher die verwendeten Daten kommen und ob ein Angreifer sie manipulieren kann. Sind �nderungen des Clients am DOM mit vom Client und damit einem m�glichen Angreifer manipulierbaren Daten notwendig, m�ssen diese auf dem Client gepr�ft werden. Das betrifft z.B. die schon in About Security #129 erw�hnten document-Objekte, aber auch z.B. window.location und deren Eigenschaften.

About Security: Die komplette Serie

Die einfachste Gegenma�nahme besteht darin, auf dem Client weder �nderungen am DOM noch sensitive Aktionen mit vom Client gelieferten Daten zuzulassen. Wann immer m�glich, sollten daf�r serverseitige Skripts verwendet werden.

Nur weil �ber DOM-basiertes XSS eingeschleuster Schadcode getarnt werden kann, darf auf serverseitige Pr�fungen durch IDS/IPS oder Web Application Firewall nicht verzichtet werden. Strenge Regeln, die festlegen, welche Parameter vorhanden sein m�ssen und/oder d�rfen und wie deren Werte aufgebaut sind, erschweren ein Ausnutzen DOM-basierter XSS-Schwachstellen.

Die Folgen � was kann XSS?

Ab jetzt geht es wieder allgemein um XSS-Angriffe. Wie der Schadcode in den Browser des Opfers gelangt, ist dabei unerheblich.

XSS ist eine seit langem bekannte Schwachstelle. Inzwischen haben sich nicht nur die Webanwendungen, sondern nat�rlich auch die Sch�dlinge dazu weiterentwickelt. Durch die Entwicklung vom Web zum Web 2.0 mit seinen AJAX-Bibliotheken, neuen Formaten wie JSON und neuen Verbreitungswegen wie RSS und REST/SOAP sind auch die M�glichkeiten der Angreifer gewachsen.

Die m�glichen Folgen eines XSS-Angriffs reichen vom Einschleusen gef�lschter Inhalte �ber das Aussp�hen von Passw�rtern und Authentifizierungs-Cookies bis zur Ausnutzung von Schwachstellen im Browser, um eigenen Code auszuf�hren und dadurch das angegriffene System zu kompromittieren.

Einige Beispiele:

  • Ein Angreifer, der JavaScript ausf�hren kann, hat die Kontrolle �ber den Browser:
    • Aussp�hen von Cookies (siehe auch About Security #14)
    • Aussp�hen von Tastatureingaben oder Mausevents
    • Auslesen von Passw�rtern aus z.B. dem Password-Safe von Firefox oder dem Schl�sselring von Mac OS X
    • Aussp�hen der Browser-History
    • Einschleusen falscher Informationen
  • Wer die Kontrolle �ber den Browser hat, befindet sich im lokalen Netz � und damit hinter der Firewall:
    • Portscan �ber JavaScript
    • Ausnutzung von Default-Passw�rtern in Netzwerkhardware
  • Wer die Kontrolle �ber den Browser hat, ist nur einen Schritt von der Kontrolle �ber das System entfernt � er muss "nur" eine Schwachstelle finden und ausnutzen.

Das Aussp�hen von Cookies und Tastatureingaben sowie das Auslesen von Passw�rtern werden in der n�chsten Folge als erste Angriffe �ber XSS vorgestellt.

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 "Sichere Webanwendungen � Cross-Site Scripting"

Kommentare

Folgende Links könnten Sie auch interessieren