Cross-Site Scripting ist eine Schwachstelle in der Web-Sicherheit. Es wird oft mit XSS abgekürzt.
Bei anfälligen Websites und Anwendungen kann die Interaktion des Benutzers mit der Anwendung durch einen Bedrohungsakteur, allgemein als Angreifer bezeichnet, beeinträchtigt werden. XSS ist eine Technik, die Bedrohungsakteure einsetzen, um Kontrollen wie die Richtlinie zur gleichen Herkunft zu umgehen, auf die sich moderne Browser verlassen, um den Datenzugriff zwischen Anwendungen oder Websites zu beschränken.
Bei einem XSS-Angriff könnte sich ein Angreifer als ein Benutzer ausgeben, und damit dieselben Aktionen ausführen, die ein legitimer Benutzer vornehmen würde. Außerdem könnte der Angreifer so auf die privaten Daten des Benutzers zugreifen.
Wenn sich ein Angreifer Zugang zu einem Benutzer mit privilegiertem Zugriff auf eine Website oder Anwendung verschafft, kann er weiteren Schaden anrichten, indem er die Funktionsweise verändert und Daten stiehlt.
Bei einem XSS-Angriff schleust ein Angreifer ein bösartiges Skript ein, das vom Browser des Benutzers clientseitig ausgeführt wird und manchmal auch als Nutzlast bezeichnet wird.
Mit XSS kann ein Angreifer eine anfällige Website oder Anwendung zu einem Staging-Bereich machen, um bösartige Codes (oder Nutzdaten) in den Browser des Benutzers zu übertragen. Wenn der Benutzer die betroffene Website oder Anwendung besucht, wird ein Skript ausgeführt, das es dem Angreifer ermöglicht, diese Interaktion zu stören.
Es gibt drei Hauptkategorien von XXS-Angriffen: Reflected XSS, Stored XSS und DOM-based XSS.
Reflected XSS – Hier wird die Nutzlast von einer Webanwendung in den Browser des Benutzers „reflektiert“. Der Code wird in der Regel über einen Link in einer Phishing-E-Mail aktiviert oder über soziale Medien als private Nachricht verschickt. Der Link führt zu einer ungeschützten Website, auf der das Skript ausgeführt werden kann.
Stored XSS – Bei einem Stored XSS-Angriff wird die Nutzlast eines bösartigen Skripts in der Regel in der Webserver-Datenbank der betroffenen Website gespeichert und in eine Webanwendung injiziert, wenn ein Benutzer eine Seite vom Webserver lädt.
DOM-based XSS – Hier liegt das Problem im Code auf der Client-Seite (im Gegensatz zum Code auf der Server-Seite). Der Angriff wird ermöglicht, indem das Document Object Model (DOM) im Browser des Benutzers verändert wird, sodass das clientseitige Skript anders ausgeführt wird, als es sollte.
Ebenfalls erwähnenswert sind die Penetrationstester für Anwendungen, oder einfach Pen-Tester. Pen-Tester führen simulierte Cyberangriffe auf die Computersysteme oder Netzwerke eines Unternehmens durch. Dabei handelt es sich um legitime, autorisierte Tests, die Schwachstellen in der Cybersicherheit erkennen, um sie beheben zu können, bevor böswillige Angreifer sie finden und ausnutzen.
Ein erfolgreicher XSS-Angriff ermöglicht es einem Bedrohungsakteur in der Regel, sich als echter Benutzer auszugeben. Dies ist gefährlich, da es dem Angreifer im Falle eines hochrangigen Benutzers mit eingeschränktem Zugriff in der Lage wäre:
Alle Änderungen an der Anwendung oder der Website als dieser Benutzer vorzunehmen
Alle Daten, auf die der identifizierte Benutzer Zugriffsrechte hat, zu lesen
Logindaten und Passwort des Benutzers stehlen
Manipulation, Vandalismus oder Verunstaltung der Website oder App durchzuführen
Die Website oder Anwendung mit einem Trojaner infizieren
Ein XXS-Angriff besteht in der Regel aus zwei Schritten. Damit der erste Schritt erfolgen kann, muss die vom Angreifer als Angriffsziel identifizierte Website eine sein, die Benutzereingaben zulässt (z. B. ein Online-Nachrichtenbrett). Die vom Angreifer eingefügte bösartige Codefolge wird vom Browser des Opfers als legitimer Quellcode behandelt.
Der Angreifer findet einen Weg, die Nutzlast über eine vom Opfer besuchte Webseite in den Browser des betroffenen Benutzers zu injizieren.
Sobald die Nutzlast in die Webseite injiziert wurde, muss der Benutzer diese Seite besuchen. In Fällen, in denen der XSS-Angriff auf ein bestimmtes Opfer oder bestimmte Opfer abzielt, kann der Angreifer ein Phishing-Schema oder Social Engineering verwenden, um die bösartige URL zu übermitteln, die sie besuchen sollen. Diese Schemata spielen eine Schlüsselrolle bei Kontoübernahmebetrug (ATO, Account Takeover Fraud) und führen zu weiteren Problemen für die geschädigten Nutzer.
Zu den Websites oder Anwendungen, die besonders anfällig für XSS-Angriffe sind, gehören Messageboards, Diskussionsforen oder Websites, auf denen Benutzer Kommentare abgeben können. Diejenigen, die diese Seiten besitzen und betreiben, sollten besonders wachsam sein, was die Sicherheit angeht.
Jede Website oder Anwendung, die ungefilterte oder potenziell unbereinigte Benutzereingaben verwendet, um eine unsachgemäße Ausgabe zu erzeugen, könnte besonders anfällig für XSS-Angriffe sein.
XSS-Angriffe finden am häufigsten in JavaScript statt, da diese Sprache die Codegrundlage der meisten Webanwendungen bildet. Sie können aber auch über älteres Flash oder ActiveX sowie über VBScript und CSS durchgeführt werden.
Hier ist eine Liste von Vektoren, die ein XSS-Angreifer aus verschiedenen Gründen ausnutzen könnte. Dies ist keine erschöpfende Liste, sondern nur einige der häufigsten Ziele für das Einfügen von bösartigem Code.
JavaScript-Ereignisse
<script>-Tags
<embed>-Tags
<img>-Tags
<body>-Tags
<iframe>-Tags
<link>-Tags
<input>-Tags
<div>-Tags
<table>-Tags
<object>-Tags
Obwohl ein XSS-Angriff sehr gefährlich sein kann, gehören XSS-Schwachstellen zu den häufigsten in Webanwendungen. Für das Open Web Application Security Project (OWASP) stehen Injektionsangriffe, einschließlich XSS, auf Platz drei seiner Top Ten Web Application Security Risks.
Das Verhindern von XSS-Angriffen ist nicht einfach, aber durchaus möglich. Welche Vorbeugungstechniken Sie verwenden, hängt von Ihrem Programmiergerüst, der Art der Sicherheitslücke, die Sie betrifft, und der Art und Weise ab, wie Benutzereingaben über Ihre Anwendung verwendet werden. Es gibt jedoch einige grundlegende Schritte, die XSS-Angriffe universeller verhindern.
Sensibilisierung und Schulung der Mitarbeiter Stellen Sie sicher, dass alle Personen, die an der Erstellung und Wartung Ihrer Webanwendungen beteiligt sind, über die Gefahren von XSS-Schwachstellen informiert sind. Dazu gehören nicht nur Entwickler, sondern auch Systemadministratoren, DevOps und Qualitätssicherungspersonal. QA-Tests, auftragsunabhängige Pen-Tests und dynamische Anwendungstests sollten in Betracht gezogen werden. Häufige und gründliche Tests sind entscheidend.
Filterung aller Eingaben beim Empfang Vermeiden Sie nach Möglichkeit HTML-Eingaben. Jede Eingabe, die sich nicht vermeiden lässt, muss so gründlich wie möglich gereinigt werden. Man sollte den von einem Benutzer oder Browser empfangenen Daten nicht trauen, selbst wenn sie von einem authentifizierten Benutzer stammen. Gehen Sie davon aus, dass alle Daten öffentlich zugänglich sind und bösartige Codes enthalten können. Als Sicherheitsarchitekturmodell, das jeden einzelnen Benutzer und jedes Gerät verifiziert und authentifiziert, bevor er auf Anwendungen und andere Ressourcen zugreifen kann, ist ein Zero-Trust-Ansatz in der Lage, Ihre XSS-Anfälligkeit zu verringern. Stellen Sie sich vor, Sie bewegen sich weg von einem „vertraue, aber überprüfe“-Modell hin zu einem „vertraue nie, überprüfe immer“-Modell.
Encoding oder Escaping aller Daten in der Ausgabe Immer wenn Benutzereingaben Teil der HTML-Ausgabe sind, besteht ein erhöhtes XSS-Risiko. Sie können das Risiko verringern, indem Sie die Ausgabe so codieren, dass sie nicht als aktiver Inhalt verstanden werden kann. Je nach Kontext der Ausgabe kann dies eine kombinierte Codierung mit HTML, JavaScript, URL und CSS erfordern. Diese Technik wird auch als „Output Escaping“ bezeichnet.
Sicherstellung geeigneter Antwort-Header Durch die Verwendung von Content-Type- und X-Content-Type-Options-Headern können Sie verhindern, dass XSS in HTTP-Antworten eingeschleust wird, die kein JavaScript oder HTML enthalten sollten. Diese Header können den Browsern helfen, die von Ihnen beabsichtigte Antwort auszuführen.
Umsetzung der Content Security Policy Nachdem Sie alle oben genannten Maßnahmen ergriffen haben, können Sie die Content Security Policy (CSP) als letztes Sicherheitsnetz einsetzen. CSP ermöglicht es Website-Besitzern, die Herkunft von Inhalten, Skriptblöcken und Skriptdateien, die von Browsern auf ihre Website geladen werden dürfen, zu standardisieren und ausdrücklich zu deklarieren. Dies kann dazu beitragen, das Ausmaß der verbleibenden XSS-Schwachstellen zu verringern.
Da Sie nun wissen, wie gefährlich – und wie häufig – XSS ist, sollte klar sein, dass die Zugriffskontrolle allein nicht ausreicht, um XSS-Angriffe zu verhindern.
DevOps- und IT-Sicherheitsteams sollten einen umfassenden Ansatz zum Schutz vor allen API-Bedrohungen verfolgen.
Starten Sie jetzt
Erfahren Sie, wie Ping Sie dabei unterstützen kann, sichere Mitarbeiter- und Kundenerlebnisse in einer sich schnell entwickelnden digitalen Welt zu schaffen.
Kostenlose Demo anfordern