Cross-Site-Scripting (XSS): Wenn Ihre Website plötzlich Schadcode verbreitet

Beim Cross-Site-Scripting (XSS) kombinieren Kriminelle scheinbar harmlose Webseitenaufrufe mit gefährlichem Schadcode. Haben Sie schon geprüft, ob Ihr eigener Internetauftritt gegen derartige Attacken geschützt ist? Erfahren Sie hier, wie trickreich die Angreifer:innen beim Cross-Site-Scripting vorgehen und mit welchen Maßnahmen Sie Ihre Website wirksam schützen.

Während Sicherheitsexpert:innen regelmäßig vor neuen Viren, Trojanern und Ransomware warnen, gehört das Cross-Site-Scripting (XSS) zu den unterschätzten Cybergefahren. Dabei ist es bis heute eine sehr effiziente Hackingtechnik.

Weltweit sind nach Schätzungen mehrere Millionen Websites unzureichend gegen XSS gesichert. Bei vielen bekannten Anbietern und Plattformen im Internet wie Facebook, ebay, Amazon oder WhatsApp wurden schon XSS-Lücken in deren Internetauftritten gefunden. Besonders gravierende Sicherheitslücken schaffen es regelmäßig in die Berichte des Fachforums Open Worldwide Application Security Project (OWASP). Doch wie genau funktioniert XSS und warum schützen viele Unternehmen und Organisationen ihre Websites nicht ausreichend?

Was ist XSS (Cross-Site-Scripting)?

Die englische Bezeichnung „Cross-Site-Scripting“ beschreibt in Kurzform, worum es bei dieser Art von Cyberattacken geht, nämlich das Ausführen (gefährlicher) Programmskripte über eine eigentlich vertrauenswürdige Website.
Bei der Hackingtechnologie XSS versenden Kriminelle beispielsweise Spam-Mails mit Links auf eigentlich harmlose Internetseiten. Diese Links sind allerdings mit Schadcode angereichert,der Schwächen in den Sicherheitsmechanismen dieser Seiten ausnutzt – beispielsweise beim Aufbau scheinbar sicherer Datenverbindungen zwischen einem Onlineshop und dessen Kund:innen.
Klickt nun ein:e Kund:in des Onlineshops in einer Spam-Mail auf einen solchen infizierten Link, anstatt sich beim Onlineshop wie üblich über den eigenen Kundenaccount anzumelden, so können die Hacker:innen in diesem Moment die Verbindung („Session”) kapern und erhalten damit Zugriff auf das Kundenkonto.
Andere XSS-Programmskripte fordern die Empfänger:innen der Attacken sogar auf, sich mit ihren persönlichen Daten auf einer gefälschten Anmeldeseite anzumelden. Hierzu lassen die Hacker:innen den gefährlichen Link wie die Anmeldung bei einer bekannten Seite aussehen. Tatsächlich führt der Link aber auf eine andere Seite. Manchmal installieren die XSS-Schadskripte auf diesem Weg heimlich Überwachungssoftware oder Erpressungsprogramme (Ransomware) auf den Computern ihrer Opfer.
Die Hacker:innen nutzen hierbei die Vertrauensbeziehung zwischen Webseitenbetreiber und Kund:in aus. Die Kund:innen erkennen die Gefahren des Schadcodes nicht, weil dieser scheinbar von einem bekannten und vertrauenswürdigen Absender kommt. Das kann beispielsweise die Webseite einer Bank sein, ein bekannter und seriöser Webshop oder auch ein Social-Media- oder Branchenportal.
Abgekürzt wird Cross-Site-Scripting mit den Buchstaben XSS. Das X steht hierbei für das englische Wort „Cross“, da die Abkürzung „CSS“ im HTML-Umfeld bereits für eine Layoutsprache vergeben ist (Cascading Style-Sheets).
XSS gehört zur Familie der sogenannten Injection-Angriffe. Hierbei „injizieren“ Hacker:innen ihren Schadcode direkt dort, wo er unmittelbar seine schädliche Wirkung entfalten kann. Die SQL-Injection, die gezielt Datenbanken im SQL-Format angreift, ist ein anderes Beispiel für diese Hackingmethode.

Ziele von XSS-Attacken

Ein XSS-Angriff verfolgt fast immer eines oder mehrere dieser Ziele:
  •  fremde Benutzersitzungen übernehmen, beispielsweise eines Online-Einkaufs oder der Navigation auf einer besonders geschützten Webseite
  • fremdes Material in Webseiten einschleusen, um diese optisch zu entstellen (Website-Defacement) oder bestimmte Botschaften zu verbreiten
  • Phishing-Angriffe durchführen, um an fremde Log-in-Daten, Kreditkarteninformationen und Ähnliches zu gelangen
  • Kontrolle über fremde Browser oder Computer übernehmen
Besonders gefährdet und häufige Ziele von XSS-Attacken sind:
  • Banken und Kreditinstitute
  • Content-Management-Systeme (CMS)
  • Suchmaschinen – insbesondere solche Suchmaschinen, die in Firmen-Websites integriert sind
  • News-Skripte und -Anwendungen
  • Benutzeroberflächen für Hardware-Konfigurationen und Serveranwendungen, auch im IoT-Bereich
  • Behördliche Webseiten im In- und Ausland
  • Webseiten aus dem Bereich Verteidigung
  • Onlineshops und -marktplätze
  • Veraltete Webbrowser
  • Router, Firewalls und Gateways
  • UTM-Systeme (Unified-Threat-Management)

So funktionieren die Angriffe auf Webanwendungen

Beim Cross-Site-Scripting verwenden Hacker:innen häufig Skriptsprachen wie das sehr verbreitete JavaScript. Diese Sprache wurde einst als Erweiterung für das sehr simple Internet-Seitenformat HTML entwickelt. Mithilfe von JavaScript-Programmcode ist es beispielsweise möglich, personalisierte Webseiten für alle Besucher:innen einer Website zu erstellen.
Die persönliche Anmeldeseite für einen Webshop liegt jedoch in der Regel nicht „statisch“ auf dem Webserver des Anbieters. Sie wird erst zum Zeitpunkt des Webshop-Aufrufes „dynamisch“ im Browser erzeugt – komplett mit persönlicher Anrede, Auflistung der letzten Einkäufe und Anzeige des eigenen Warenkorbs.
Nahezu alle komplexen Interaktionen mit Webservern – von der Online-Navigation über das Homebanking bis hin zur Anmeldung auf einer Social-Media-Plattform – basieren heute auf solchen dynamischen Webseiten, die mittels Skriptsprachen wie JavaScript erstellt werden.
Hacker:innen missbrauchen beim XSS allerdings genau diese Skriptsprachen, um damit manipulierte Anmeldeseiten oder Webformulare zu erzeugen. Mit denen schöpfen sie dann beispielsweise Bankdaten von ahnungslosen Kund:innen ab, die diese Seiten aufrufen. Aber auch das Übertragen von Malware auf die Zielcomputer ist per XSS grundsätzlich möglich.
Auch mit anderen Sprachen wie php, VBScript, ActiveX und sogar mit CSS sind solche Attacken grundsätzlich möglich und auch dokumentiert. Meistens verwenden Cyberkriminelle jedoch JavaScript, da die Sprache weit verbreitet ist und ihre Sicherheitslücken auch in Hackerkreisen gut bekannt sind.

Die unterschiedlichen Arten von XSS

Es gibt verschiedene Arten von Cross-Site-Scripting-Angriffen. Sie unterscheiden sich nach:
  • Dauer, für die der Schadcode bereitliegt (dauerhaft/persistent versus fallweise/reflektiert)
  • programmiertechnischer Methode der Infiltrierung
  • Computer, auf dem der Schadcode vorliegt (lokal bei der jeweiligen Zielperson oder global auf einem Webserver)

Reflective (Reflected) XSS

Beim Reflective XSS (auch Reflected XSS genannt oder im Deutschen reflektierter XSS-Angriff) spielen Cyberkriminelle gefährlichen Schadcode „über Bande“ aus. Sie provozieren bei einem Webserver eine bestimmte Rückmeldung an einen anderen Computer. Diese Rückmeldung enthält versteckten Schadcode, der für den Zielcomputer gefährlich werden kann.
 Diese Art einer XSS-Attacke wird auch als nicht persistent bezeichnet, da sie auf einer einmaligen Serverrückmeldung („Reflektion“) aufbaut, aber die dahinter liegende Website selbst nicht dauerhaft manipuliert. In der Regel haben die Angreifer:innen bei dieser Hackingattacke gar keinen Zugriff auf den Webserver, können aber dessen Rückmeldungen gezielt ausnutzen, um Dritten zu schaden.
Reflektierte XSS-Angriffe arbeiten häufig mit URL-Parametern. URL-Parameter sind zusätzliche Informationen, die an den Aufruf einer Webseite angehängt werden können. Von der eigentlichen Webadresse werden solche URL-Parameter üblicherweise mit einem Fragezeichen oder einem Doppelkreuz („#“) getrennt.
Der Adressaufruf „https://www.google.de“ ohne weitere URL-Parameter öffnet beispielsweise die Seite www.google.de im Internet.
Zusammen mit der Adresse kann hier aber auch direkt ein URL-Parameter übergeben werden, etwa in dieser Form: „https://www.google.de/?q=Suchauftrag“
Der URL-Parameter „q“ für „query“ (Suchanfrage) wird direkt beim Aufruf vom Webserver gelesen und mitverarbeitet. In diesem Beispiel wird er vom Google-Server als Auftrag interpretiert, in das Suchfenster den auf das Gleichheitszeichen folgenden Suchbegriff einzutragen, hier also das Wort „Suchauftrag“. Damit entsteht eine individuell erzeugte Suchwebseite, die bereits vorausgefüllt ist.
Heutzutage können sehr viele Webserver derartige URL-Parameter verarbeiten. Auch das Kombinieren mehrerer Parameter ist auf vielen Webseiten möglich. Diese einzelnen Parameter werden dann jeweils per „&“ voneinander getrennt. In der Praxis können dadurch sehr umfangreiche Adressaufrufe entstehen, die manchmal länger sind als das eigentliche Adressfeld im Browser.
XSS-Attacke als Infografik mit Manipulation einer vertrauenswürdigen Webseite durch schädlichen Code
XSS-Attacken bedienen sich häufig harmloser Webseiten, die mit Schadcode manipuliert werden, sobald jemand sie aufruft.
Für die Kommunikation mit Webservern gibt es zwei verschiedene Methoden (Befehle). Sie heißen „HTTP GET“ und „HTTP POST“. Bei der Methode HTTP GET werden die URL-Parameter sichtbar als Klartext mit übertragen und können auch im Browser als Teil eines Lesezeichens gespeichert werden. Mit dieser Methode kann beispielsweise direkt auf ein Video auf einer Videoplattform verlinkt werden, dessen sogenannter „Embed Code“dann als URL-Parameter im Lesezeichen mit enthalten ist.
Im Unterschied hierzu überträgt der Befehl HTTP POST seine angehängten Daten immer verdeckt. HTTP POST wird gerne verwendet, um Dateien, etwa Bilder oder Programme, auf einen Webserver hochzuladen. Aber auch Formulardaten werden oft per HTTP POST übertragen. Die mit dieser Methode versendeten Informationen werden in der Regel nicht im Pufferspeicher (Cache) des Browsers abgelegt und auch in Lesezeichen nicht mitgespeichert. Sie sind, etwa im Fall von Formular- und Benutzerdaten, vertraulich.
Für Hacker:innen bieten beide Methoden HTTP GET und HTTP POST zahlreiche Wege, um damit gefälschte dynamische Webseiten zu erzeugen oder Schadcode an Dritte auszuspielen, sofern die als Übermittler genutzten Webseiten nicht entsprechend abgesichert sind.
Ein Beispiel: Hacker:innen senden eine E-Mail an ihre Opfer, die einen Link auf eine grundsätzlich vertrauenswürdige Website enthält. Was die Opfer nicht sehen: An diesen Link ist unsichtbar ein URL-Parameter angehängt, der wiederum ausführbaren Programmcode in JavaScript enthält.
Ein solcher JavaScript-Code im URL-Parameter könnte etwa wie folgt aussehen:
< script type =„text/javascript“ > alert („Sie sind Opfer einer XSS-Attackegeworden“); < /script >
Dieser Schadcode ist für das Mailprogramm des Opfers zunächst ungefährlich, da er beim Lesen der E-Mail nicht ausgeführt wird. Klickt es allerdings den Link auf die scheinbar vertrauenswürdige Seite an und der oben beschriebene JavaScript-Anteil wird dorthin übertragen, liefert der dortige Webserver genau diesen JavaScript-Code wieder als Teil einer dynamischen Website zurück („Reflektion“). Sobald diese Seite dann im Browser des Opfers dargestellt wird, führt der Browser den Code ohne weitere Prüfung aus, da er von einer vermeintlich „sicheren Webseite“ stammt.
Das oben gezeigte Code-Beispiel würde lediglich den Browser-Warnhinweis erzeugen, dass gerade eine XSS-Attacke erfolgt ist. Aber auf gleichem Weg können auch viel gefährlichere Skripte in den Browser geschleust werden. Diese gefährlichen Skripte könnten beispielsweise:
  • den Browser auf eine dem vertrauenswürdigen Original nachempfundene Seite umleiten, die Bankdaten oder Passwörter abfragt
  • unerkannt Viren oder Trojaner herunterladen
  • Sitzungsdaten für eine aktuell bestehende Verbindung beispielsweise zum Online-Banking auslesen, um diese Verbindung dann selbst zu übernehmen
Verfügen die betroffenen Nutzer:innen obendrein über lokale Administratorrechte auf ihren Arbeitsplatzcomputern, können Hacker:innen auch Einblicke in deren Systemumgebung erhalten. Im schlimmsten Fall könnten die Angreifer:innen ein System sogar komplett übernehmen oder auf ihm versteckte Systemdienste installieren, die dann unbemerkt im Hintergrund laufen (z.B. für das Bitcoin-Mining oder Spamversand).
Eine weitere Form der reflektierenden XSS-Attacke nutzt manipulierte Kontaktformulare und/oder sogenannte InlineFrames („iFrames“). InlineFrames sind Fenster in HTML-Seiten, in denen Inhalte von anderen Internetseiten angezeigt werden. Ein Beispiel für solche InlineFrames ist die Google-Maps-Karte, die als Wegbeschreibung zum Unternehmenssitz in die eigene Webseite eingebettet wird. Bereits ein Klick in ein manipuliertes iFrame kann jedoch ausreichen, um versteckten Schadcode auf den eigenen Computer zu laden.

DOM-based XSS und lokales XSS

Die Abkürzung DOM steht für „DocumentObjectModel“ und bezeichnet eine standardisierte Schnittstelle für den Datenzugriffdurch andere Programme und Dokumente auf Webseiten sowie auch für den Datenzugriff innerhalb von Webseiten. Das DOM-Prinzip ist insbesondere bei dynamisch erzeugten Angeboten von Bedeutung. Bei diesen stammen Inhalte häufig aus mehreren Quellen, die miteinander interagieren und in Beziehung stehen, aber für Anwender:innen wie eine einzige Webseite aussehen (sollen). Ein Beispiel hierfür ist die Kombination aus statischen Inhalten wie einer Navigationsleiste, eingeblendeter Werbung und persönlichen Daten aus dem Konto des:der Benutzer:in.
Diese Art der Intra-Webseiten-Kommunikation findet normalerweise nicht auf Serverseite statt, sondern direkt im Browser. Selbst bei einfachen Webseiten mit JavaScript-Anteilen können Hacker:innenim Bereich dieser Seiteninteraktion über den betreffenden URL-Parameter Schadcode ausführen. Perfide an dieser Art von Attacke ist, dass es nicht möglich ist, die Manipulation über den angezeigten Link in der Browser-Adresszeile zu erkennen.
Die meisten Browser fangen solche manipulierten Seiten(-anteile) inzwischen ab.Dennoch sind auch DOM-basierte XSS-Angriffe und lokale Skript-Attacken weiterhin von großer Bedeutung.

Persistent (Stored) XSS

Die sogenannten persistenten XSS-Attacken sind besonders dort verbreitet, wo Gästebücher, Foren oder andere interaktive Webseiten ganz oder weitgehend unmoderiert betrieben werden. Hier können Angreifer:innen ganz einfach Schadcode in Skriptform oder als Verweis auf bösartige URL veröffentlichen – beispielsweise anstelle normaler Kommentare und Beiträge oder zusätzlich zu diesen. Greifen nun andere Personen auf diese Beiträge oder Links zu und sind ihre Rechner nicht entsprechend geschützt, kann es sein, dass bei ihnen der hinterlegte Schadcode ausgeführt wird und ein persistenter Angriff erfolgreich ist.
Das Vorgehen ist ähnlich wie bei den Reflected-XSS-Attacken: Angreifer:innen platzieren anstelle von normalen Texteingaben Skriptcode in einem Eingabefeld und „hoffen“ zunächst darauf, dass dieser Eintrag nicht weggefiltert wird. Gleichzeitig basiert die Idee darauf, dass unsichere oder veraltete Browser den eingeschleusten Code nicht ignorieren, sondern ausführen. In diesem Fall wäre die XSS-Attacke nicht nur erfolgreich, sondern sogar dauerhaft wie eine Art Köder im Netz platziert.

Beispiele für XSS-Angriffe

Im Folgenden zeigen wir Ihnen einige Beispiele für XSS-Angriffe auf, die in der Vergangenheit für Aufmerksamkeit gesorgt haben. Auch wenn die genannten Sicherheitslücken inzwischen bekannt sind und somit weitgehend geschlossen wurden, ist es nur eine Frage der Zeit, bis Hacker:innen neue Angriffsvektoren identifiziert haben.
XSS-Beispiel 1: Das schwache Galerie-Skript: Ein relativ bekanntes Beispiel für XSS-Angriffe ist ein sogenanntes Galerie-Skript, das viele Webseiten-Betreiber:innen eine Zeit lang tausendfach heruntergeladen und zur Gestaltung ihrer Webseiteninhalte verwendet hatten. Zusätzlich zum nützlichen Aspekt der Bildergalerie wies das Skript eine Schwachstelle auf, über die mithilfe der untenstehenden Eingabe die aktuellen Sitzungs-Cookies der Anwender:innen ausgelesen werden konnten:
< script > alert(document.cookie) < /script >
Mithilfe derart ausgelesener Cookies war es möglich, Sitzungen zu übernehmen und beispielsweise Shop-Bestellungen an eine andere Adresse umzuleiten oder Zahlungsdaten auszuspähen.
XSS-Beispiel 2: Falsche Bewerber:innen: Ende 2023 stahl eine Gruppe von Unbekannten per XSS und SQL-Injection mehr als zwei Millionen E-Mail-Adressen und persönliche Daten von Stellenbewerber:innen auf insgesamt mehr als 65 Unternehmenswebsites. Betroffen waren Firmen in Südostasien, vor allem aus den Bereichen Personalvermittlung, Immobilien und Investment.
In einem Fall erstellten die Hacker:innen ein gefälschtes Bewerbungsprofil auf einer Bewerbungswebsite und befüllten es anschließend mit XSS-Skripten. In einem anderen Fall versteckten sie die Skripte in einem fingierten Lebenslauf.
XSS-Beispiel 3: Die fremde JavaScript-Schwachstelle: 2018 spähten Cyberkriminelle wertvolle Daten von Kund:innen der Fluggesellschaft British Airways aus. Hierbei wurde eine Sicherheitslücke in einer JavaScript-Bibliothek namens Feedify ausgenutzt. Kund:innen, die einen Flug buchen wollten, wurden auf eine Domain umgeleitet, die so ähnlich lautete wie die von British Airways, und bezahlten dort für ihre Flüge. Auf diese Art hatten Cyberkriminelle bereits etwa 380.000 Kreditkarten-Datensätze gestohlen, bevor der Betrug aufflog.

Darauf sollten Unternehmen besonders achten

Die Risiken durch XSS-basierte Angriffe sind ebenso vielfältig wie groß. Nicht nur das Beispiel der betrogenen British-Airways-Kund:innen dürfte viele Unternehmen veranlasst haben, bei ihren hauseigenen Sicherheitsmechanismen noch einmal genauer hinzusehen. Selbst vermeintlich harmlose Einzelfälle können sich schnell zu einer ausgewachsenen Sicherheitslücke entwickeln.
Das Problem: Oft sind XSS-Attacken nur der Anfang einer Serie von Angriffen. Haben sich die Angreifer:innen erst einmal Administrationsrechte auf der Unternehmenswebsite verschafft, können sie nach Belieben Kundendaten ausspähen oder weitere Schadprogramme direkt an die Kund:innen des Unternehmens versenden.
Der Ursprung der eigentlichen Attacke lässt sich im Nachhinein oft nur noch schwer identifizieren.Häufig sind die entsprechenden Log-Dateien des Webservers dann bereits gelöscht oder die Eindringlinge sind so geschickt vorgegangen, dass ihre Attacken im Log-File gar nicht erkennbar sind.
Zu den möglichen Schäden durch XSS-Angriffe in Unternehmen zählen:
  • Komplette oder teilweise Betriebsausfälle
  • Ausfall von Webseiten, einschließlich Shops, oder deren erhebliche Verlangsamung
  • Datendiebstähle jeglicher Art, sowohl in Form von Stammdaten als auch Zahlungsdaten
  • Einschleusung weiterer Schadsoftware in unzureichend geschützte Systeme
  • Imageverlust durch den Verlust persönlicher Daten von Mitarbeiter:innen und Kund:innen
  • Verurteilung zu einer Geldstrafe wegen Verstoß gegen die Datenschutzgrundverordnung (Weitergabe von persönlichen Daten)
  • Wettbewerbsnachteile, beispielsweise durch Industriespionage
Unternehmen sollten sich also bestmöglich gegen Cross-Site-Scripting schützen, da die Folgen einer solchen Attacke sehr schwerwiegend sein können.

Prävention: So verhindern Sie wirksam XSS-Angriffe

Aktuell nutzen fast alle größeren Webseiten die vielen Vorteile von JavaScript, HTML, XML und DOM. Schließlich erwarten Kund:innen bequem zu nutzende Online-Angebote und möchten sich dabei nicht ständig neu anmelden. Allzu aufwändige Log-in-Mechanismen mit Zwei-Faktor-Authentifizierung, starken Verschlüsselungen oder schnell ablaufenden Sitzungen sorgen für Frustration.
Entsprechend bestellen Kund:innen dann weniger im Firmen-Webshop, bewerten negativ oder beschweren sich. Was also tun, wenn Sie Cross-Site-Scripting und andere Cyberattacken wirksam verhindern wollen, ohne ihre Kund:innen dabei zu verärgern?

So bauen Sie serverseitigen Schutz gegen XSS-Attacken auf

Eines vorab: Ein hundertprozentiger Schutz gegen XSS-Attacken ist kaum möglich. Immer wieder ergeben sich neue Sicherheitslücken, die die Anbieter von Serversoftware, Firewalls und Co.dann möglichst schnell schließen müssen. Daher sollten Sie in Ihrem Unternehmen bei allen Beteiligten eine entsprechende Awareness für die Gefahren von XSS schaffen.
 Hierzu gehören:
  • Installieren Sie stets die neuesten Versionen der Betriebssysteme auf Ihren Servern.
  • Halten Sie diese durch automatische Updates auf dem neuesten Stand.
  • Noch besser: Nutzen Sie die Public- und Private-Cloud-Angebote etablierter Anbieter.
  • Fangen Sie jegliche Eingaben mit Sonderzeichen in Kontaktformularen, URLs und Co. ab und verbieten Sie diese auf Ihren Webseiten.
  • Lehnen Sie automatisierte Seitenaufrufe ab, die Skript-Marker wie „< script >“ enthalten.
  • Prüfen Sie grundsätzlich alle Inhalte von Drittanbietern, die Sie in Ihre eigene Website integrieren.
  • Kontrollieren Sie regelmäßig die Logfiles Ihrer Website und suchen Sie dort nach auffälligen Seitenaufrufen. Nutzen Sie entsprechende Sicherheitstools, die diese Arbeit automatisiert für Sie erledigen – Stichwort: SIEM/SOAR.
  • Führen Sie regelmäßig sogenannte Penetrationstests durch oder nutzen Sie Angebote aus dem Bereich des Ethical Hacking: Dabei untersuchen Expert:innen Ihre Website gezielt auf mögliche Schwachstellen – ohne jedoch Schäden zu verursachen.

So verhindern Sie clientseitig XSS-Angriffe

  • Sorgen Sie dafür, dass auch die Client-Rechner in Ihrem Unternehmen stets über die neuesten Updates verfügen – egal, ob Windows-, macOS- oder Linux-basiert.
  • Achten Sie darauf, dass Ihre Mitarbeiter:innen stets die neuesten Browser-Updates verwenden.
  • Verhindern Sie, dass Mitarbeiter:innen sich lokal mit Administratorrechten anmelden.
  • Prüfen Sie, ob Sie je nach Bedrohungslage auf Ihren Geräten weitere Sicherheitspakete installieren sollten – zusätzlich zum vorhandenen Viren- und Firewall-Schutz.
  • Lassen Sie keine Client-Computer längere Zeit unbeobachtet laufen. Diese sind zumindest im internen Netz mit ihrer IP-Adresse erreichbar und könnten durch Cybervorfälle auf internen Webservern ebenfalls kompromittiert werden.
  • Sorgen Sie für ein ordnungsgemäß abgeschottetes internes Netzwerk mit VPN-Einwahl und hängen Sie Ihr WLAN-Passwort nicht sichtbar im Büro auf.
  • Falls Mitarbeiter:innen eigene Geräte mitbringen dürfen (BYOD-Modell), achten Sie darauf, dass diese Geräte Ihren hauseigenen Sicherheitsrichtlinien entsprechen.
Sorgen Sie außerdem für eine offene Fehlerkultur in Ihrem Unternehmen. Mitarbeiter:innen sollten es straffrei melden können, wenn sie beispielsweise versehentlich einen kompromittierten Link angeklickt haben. Wird eine XSS-Attacke bekannt, geraten Sie nicht in Panik: Trennen Sie den betroffenen Computer umgehend vom Netz, fahren Sie ihn herunter und lassen Sie ihn durch ausgebildete IT-Forensiker:innen aus dem Cyber-Security-Umfeld untersuchen. Nur so erkennen Sie zeitnah das mögliche Ausmaß des Schadens und können schnellstmöglich Gegenmaßnahmen ergreifen.

Das Wichtigste zu Cross-Site-Scripting in Kürze

  • Beim Cross-Site-Scripting (XSS) versenden Hacker:innen Schadcode mithilfe vertrauenswürdiger Websites.
  • Viele aktuelle Webseiten sind unzureichend gegen den Missbrauch als Schadcode-Versender abgesichert.
  • Unternehmen sollten geeignete Maßnahmen ergreifen, um ihre Kund:innen und Mitarbeiter:innen sowie die eigenen Server vor XSS-Attacken zu schützen. Bei Verstößen drohen gravierende Folgen und hohe Geldstrafen.
  • Angriffe per XSS sind oft der Anfang einer Serie von Hackingattacken. Mithilfe gekaperter Webserver können Hacker:innen persönliche Daten stehlen oder Schadsoftware an Dritte versenden.
  • Eine offene Fehlerkultur im Unternehmen ist wichtig, um Cyberattacken schneller zu erkennen und abzuwehren.

Quelle:

https://www.vodafone.de/business/blog/cross-site-scripting-15873/