Mit XSS können Angreifer eine Web-Anwendung einfach kompromittieren und von innen heraus beschädigen. Wir klären auf, was Cross-Site Scripting ist und wie es sich am effektivsten vermeiden lässt. [...]
Am 4. Oktober 2005 dämmert es kalt und klar. Übernächtigte Myspace-Nutzer erwachen aus ihrem Schlaf, um sich sogleich in die zu dieser Zeit weltgrößte Social Media Plattform einzuloggen und neue Freunde zu finden. Menschen wie Samy Kamkar. Samy war so verbissen auf der Suche nach neuen Freunden, dass er Cross-Site Scripting (XSS) einsetzte, um sein MySpace-Profil zu diesem Zweck auszunutzen. Der von ihm verwendete JavaScript – heute noch liebevoll „Samy Worm“ genannt – fügte damals automatisch jeden seiner Myspace-Profil-Besucher zu seiner Freundesliste hinzu und sendete den Betroffenen eine Popup-Nachricht, die verkündete: „Samy ist mein Held!“. Als Myspace ihm den Stecker zog, hatte er seinem Profil bereits eine Million neue Freunde hinzugefügt. Heute ist Kamkars legendärer Streich ein Sinnbild der Fragilität von Web-Applikationen und der Unfähigkeit, User-Input ordentlich zu bereinigen.
Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
SemperVideo erklärt anschaulich, wie eine XSS-Attacke abläuft.
Was ist eine XSS–Schwachstelle?
Grundsätzlich wird eine XSS-Attacke von einem Angreifer ausgeführt, der einen schädlichen Code in ein Web-Formular oder eine Web-App-URL eingibt, um ein Programm dazu zu bringen, etwas zu tun, das es nicht tun sollte. Nehmen wir an, das Online-Formular einer Web-Anwendung fordert Sie dazu auf, Ihren Namen einzugeben, doch Sie schreiben stattdessen:
<script>alert;(„Ich bin ein reflektierter XSS-Angriff!“)</script>
Drücken Sie Enter, erscheint eine Pop-Up-Nachricht mit dem Inhalt: „Ich bin ein reflektierter XSS-Angriff!“. In diesem Moment sollte klar sein, dass die Türen auch für jeden weiteren Angriff weit offenstehen und sich die zuständigen Wächter offenbar gerade beim Mittagsschlaf befinden. Oder es sind vielmehr die Betreiber der Web-Applikation selbst, die ihre Sicherheitsvorkehrungen vernachlässigt haben.
Zwar sind nur noch wenige Web-Applikationen im Jahr 2018 derart verwundbar, doch herrscht ein stetes, internationales Wettrüsten zwischen XSS-Angreifern und den Betreibern von Webseiten. Im Falle einer Eskalation finden Angreifer immer wieder leicht undichte Stellen in der Abwehr von Web-Applikationen – und eine erfolgreiche XSS-Attacke kann in so einem Fall schwere Folgen für Sie und Ihr Unternehmen haben.
Das Open Web Application Security Project, kurz OWASP, ist eine Non-Profit-Organisation, die es sich zur Aufgabe gemacht hat, die Sicherheit von Web-Anwendungen und Online-Diensten zu verbessern. Auf ihrer Website bezüglich der zehn häufigsten kritischen Sicherheitsrisiken von Web-Applikationen heißt es:
„XSS-Mängel scheinen dann auf, wenn eine Anwendung nicht-vertrauenswürdige Daten ohne ordentliche Validierung oder Maskierung auf eine neue Web-Page implementieren will; oder wenn die Anwendung eine bereits existierende Web-Page mit Nutzerangaben aktualisiert, indem sie ein Browser-Programmierinterface nutzt, das HTML oder JavaScripts erstellen kann. XSS erlaubt es den Angreifern, in den Browsern ihrer Opfer bestimmte Scripts auszuführen, die User-Sessions kontrollieren, Webseiten verunstalten und den Nutzer auf schädliche Websites umleiten können.“
Herr Kamkar mag damals noch ein Kind gewesen sein, das keine schlechten Absichten hegte, doch dieselbe Art von XSS–Schwachstelle ist, laut OWASP, noch immer in Zweidritteln aller eingesetzten Web-Applikationen verbreitet und damit die zweithäufigste Art der Web-Attacke nach SQL-Injection. Der Begriff „Cross-Site Scripting“ hat sich in den letzten 15-20 Jahren derart verändert, dass mitre.org heute die weniger plakative, aber präzisere Bezeichnung „missbräuchliche Bereinigung von Input während der Webpage-Generierung“ bevorzugt. Bereinigen Sie diese Form des User-Inputs unbedingt, um zumindest weniger begabten Angreifern den Nährboden entziehen. XSS ist ein gut erforschter Angriffsvektor, der in Internetjahren eigentlich bereits steinalt ist. Wenn Sie sich gegen solche Angriffe nicht schützen, kommen Sie Ihrer Sorgfaltspflicht nicht ausreichend nach.
Typen von XSS
Insgesamt gibt es drei Arten von XSS-Attacken: Reflektierte (nicht persistente) XSS, persistente XSS und Document Object Model (DOM)-basierte XSS.
Reflektierte XSS wird oft als Teil eines Phishing-Vorhabens genutzt, und ist nicht nur die am einfachsten auszunutzende, sondern auch am einfachsten vorzubeugende Form des XSS. Der oben genannte <script> ist bereits ein rudimentäres Beispiel für reflektierte XSS: Ein Angreifer injiziert schädliche Inhalte in eine HTTP Anfrage und die Ergebnisse werden dann auf den betroffenen User zurück-„reflektiert“.
Natürlich wird ein Angreifer wenig Grund haben, sich selbst zu schaden. Er wird also mit mehr oder weniger geschickten Phishing- und Social Engineering-Tricks versuchen, sein Opfer dazu zu bringen, auf einen schädlichen Link zu klicken. Dieser ist in der Lage ist, eine vorhandene Lücke in der Web–Applikation auszunutzen. Damit wird der vorher implementierte, schädliche Code auf den User reflektiert und in Gang gesetzt. Auf diese Weise könnte der Angreifer beispielsweise die laufende Browser-Session des User hijacken und darüber hinaus steuern oder korrumpieren. Aufgrund der Einfachheit dieses Vorgehens lässt sich reflektierte XSS häufig in Phishing-Attacken finden.
Persistente XSS-Attacken funktionieren, indem der Angreifer eine Web–Applikation dazu bringt, den schädlichen Code in der Datenbank des Programms zu speichern. Einmal auf dem Server gespeichert, kann der Code direkt das System angreifen und zu vielen, wenn nicht sogar zu allen Endnutzern transportiert werden. Eine bekannte Form der Anwendung für persistente XSS ist es, einen schädlichen Code in die Kommentar-Sektion von Blogs zu posten.
<script>alert;(„Ich bin eine persistente XSS Attacke in einem Blog-Kommentar!“)</script>
Jeder, der den Blog besucht, würde ein Opfer des Schädlings werden. Deshalb sind persistente XSS die gefährlichste Art des Cross-Site-Scripting. Warum nur einen User attackieren, wenn man sie alle attackieren könnte?
Die dritte und neueste Art des XSS ist die DOM-basierte Form. Anders als die reflektierte oder die persistente XSS, attackiert die Dom-basierte XSS den Code auf Seiten des Client. Oft passiert dies durch JavaScript – nicht aber auf der Server-Seite der Web–App –, um den schädlichen Code direkt im Browser seines Opfers auszuführen.
Cross-Site Scripting vorbeugen
Erinnern Sie sich: Vertrauen Sie niemals dem User-Input. Ihre Web–Applikation sollte unbedingt Probleme mit User-Input haben, und das sollte sich am besten auch niemals ändern. Die gute Nachricht ist, XSS ist ein sehr alter Angriffsvektor und die Tools, die Sie brauchen, um sich zu schützen, sind ausgereift und leicht zu nutzen. Nutzen Sie sie.
Setzen Sie vertrauenswürdigen Input auf die Whitelist. Eine Blacklist ist zu anfällig und wird auf kurz oder lang nicht den gewünschten Effekt haben. Entscheiden Sie sich, welcher Input für ihre Web–Applikation sicher sein könnte, und lehnen Sie alles andere ab oder maskieren sie es. OWASP empfiehlt sogar, erstmal von Grund auf alles abzulehnen. Innerhalb des HTML gibt es zu viele sonderbare Kontexte, sodass eine Liste mit allen Regeln der Maskierung schnell viel zu kompliziert werden würde.
Für JavaScript gilt dieser Vorsatz gleich doppelt: Man sollte niemals einen JavaScript aus unbekannter Quelle annehmen oder sogar starten, rät die OWASP. Bei einem Parameter namens ‚callback‘, der den Ausschnitt eines JavaScipt Codes enthält, kann auch Maskierung nicht mehr helfen.
Das Cheat Sheet der OWASP Top Ten zum Thema XSS-Prävention geht noch tiefer auf dieses Thema ein. Es empfiehlt sich also, das gesamte Dokument zu lesen. Vergessen Sie nicht, Ihre App regelmäßig auf Anfälligkeiten gegenüber XSS-Angriffen zu überprüfen.
Wo liegt der Unterschied zwischen XSS und CSRF?
Cross-Site Scripting (XSS) und Cross-Site Request Forgery (CSRF) sind verwandte Vorgehensweisen, um den Browser eines Nutzers anzugreifen. Der Hauptunterschied ist jedoch, dass CSRF die authentifizierte Session eines Users ausnutzt (wenn er beispielsweise in seinen Bank-Account eingeloggt ist), und XSS überhaupt keine authentifizierte Session braucht, um effektiv zu sein. Nehmen wir an, Sie sind gleichzeitig sowohl in Ihren Twitter-, als auch in Ihren Online-Banking-Account eingeloggt und klicken auf einen Link, der so aussieht wie dieser:
www.yourbank.com/sendmoney,do?from=you&to=attacker&amount=5000
Abhängig davon, wie Ihre Bank Session Tokens verwaltet und welchen Browser Sie nutzen, wären Sie im nächsten Augenblick vermutlich um knappe 5000 Euro ärmer. XSS mag vielleicht der gefährlichere Angriffsvektor sein, aber es ist dennoch wichtig, sich sowohl gegen XSS, als auch gegen CSRF zu schützen. Mehr über CSRF Sicherheitsmaßnahmen finden Sie im OWASP CSRF Prevention Cheat Sheet.
Wenn XSS angreift
Cross-Site Scripting (XSS) mag für Angreifer zwar kein großes Hindernis sein, die im Sinn haben, sich eine Lücke in einer Web-Applikation zu Nutze zu machen – es ist aber auch gleichermaßen einfach, genau diese Angriffe zu abzufedern, indem man die notwendigen Sicherheitsmaßnahmen trifft. Der Samy Worm war ein gutartiger Hack, der niemandem größeren Schaden zugefügt hat, und doch wird die selbe Form der Schwachstelle noch immer täglich von Spionen und Verbrechern mit böser Absicht genutzt. Mehr als ein Jahrzehnt nachdem der Samy Worm zum ersten Mal eingesetzt wurde, wirkt Unfähigkeit, das Risiko eines XSS-Angriffs aktiv abzumildern, wie grobe Fahrlässigkeit.
* J. M. Porup ist Senior Writer bei CSO.com
Be the first to comment