Cross-Site Scripting (XSS) ist ein Cyberangriff, bei dem ein Hacker schädlichen Code in ein Webformular oder eine URL einer Webanwendung einfügt. Dieser bösartige Code, der in einer Skriptsprache wie JavaScript oder PHP geschrieben ist, kann alles tun, von der Zerstörung der Seite, die Sie zu laden versuchen, bis hin zum Diebstahl Ihrer Passwörter oder anderer Anmeldedaten.

XSS nutzt einen wichtigen Aspekt des modernen Internets, nämlich die Tatsache, dass die meisten Webseiten erstellt werden, während Seiten geladen werden, manchmal durch Ausführen von Code im Browser selbst. Dies kann es schwierig machen, solche Angriffe zu verhindern.

Überprüfen Sie auch:

Wie funktioniert ein XSS-Angriff?

Jeder kann eine Website erstellen, die schädlichen Code enthält. Bei einem Cross-Site-Scripting-Angriff richtet der Angreifer alles so ein, dass sein Code den Rechner des Opfers erreicht, wenn dieses eine fremde Website besucht. Daher kommt das „Kreuz“ im Namen. XSS-Angriffe erreichen dies, ohne privilegierten Zugriff auf einen Webserver zu benötigen, um heimlich Code einzufügen. Stattdessen nutzen Angreifer die Funktionsweise moderner Websites aus.

Wenn Sie jemand um eine einfache und grundlegende Erklärung der Funktionsweise des Webs bitten würde, könnten Sie ihm wahrscheinlich so etwas sagen: Die Person, die eine Webseite erstellen möchte, schreibt ein HTML-Dokument und legt es auf einem Webserver ab; Wenn der Benutzer auf diese Seite zugreifen möchte, leitet er seinen Browser an die Serveradresse, der Browser lädt den HTML-Code herunter und interpretiert ihn und erstellt eine Kopie der Webseite des Benutzers.

Diese Beschreibung ist nicht falsch, aber einige Aspekte sind veraltet (und schon seit über zehn Jahren). Erstens sind viele, wenn nicht alle Webseiten heute dynamisch – das heißt, sie zeigen nicht jedem Besucher denselben statischen HTML-Code an, sondern werden sofort aus Informationen in der Datenbank des Servers generiert, wenn der Browser den Zugriff anfordert. Die Seite, die der Browser vom Server empfängt, hängt oft von den mit der Anfrage gesendeten Informationen ab – Informationen, die manchmal die Form von Parametern in der URL annehmen, die für den Zugriff auf die Site verwendet wird. Websites bestehen nicht nur aus HTML und Cascading Style Sheets (CSS), die beschreiben, wie Text und Grafiken angezeigt werden, sondern enthalten auch ausführbaren Code, der in Skriptsprachen, normalerweise JavaScript, geschrieben ist.

Bei einem XSS-Angriff nutzt der Hacker diese Interaktion zwischen dem Benutzer und der Website, um Schadcode auf dem Computer des Benutzers auszuführen. aber wie? Betrachten Sie die folgende URL:

https://www.google.com/search?q=CSO+online

Geben Sie diese in die Adressleiste Ihres Browsers ein und Sie sehen die Google-Suchergebnisse für „CSO Online“. Tatsächlich sieht die angezeigte Seite genau so aus, als hätten Sie „CSO Online“ in die Suchleiste Ihres Browsers oder auf der Google-Startseite eingegeben. Sie werden unter anderem feststellen, dass dieser Satz an mehreren Stellen auf der Seite erscheint, einschließlich der Suchleiste in den Bergen:

Was wäre, wenn diese URL anstelle des harmlosen und erfolgreichen Ausdrucks „CSO online“ bösartigen JavaScript-Code wie diesen enthalten würde?

https://www.google.com/search?<script>doEvil()</script>

doEvil() macht hier einen wirklich schlechten Job. Sie könnten besorgt sein, dass Google, anstatt „CSO Online“ auf der Seite anzuzeigen, die Sie von dieser URL zurücksenden, stattdessen das fehlerhafte Javascript dynamisch in die Seite integriert, die Sie rendern, und dass dieses Skript in Ihrem Browser ausgeführt wird , verursacht ein Durcheinander . Ihre Bedenken sind unbegründet, denn Google hat sehr viele talentierte IT-Sicherheitsexperten unter seinen Mitarbeitern und hat Abhilfemaßnahmen implementiert, auf die wir später noch zu sprechen kommen. Allerdings ist nicht jede Seite sehr vorsichtig und das gibt Ihnen eine Vorstellung davon, wie solche Angriffe funktionieren.

Ataki XSS

XSS-Angriffe fallen in mehrere Kategorien: reflektierte Angriffe, DOM-basierte Angriffe und gespeicherte Angriffe. So unterscheiden sie sich:

• Reflexangriffe: Auch als schwache Angriffe bekannt, wird bösartiger JavaScript-Code vom Browser des Opfers an Google gesendet, dann in ausführbarer Form zurückgespiegelt und nie auf den Servern von Google gespeichert. Diese Angriffe sind oft Teil eines Phishing-Betrugs, bei dem der bösartige Link als etwas Amüsanteres getarnt und per E-Mail oder SMS an das Opfer gesendet wird.
• DOM-basierte Angriffe: Dies ist eine Art von Reflexangriff namens Document Object Model, eine Standard-API, die definiert, wie Browser eine Webseite aus grundlegendem HTML- oder JavaScript-Code erstellen. Die meisten DOM-Angriffe ähneln dem zuvor beschriebenen Reflex-Angriff, mit dem Unterschied, dass bösartiger Code niemals an den Server gesendet wird, sondern als Parameter an eine JavaScript-Funktion übergeben wird, die im Browser selbst ausgeführt wird, was bedeutet, dass die Mechanismen schützen auf der Serverseite können den Benutzer nicht schützen. Wenn Sie an den Details interessiert sind, bietet PortSwigger eine detailliertere Beschreibung der Funktionsweise von DOM-Angriffen.
• Gespeicherte Attacken: ansonsten hartnäckig; Der Angreifer nutzt die interaktiven Funktionen der Website, um Schadcode auf dem Webserver zu hinterlegen. In einem typischen Beispiel hinterlässt der Angreifer einen Kommentar zu einem Blogbeitrag, der schädliches JavaScript enthält. Wenn jemand diese Seite das nächste Mal lädt, wird der Code ausgeführt.
• Anfälligkeit für XSS-Angriffe

Was macht eine Website anfällig für einen XSS-Angriff? Hoffentlich hat unsere bisherige Diskussion einige Hinweise gegeben. Wenn Ihre Webanwendung naiv Benutzereingaben akzeptiert, sie nicht auf bösartigen ausführbaren Code überprüft und diese Daten verwendet, um eine Seite zu rendern oder andere Vorgänge auszuführen, ist sie für diese Art von Angriffen anfällig.

Und die Risiken sind groß. Der Hauptaspekt der Browsersicherheit ist die sogenannte Same-Origin-Policy, die besagt, dass ein auf einer Seite ausgeführtes Skript nur dann auf Daten auf der anderen Seite zugreifen kann, wenn beide Seiten denselben Ursprung haben (definiert als Kombination aus URI, Hostname, und Rufnummernport). Wenn jedoch schädliches JavaScript im Browser ausgeführt werden kann, während das Opfer auf die Website zugreift, erlaubt der Browser dem JavaScript, auf Daten von anderen Websites zuzugreifen, die eine Ressource mit der anfälligen Website teilen. JavaScript kann auf Cookies und andere proprietäre Sitzungsinformationen zugreifen, was ein gutes Rezept für das Hacken der Internetkonten von Opfern darstellt.

Nutzdaten XSS

Im Sprachgebrauch von Malware ist eine Payload ein ausführbarer Code, der vom Angreifer geforderte Aktionen ausführt. Im Falle eines XSS-Angriffs ist die Nutzlast ein Skriptcode, den der Angreifer ausführt, um den Browser des Opfers dazu zu bringen, ausgeführt zu werden.

Es gibt eine riesige Liste von XSS-Payload-Vorlagen im Payloadbox-Repository auf GitHub. Wenn Sie sich mit JavaScript auskennen, können Sie sich beim Lesen vielleicht ein Bild davon machen, wie XSS-Angreifer ihre Drecksarbeit verrichten. Ein XSS-Angriff geht jedoch über das Ausschneiden und Einfügen der Nutzdaten in die URL hinaus: Der Angreifer muss die spezifischen Funktionen und Schwachstellen der Webanwendung verstehen, die er ausnutzen möchte, um den Angriff zu planen. Wenn Sie tiefer graben und einige Beispiele für XSS-Angriffe sehen möchten, besuchen Sie die OWASP XSS-Website für einen detaillierten Blick auf den Skriptcode, der einen XSS-Angriff demonstriert.

XSS-Schutz und -Prävention

Wenn Sie eine Webanwendung oder eine interaktive Website erstellen oder verwalten, sollten Sie bei Ihrem Design drei Haupttechniken berücksichtigen, um potenzielle Cross-Site-Scripting-Angriffe zu vermeiden.

• Sterilisierung von Eingabedaten. Die offensichtliche Antwort, um zu verhindern, dass bösartiger Code als Eingabe weitergegeben und an den Benutzer zurückgegeben wird, besteht darin, Skriptcode einfach nicht als Eingabe zu akzeptieren. Sie sollten Ihre Eingaben auf jeden Fall in diesem Sinne filtern, aber das ist leichter gesagt als getan; Kleine Teile ausführbaren Codes können durch Filter schlüpfen. Eine Möglichkeit, mit diesem Problem umzugehen, besteht darin, einen Whitelist-Ansatz anstelle eines Blacklist-Ansatzes zu verwenden. Anstatt beispielsweise zu versuchen, einen Filter zu schreiben, der den gesamten schädlichen Code blockiert, der in ein Webformular eingespeist wird, müssen Sie Ihre Anwendung so schreiben, dass sie dies akzeptiert Daten zu bestimmten Zeiten Formate (Telefonnummern, E-Mail-Adressen usw.) nur dann, wenn Sie dies wünschen.
• Flucht aus der Ausgabe. Dies ist andererseits die Lösung des Problems. Wenn eine Webanwendung Benutzereingaben an eine Webseite zurücksendet, müssen diese Daten gefiltert werden, um sicherzustellen, dass sie auf dieser Seite nicht ausführbar werden. Wenn der Benutzer HTML-Tags als Eingabe eingibt, muss die Anwendung überschriebene Zeichen verwenden, damit diese Tags als Text auf der Ergebnisseite angezeigt werden und nicht in den HTML-Code der Seite selbst integriert werden.
• Standard-Inhaltssicherheitsrichtlinie (CSP). CSP führt den „Whitelisting“-Ansatz außerhalb der Texteingabe in den Bereich des Skriptings: Eine Webanwendung sollte nur Code ausführen, den der Benutzer als sicher angegeben hat. Google hat einige großartige Ressourcen zur Implementierung von CSP.

XSS-Test

Schwachstellentests für XSS-Angriffe sind ein wichtiger Aspekt, um die Sicherheit einer Webanwendung zu gewährleisten. OWASP verfügt über Ressourcen, die detailliert beschreiben, wie Anwendungen getestet werden können, um DOM-Angriffe oder Reverse-Cross-Site-Scripting zu vermeiden. Wenn Sie nach einem XSS-Blatt suchen, hat OWASP auch ein Dokument mit XSS-Angriffscode für Sie, mit dem Sie einige XSS-Verteidigungsfilter umgehen können. Es wird sich bei den Penetrationstests, die Sie auf Ihren eigenen Systemen durchführen können, als unschätzbar erweisen.

XSS und CSRF

Sie werden vielleicht hören, dass CSRF im selben Kontext wie XSS verwendet wird. Es ist die Abkürzung für Cross-Site Request Forgery, ein Angriff – wie XSS – der auf den Browser eines Benutzers abzielt. Der Hauptunterschied besteht darin, dass CSRF eine authentifizierte Sitzung für den Benutzer verwendet (möglicherweise ist er bei seinem Bankkonto angemeldet), während XSS keine authentifizierte Sitzung benötigt, um effektiv zu sein.

Angenommen, ein Benutzer ist gleichzeitig bei Twitter und einer Internetbank angemeldet und klickt auf einen Twitter-Link, der so aussieht:

http://www.yourbank.com/sendmoney,do?from=you&to=attacker&amount=5000

Je nachdem, wie Ihre Bank Session-Token verwaltet und welchen Browser Sie verwenden, können diese plötzlich viel schlechter werden. XSS ist ein gefährlicherer Angriffsvektor, aber es ist wichtig, sich sowohl gegen XSS als auch gegen CSRF zu verteidigen. OWASP hat ein Informationsblatt zu Schutzmaßnahmen gegen CSRF erstellt.

Aktuelle und berüchtigte XSS-Angriffe

Einer der ältesten und bekanntesten Cross-Site-Scripting-Angriffe ereignete sich im Jahr 2005, als der unternehmungslustige MySpace-Benutzer Sammy Kamkar erkannte, dass er JavaScript-Code in sein Profil eingeben konnte, der jeden Besucher der Website automatisch authentifizierte – und diesen Code auch in die Profile von kopierte Ihr neue Freunde, Dank dessen wird jeder, der diese Seiten besucht, auch sein Freund sein. (Das Drehbuch sorgte dafür, dass jeder von Kamkars neuen Freunden es in die „Top Acht“ schaffte – wir haben Angst, das zu verstehen, Sie müssten dort sein, aber glauben Sie uns, es war wichtig.) Innerhalb von 24 Stunden gewann er über eine Million Freunde und zwang MySpace, die gesamte Seite für kurze Zeit abzuschalten.

Es stellt sich heraus, dass der sogenannte Sami-Wurm größtenteils harmlos ist. Andere waren jedoch ärgerlicher:

• Ebay hatte jahrelang XSS-Schwachstellen, die es Hackern ermöglichten, Anmeldedaten von Benutzern zu stehlen

• XSS-Angreifer konnten 2019 V-Bucks von Fortnite-Spielern stehlen.

• Die Hacking-Gruppe Magecart griff British Airways 2018 mit einem XSS-Angriff an und stahl Hunderttausende von Benutzeridentitäten

Und Cross-Site-Scripting bleibt auch heute noch eine ernsthafte Bedrohung. Seit 2021 wurden XSS-Schwachstellen in der E-Mail-Plattform Zimbra, Wordpress und der Open-Source-IT-Verwaltungsplattform Nagios gefunden. Denken Sie daran, dass Hacker Angriffstechniken normalerweise nicht isoliert verwenden: Cross-Site-Scripting ist eine Komponente einer kürzlich entdeckten komplexen Form des TLS-Wildcard-Angriffs, der als ALPACA bekannt ist. Stellen Sie sicher, dass Sie die XSS-Schwachstellen schließen, um gefährliche Bedrohungen zu vermeiden.

Quelle: CSO