Cross-Site Scripting (XSS) ist eine Sicherheitslücke, die normalerweise in Websites und/oder Webanwendungen zu finden ist, die Benutzereingaben akzeptieren. Beispiele hierfür sind Suchmaschinen, Anmeldeformulare, Message Boards und Kommentarfelder.
Cyberkriminelle nutzen diese Schwachstelle, indem sie Zeichenfolgen von ausführbarem bösartigem Code in diese Funktionen eingeben. Dadurch wird der bösartige Code in den Inhalt der Zielwebsite eingespeist, was ihn zu einem Teil der Website macht und somit Opfer betrifft, die diese Website besuchen oder ansehen können. Der Code kann sich auch als vorübergehender Inhalt darstellen, der nicht tatsächlich Teil der Website ist, sondern nur dem Besucher zu sein scheint. Das macht den Anschein, dass die Website tatsächlich von Cyberkriminellen kompromittiert wird.
Cyberkriminelle können diese Schwachstelle auch nutzen, um die Kontrolle über eine Website zu übernehmen oder eine Website direkt zu gefährden sowie andere vorhandene Schwachstellen auf dem Server oder der Software der Website auszunutzen.
Mit XSS können Cyberkriminelle vertrauenswürdige Websites in bösartige Websites verwandeln und so nicht nur den Opfern, sondern auch dem Ruf des Eigentümers der vertrauenswürdigen Website Schaden zufügen.
Websites, die von XSS kompromittiert werden, können eine beliebige Anzahl von Bedrohungen verursachen, um das System eines Benutzers anzugreifen. Dies kann alles umfassen, von unangemessenen Inhalten bis hin zu Malware, die auf das System heruntergeladen wird, ohne dass der Benutzer davon weiß.
So gefährlich XSS auch ist, es gibt Möglichkeiten, eine solche Schwachstelle zu beheben. Website-Besitzer müssen sicherstellen, dass alle ihre Webanwendungen, die Benutzereingaben akzeptieren, dies so tun, dass sie die eingegebenen Zeichenfolgen zuerst bereinigen, bevor sie die resultierende Seite der Eingabe erstellen. Dadurch wird verhindert, dass eine Codeinjektion stattfindet. Nutzer hingegen sollten Skripting in ihren Browsern deaktivieren und vermeiden, auf Links von verdächtigen Parteien oder Absendern zu klicken.
Laut Open Web Application Security Project (OWASP) fallen XSS-Angriffe in eine von drei Kategorien: reflektiertes XSS, gespeichertes XSS und Document Object Model (DOM) XSS. Diese sind unten aufgeführt.
Ein widergespiegelter XSS-Angriff tritt auf, wenn ein Hacker ein bösartiges Skript an eine anfällige Webanwendung liefert, die der Server dann in der HTTP-Antwort zurückgibt. Der Browser des Opfers führt das bösartige Skript als Teil der HTTP-Antwort aus, gefährdet den legitimen Benutzer und sendet private Informationen zurück an den Hacker.
Gespiegelte XSS-Angriffe zielen in der Regel auf Fehlermeldungen oder Suchmaschinenergebnisseiten ab, da es einfach ist, eine bösartige E-Mail mit einem Link zu senden, auf den viele Benutzer klicken. Wenn der Benutzer auf den Link klickt, erhält der Server die Anforderung, die das bösartige Skript enthält, und da es nicht gespeichert ist, antwortet er, indem er einen Code zurück an den Benutzer sendet. Wenn Benutzereingaben nicht ausreichend validiert und bereinigt werden oder wenn Daten aus einer Anfrage unsicher dupliziert werden, besteht das Risiko von reflektierten XSS-Schwachstellen.
Die erste Verteidigungslinie gegen XSS-Angriffe besteht darin, Inhalte zu filtern und Benutzereingaben zu überprüfen. Sie können Safelists und Blocklists von Skriptanbietern verwenden, um riskante Datenmuster abzulehnen.
Darüber hinaus können Sie eine strenge Content Security Policy (CSP) implementieren, die Ihnen hilft, die Quelle von Inline-Skripten zu identifizieren und das Risiko von reflektierten XSS-Angriffen zu reduzieren. Ein leistungsstarker CSP gibt Ihnen die Kontrolle über Skripte und die Webseitenorte, an denen sie geladen und ausgeführt werden können.
Bei einem gespeicherten XSS-Angriff speichert ein bösartiges Skript Benutzereingaben auf dem Zielserver. Im Gegensatz zu einem reflektierten XSS-Angriff, der auf dem Server ausgeführt wird, wird ein gespeicherter XSS-Angriff auf dem Browser des Benutzers ausgeführt. Angreifer verwenden dann moderne HTML5-Anwendungen, in der Regel HTML-Datenbanken, um schädliche Skripte dauerhaft im Browser zu speichern.
Bei einem gespeicherten XSS-Angriff wird das Skript jedes Mal gespeichert und auf dem Server ausgeführt, wenn der Benutzer auf die betroffene Website zugreift. Es ist für einen Angreifer einfach, eine große Anzahl von Opfern anzugreifen, und das Ergebnis ist hartnäckig. Gespeicherte XSS-Angriffe können auch auftreten, wenn ungeschulte Benutzer versuchen, Daten aus der Software zu extrahieren, ohne Desinfektions- oder Validierungsvorkehrungen zu treffen.
Gespeicherte XSS-Angriffe zielen darauf ab, einem Benutzer ein bösartiges Skript zu vermitteln. Der einfachste Weg, diese zu verhindern, besteht also darin, Benutzerdaten zu desinfizieren und Eingaben sorgfältig zu behandeln – und der beste Weg, sie zu verhindern, ist die Verwendung geeigneter Parameterbindung.
Sie können Daten mit einem Vorlagensystem mit automatischer Ausweichfunktion oder HTML-Codierung bereinigen. Sie sollten Daten codieren, die für die Ausgabe bestimmt sind, um zu verhindern, dass der Server sie als aktiven Inhalt interpretiert. Das bedeutet, dass die Anwendung Sonderzeichen in ihren gespeicherten Daten als HTML-Tag-Inhalt und nicht als einfache HTML verarbeitet.
Die Datenparameter (Daten)-Bindung variiert je nach Vektor, aber Sie können Variablen immer als zusätzliche Werte außerhalb der normalen Funktionalität der Funktion weitergeben. Sie können auch geeignete Antwort-Header verwenden, um Angriffe zu verhindern, in der Regel indem Sie nur ein paar Codezeilen hinzufügen.
Eine weitere Technik, um XSS-Angriffe in Echtzeit zu stoppen, ist die Verwendung dynamischer Sicherheit, die aktiv nach Exploitierungsversuchen sucht. Indem bekannte Muster blockiert werden, können Sie Angreifer davon abhalten, vorhandene Lücken auszunutzen.
Schließlich können Sie Web Application Firewalls (WAFs) für die Erkennung und Abmilderung von XSS-Angriffen in Echtzeit verwenden.
Die DOM-Schnittstelle ermöglicht die Verarbeitung und Manipulation von Webseiteninhalten durch Lesen und Ändern von HTML- und XML-Dokumenten. DOM-basierte XSS-Angriffe führen bösartige Änderungen am DOM-Kontext des Browsers des Opfers ein, wodurch der clientseitige Code unbeabsichtigt ausgeführt wird.
DOM-basierte XSS-Angriffe speichern, anders als reflektierte und gespeicherte XSS-Angriffe, das bösartige Skript nicht und liefern es nicht an den Server. Bei diesem Angriff ist der Browser des Opfers die einzige Schwachstelle. Da sie schwieriger zu verstehen sind als andere Kategorien, sind DOM-basierte Schwachstellen ungewöhnlich, ausgefeilt und schwierig zu überwinden. Darüber hinaus können automatisierte Schwachstellenscanner und Web Application Firewalls sie nicht leicht identifizieren.
Sie können die gleichen Techniken verwenden, um diesen Angriff zu verhindern wie die anderen beiden, aber Sie müssen besonders darauf achten, den clientseitigen Code zu desinfizieren. Zwei effektive Lösungen bestehen darin, zu verhindern, dass benutzergesteuerte Quellen potenziell gefährliche JavaScript-Funktionen (sogenannte „Senken“) ändern, oder nur vertrauenswürdige Inhalte mithilfe einer Safelist zuzulassen. Mit diesen Vorsichtsmaßnahmen werden Zeichenfolgen, die das DOM gefährden könnten, nicht an Senken gesendet. Sie können die Daten auch mithilfe der integrierten Browserfunktionalität bereinigen, wodurch das Risiko von Problemen im Zusammenhang mit Parser-Änderungen reduziert wird.
Eine neuartige Verteidigung gegen diese Art von Angriff ist die Verwendung vertrauenswürdiger Arten. Dies ist ein Browser-Sicherheitsmechanismus, der sicherstellt, dass alle riskanten Teile des DOM nur von Daten verwendet werden können, die eine vordefinierte Richtlinie bestanden haben. Es verhindert, dass beliebige Zeichenfolgen an potenziell gefährliche Senken weitergegeben werden, was dem Browser hilft, zwischen Code und Daten zu unterscheiden und die Hauptquelle der Schwachstellen zu entfernen.
XSS-Angriffe werden entweder als Server XSS oder Client XSS kategorisiert. Clientseitige Programme laufen auf dem Gerät oder Browser des Clients und kümmern sich um die Benutzeroberfläche und alle anderen Verarbeitungen, die auf dem Gerät des Clients stattfinden. Serverseitige Programme arbeiten auf Servern und erstellen den Inhalt einer Webseite.
Serverseitiges XSS tritt auf, wenn der gesamte serverseitige Code gefährdet ist und der Browser die Antwort rendert und alle darin eingebetteten legitimen Skripte ausführt. Andererseits wird clientseitig XSS auf dem Gerät des Benutzers ausgeführt und ändert eine Webseite, nachdem sie geladen wurde.
Ein XSS-Angriff ist überall dort möglich, wo HTML vorhanden ist. Unabhängig davon, ob sie gespeichert, reflektiert oder DOM-basiert sind, haben alle XSS-Angriffe die gleiche Wirkung: Ein Angreifer erhält die vollständige Kontrolle über eine Websitzung.
Diese XSS-Angriffe können sich ebenfalls überschneiden und eine Website kann für alle drei gleichzeitig anfällig sein. Im Falle einer einzelnen Website oder einer Offline-Anwendung können sich alle drei Angriffstypen direkt im Browser präsentieren. Deren Verhalten kann sich jedoch unterscheiden, wenn die Daten auf dem Server gespeichert werden, im Vergleich zu dem, wenn sie vom Server reflektiert werden.
Weiterführende Forschung