Ein Cross-Sites-Scripting-Angriff bringt einen Webbrowser dazu, Schadcode auszuführen.
Nach Lektüre dieses Artikels können Sie Folgendes:
Ähnliche Inhalte
Sicherheit von Webanwendungen?
Cross-Site-Request-Forgery
Brute-Force-Angriff
Pufferüberlaufangriff
Was ist SQL-Injection?
Abonnieren Sie theNET, Cloudflares monatliche Zusammenfassung der beliebtesten Einblicke in das Internet!
Link zum Artikel kopieren
Cross-Site Scripting (XSS) ist ein Exploit, bei dem der Angreifer an eine legitime Website Code anfügt, der ausgeführt wird, wenn das Opfer die Website lädt. Dieser Schadcode kann auf verschiedene Arten eingefügt werden. Am beliebtesten ist es, ihn entweder an das Ende einer URL anzuhängen oder direkt auf einer Seite zu posten, die benutzergenerierte Inhalte anzeigt. Technisch gesehen ist Cross-Site Scripting ein clientseitiger Code-Injection-Angriff.
Clientseitiger Code ist JavaScript-Code, der auf dem Computer eines Benutzers ausgeführt wird. In Bezug auf Websites ist clientseitiger Code normalerweise Code, der vom Webbrowser ausgeführt wird, nachdem der Browser eine Webseite geladen hat. Das steht im Gegensatz zum serverseitigen Code, der auf dem Webserver des Hosts ausgeführt wird. Clientseitiger Code ist bei interaktiven Webseiten sehr nützlich. Interaktive Inhalte werden schneller und zuverlässiger ausgeführt, da der Computer des Benutzers nicht bei jeder Interaktion mit dem Webserver kommunizieren muss. Browserbasierte Spiele sind eine beliebte Plattform für clientseitigen Code, da der clientseitige Code sicherstellen kann, dass das Spiel auch bei Verbindungsproblemen reibungslos funktioniert.
Clientseitig ausgeführter Code ist in der modernen Webentwicklung sehr verbreitet und wird auf den meisten modernen Websites verwendet. Da Cross-Site-Code ein Grundpfeiler des modernen Web ist, ist Cross-Site Scripting zu einer der am häufigsten berichteten Schwachstellen im Bereich der Cybersicherheit geworden. Cross-Site-Scripting-Angriffe haben schon große Websites wie YouTube, Facebook und Twitter getroffen.
Ein nützliches Beispiel für Cross-Site-Scripting-Angriffe ist häufig auf Websites mit nicht validierten Kommentarforen zu sehen. In diesem Fall veröffentlichen Angreifer einen Kommentar, der aus ausführbarem Code besteht, der in den Tags „<script> </script>“ eingeschlossen ist. Diese Tags weisen einen Webbrowser an, alles zwischen den Tags als JavaScript-Code zu interpretieren. Sobald sich dieser Kommentar auf der Seite befindet und andere Benutzer die Website laden, wird der Schadcode zwischen den Script-Tags vom Webbrowser ausgeführt und sie werden Opfer des Angriffs.
Cross-Site-Scripting-Angriffe auf JavaScript sind beliebt, da JavaScript Zugriff auf einige sensible Daten hat, die für Identitätsdiebstahl und andere böswillige Zwecke missbraucht werden können. Beispielsweise hat JavaScript Zugriff auf Cookies* und Angreifer können einen XSS-Angriff benutzen, um die Cookies eines Benutzers zu stehlen und sich online als dieser auszugeben. JavaScript kann auch HTTP-Anfragen erstellen, mit denen Daten (z. B. gestohlene Cookies) an den Angreifer zurückgesendet werden können. Darüber hinaus kann clientseitiges JavaScript Angreifern helfen, auf APIs zuzugreifen, die Geolokationskoordinaten, Webcam-Daten und andere sensible Informationen enthalten.
Ein typischer Cross-Site-Scripting-Angriff verläuft wie folgt:
*Cookies sind temporäre Anmeldeinformationen, die auf dem Computer des Benutzers gespeichert werden. Wenn sich ein Benutzer beispielsweise auf einer Website wie Facebook anmeldet, gibt ihm die Website ein Cookie. Schließt er dann das Browserfenster und kehrt später an diesem Tag zu Facebook zurück, authentifiziert das Cookie ihn automatisch und er muss sich nicht erneut anmelden.
Die beiden verbreitetsten Arten von Cross-Site-Scripting-Angriffen sind reflektiertes Cross-Site Scripting und persistentes Cross-Site Scripting.
Das ist der am häufigsten gesehene Cross-Site-Scripting-Angriff. Beim reflektierten Angriff wird Schadcode an das Ende der URL einer Website angehängt. Oft handelt es sich um eine legitime, vertrauenswürdige Website. Wenn die Opfer diesen Link in ihren Webbrowser laden, führt der Browser den in die URL injizierten Code aus. Die Angreifer verwenden normalerweise eine Form von Social Engineering, um die Opfer dazu zu bringen, auf den Link zu klicken.
Beispielsweise erhalten Benutzer möglicherweise eine legitim aussehende E-Mail, die behauptet, von ihrer Bank zu stammen. In der E-Mail werden sie aufgefordert, auf der Website der Bank Aktionen auszuführen, und erhalten dafür den entsprechenden Link. Der Link sieht möglicherweise folgendermaßen aus:
http://legitamite-bank.com/index.php?user=here is some bad code!
Obwohl der erste Teil der URL sicher aussieht und die Domain einer vertrauenswürdigen Website enthält, kann der am Ende der URL eingefügte Code schädlich sein.
Das geschieht auf Websites, auf denen Benutzer Inhalte veröffentlichen können, die anderen Benutzern angezeigt werden, z. B. in einem Kommentarforum oder auf einer Social-Media-Website. Wenn die Site die Eingaben von benutzergeneriertem Inhalt nicht ausreichend prüft, können Angreifer Code einfügen, den die Browser anderer Benutzer beim Laden der Seite ausführen. Zum Beispiel könnten Angreifer auf eine Online-Dating-Site gehen und Folgendes in ihre Profile aufnehmen:
„Hallo! Mein Name ist Dave, ich genieße lange Strandspaziergänge und <script>hier der Schadcode</script>“
Alle Benutzer, die versuchen, auf Daves Profil zuzugreifen, werden Opfer von Daves persistentem Cross-Site-Scripting-Angriff.
Es gibt keine einheitliche Strategie zur Abwehr von Cross-Site Scripting und verschiedene Arten von Webanwendungen erfordern unterschiedliche Schutzstufen. Eine Reihe von Schutzmaßnahmen kann ergriffen werden, im Folgenden werden einige skizziert.
Nach Möglichkeit HTML in Eingaben vermeiden. Eine sehr effektive Möglichkeit, persistente Cross-Site-Scripting-Angriffe zu verhindern, besteht darin, nicht zuzulassen, dass Benutzer HTML in Formulareingaben veröffentlichen. Es gibt andere Optionen, mit denen Benutzer umfangreiche Inhalte ohne Verwendung von HTML erstellen können wie z. B. Markdown- und WYSIWYG-Editoren.
Eingaben validieren. Validierung bedeutet, Regeln zu implementieren, die verhindern, dass Benutzer Daten in Formularen posten, die bestimmte Kriterien nicht erfüllen. Beispielsweise sollte eine Eingabe, die nach dem „Nachnamen“ von Benutzern fragt, Validierungsregeln enthalten, nach denen die Benutzer nur Daten senden können, die aus alphanumerischen Zeichen bestehen. Es können auch Validierungsregeln festgelegt werden, die Tags oder Zeichen ablehnen, die üblicherweise beim Cross-Site Scripting verwendet werden wie „“-Tags.
Bereinigen von Daten. Das Bereinigen von Daten ähnelt der Validierung, erfolgt jedoch, nachdem die Daten bereits an den Webserver gesendet wurden, aber noch bevor sie anderen Benutzern angezeigt werden. Es gibt verschiedene Online-Tools, die HTML bereinigen und Schadcode-Injections herausfiltern.
Ergreifen von Cookie-Sicherheitsmaßnahmen. Webanwendungen können auch spezielle Regeln für dem Umgang mit Cookies festlegen, die den Diebstahl von Cookies durch Cross-Site-Scripting-Angriffe abwehren können. Cookies können an bestimmte IP-Adressen geknüpft werden, so dass Cross-Site-Scripting-Angreifer nicht auf sie zugreifen können. Darüber hinaus können Regeln erstellt werden, die verhindern, dass JavaScript überhaupt auf Cookies zugreift.
Festlegen von WAF-Regeln. Eine WAF kann so konfiguriert werden, dass sie Regeln in Kraft setzt, die reflektiertes Cross-Site Scripting verhindern. Diese WAF-Regeln nutzen Strategien, die ungewöhnliche Anfragen an den Server einschließlich standortübergreifender Cross-Site Scripting-Angriffe blockieren. Die WAF von Cloudflare bietet eine schlüsselfertige Installation und schützt Webanwendungen vor Cross-Site Scripting, DDoS-Angriffen, SQL-Injection und anderen häufigen Bedrohungen.