Was ist Cross-Site Scripting (XSS)?

Cross-Site-Scripting (XSS) ist eine Art von Sicherheitslücke, die typischerweise in Webanwendungen zu finden ist. XSS ermöglicht es Angreifern, clientseitige Skripte in Webseiten einzuschleusen, die von anderen Benutzern angezeigt werden, und kann verwendet werden, um die Zugriffskontrolle zu umgehen, z. B. die Richtlinie für denselben Ursprung.

Die Auswirkungen von XSS können von einem kleinen Ärgernis bis hin zu einem erheblichen Cybersicherheitsrisiko reichen, abhängig von der Sensibilität der Daten, die von der anfälligen Website verarbeitet werden, und der Art der implementierten Gegenmaßnahmen.

Anfällige Webanwendungen, die häufig für Cross-Site-Scripting-Angriffe verwendet werden, sind Foren, Message Boards und Webseiten, die Kommentare zulassen. Wenn Benutzereingaben nicht bereinigt werden, sind XSS-Angriffe in VBScript, ActiveX, Flash, JavaScript und CSS möglich.

Wie funktioniert ein XSS-Angriff?

Ein typischer XSS-Angriff besteht aus zwei Phasen:

1. Der Angreifer findet einen Weg, bösartigen Code in eine Webseite einzuschleusen, die das Opfer besucht
2. Das Opfer besucht die Webseite und der bösartige Code wird ausgeführt

Damit Schritt eins funktioniert, muss die anfällige Website direkt unbereinigte Benutzereingaben auf ihren Seiten enthalten. Der Angreifer fügt dann einen bösartigen Code in die Webseite ein, der vom Browser des Opfers als Quellcode behandelt wird.

Es gibt andere XSS-Angriffe, die darauf beruhen, den Benutzer mithilfe von Social Engineering dazu zu verleiten, die Nutzlast selbst auszuführen.

Warum ist XSS gefährlich?

Während XSS-Schwachstellen als weniger gefährlich angesehen werden können als beispielsweise SQL-Injection-Schwachstellen, können die Folgen von XSS-Angriffen, insbesondere von gespeicherten XSS-Angriffen, die auf JavaScript basieren, aus folgenden Gründen sehr gefährlich sein:

• JavaScript kann auf alle Objekte zugreifen, auf die eine Webseite Zugriff hat, dies kann die Cookies eines Benutzers mit document.cookie einschließen, die es Angreifern ermöglichen können, Zugriff auf Session-Cookies zu erhalten, wenn sie nicht ausreichend geschützt sind. Wenn ein Angreifer auf die Sitzung eines Benutzers zugreifen kann, kann er die Identität des Benutzers annehmen, Aktionen im Namen des Benutzers ausführen und Zugriff auf vertrauliche Daten erhalten.
• JavaScript kann die Domain des Browsers lesen und Änderungen daran vornehmen, wodurch die Verunstaltung von Websites und die Offenlegung sensibler Informationen ermöglicht werden.
• JavaScript kann das XMLHttpRequest-Objekt verwenden, um HTTP-Anfragen zu senden
• JavaScript in modernen Browsern kann HTML5-APIs verwenden, mit denen Zugriff auf die Geolokalisierung, die Webcam, das Mikrofon und sogar die Dateien des Benutzers auf seinem Computer erhalten werden kann. Während die meisten dieser APIs ein Opt-in erfordern, können Angreifer Social Engineering nutzen, um Opfer zur Genehmigung ihrer Anfragen zu zwingen.

Welche Arten von XSS-Angriffen gibt es?

Es gibt keine einheitliche, standardisierte Klassifizierung der Arten von Cross-Site-Scripting-Angriffen, aber die meisten Experten unterscheiden zwischen mindestens zwei Haupttypen: nicht-persistent und persistent. Andere Quellen unterteilen diese beiden Gruppen weiter in traditionelle (durch serverseitigen Code verursacht) und DOM-basierte (in clientseitigem Code).

Nicht persistente (reflektierte) XSS-Angriffe

Eine nicht persistente (oder reflektierte) Cross-Site-Scripting-Schwachstelle ist eine häufige Web-Schwachstelle.

In der Regel das Ergebnis von Daten, die von einem Webclient bereitgestellt werden, am häufigsten in HTTP-Abfrageparametern (z. B. einer Formularübermittlung), und sofort von serverseitigem Code verwendet werden, um eine Seite mit Ergebnissen zu analysieren und dem Endbenutzer anzuzeigen, ohne den Inhalt ordnungsgemäß zu bereinigen.

Als Referenz bezieht sich die Bereinigung auf den Prozess der Untersuchung eines HTML-Dokuments und das Erstellen eines neuen HTML-Dokuments, das nur die HTML-Tags beibehält, die als sicher gekennzeichnet sind.

Da HTML-Dokumente eine flache Struktur aufweisen, die Steueranweisungen, Formatierungen und Inhalte mischt, kann jede nicht validierte Benutzereingabe, die ohne ordnungsgemäße HTML-Codierung in der resultierenden Seite enthalten ist, zu einem Injektionsangriff führen.

Ein klassischer Angriffsvektor dieser Art von Cyberangriffen ist die Suchmaschine einer Website. Wenn man nach einem Wort sucht, wird das Wort in der Regel wortwörtlich auf der Ergebnisseite angezeigt, um anzuzeigen, wonach gesucht wurde.

Wenn die Antwort HTML-Steuerzeichen nicht maskiert oder ablehnt, tritt ein Cross-Site-Scripting-Fehler auf.

Diese Angriffe werden in der Regel über Phishing-E-Mails oder eine neutrale Website übermittelt. Die bösartige URL verweist auf eine vertrauenswürdige Website, enthält aber den reflektierten XSS-Angriff, und wenn die Website anfällig für reflektierte Angriffe ist, führt das Klicken auf den Link dazu, dass der Browser des Opfers das injizierte Skript ausführt.

Persistente (gespeicherte) XSS-Angriffe

Persistente (oder gespeicherte) XSS-Schwachstellen sind die schädlichere Variante von Cross-Site-Scripting.

Sie tritt auf, wenn die vom Angreifer bereitgestellten Daten vom Webserver gespeichert und dann dauerhaft auf normalen Seiten angezeigt werden, die im Laufe des regulären Surfens an andere Benutzer zurückgegeben werden.

Ein berühmtes Beispiel für diese Art von Angriff heißt Samy. Samy war ein Cross-Site-Scripting-Computerwurm, der sich über das soziale Netzwerk Myspace verbreitete.

Wenn ein Benutzer ein infiziertes Profil anzeigte, wurde die Payload repliziert und in sein eigenes Profil eingefügt, um die Verbreitung des Wurms fortzusetzen.

Innerhalb von 20 Stunden nach der Veröffentlichung am 4. Oktober 2005 hatten über eine Million Benutzer die Payload ausgeführt, was Samy zum sich am schnellsten verbreitenden Wurm aller Zeiten machte.

Der Wurm selbst war ziemlich harmlos, seine Nutzlast zeigte im Profil des Opfers "aber vor allem Samy ist mein Held" an und schickte seinem Schöpfer Samy Kamar eine Freundschaftsanfrage.

Dies ist ein harmloses Beispiel. Persistente XSS-Schwachstellen können im Vergleich zu reflektierten XSS-Schwachstellen ein erhebliches Cybersicherheitsrisiko darstellen, da das bösartige Skript, wie Samy veranschaulicht, automatisch gerendert wird, ohne dass die Opfer individuell angesprochen oder auf eine Website gelockt werden müssen.

Die Methode der Injektion kann sehr unterschiedlich sein, der Angreifer muss möglicherweise nicht einmal direkt mit der Webfunktionalität selbst interagieren, um eine Lücke auszunutzen. Alle Daten, die von der Webanwendung empfangen werden (per E-Mail, Systemprotokolle, IMs usw.), die von einem Angreifer kontrolliert werden können, könnten potenzielle Angriffsvektoren sein.

Selbst-XSS

Self-XSS ist ein Social-Engineering-Angriff, der verwendet wird, um die Kontrolle über das Webkonto eines Opfers zu erlangen.

Bei einem Self-XSS-Angriff wird das Opfer des Angriffs gezwungen, bösartigen Code in seinem eigenen Webbrowser auszuführen und ihn so dem Angreifer auszusetzen.

In der Vergangenheit fand ein sehr ähnlicher Angriff statt, bei dem Benutzer dazu verleitet wurden, bösartiges JavaScript in ihre Adressleiste einzufügen. Nachdem die Browserhersteller diese Schwachstelle behoben hatten, begannen die Angreifer, Self-XSS in seiner aktuellen Form zu verwenden.

Heute haben sowohl Mozilla Firefox als auch Google Chrome Sicherheitsvorkehrungen eingeführt, um Benutzer vor Self-XSS-Angriffen zu warnen.

Mutiertes XSS (mXSS)

Mutiertes XSS tritt auf, wenn der Angreifer etwas einfügt, das sicher erscheint, aber vom Browser des Benutzers beim Parsen des Markups neu geschrieben und geändert wird.

Diese Angriffe sind innerhalb der Anwendungslogik schwer zu erkennen oder zu bereinigen.

Der Unterschied zwischen serverseitigem und DOM-basiertem Cross-Site-Scripting

In der Vergangenheit wurden XSS-Schwachstellen in Anwendungen gefunden, die die gesamte Datenverarbeitung auf dem Server durchführten.

Dies bedeutete, dass alle Benutzereingaben an den Server gesendet und dann als Webseite an den Benutzer zurückgesendet wurden, was das Potenzial für anhaltende XSS-Angriffe eröffnete.

Die Forderung nach einer verbesserten Benutzererfahrung führte jedoch dazu, dass Entwickler den Großteil der Präsentationslogik (z. B. JavaScript-Code) auf die Client-Seite verlagerten und die Daten bei Bedarf mithilfe von AJAX vom Server abzogen.

Da der JavaScript-Code auch Eingaben verarbeitete und auf der Webseite renderte, öffnete er reflektierte XSS-Angriffe oder DOM-basiertes XSS. Wie wir oben erwähnt haben, berührt dieser bösartige Inhalt nicht den Webserver, sondern wird vom JavaScript-Code ausschließlich auf der Client-Seite widergespiegelt.

So verhindern Sie XSS-Angriffe

Die Abwehr von XSS-Angriffen ist eine Schlüsselkomponente der Sicherheit von Webanwendungen und eine der OWASP Top Ten.

Allerdings gibt es keine einheitliche Strategie zur Eindämmung von Cross-Site-Scripting, und verschiedene Webanwendungen erfordern unterschiedliche Schutzstufen. Es kann eine Reihe von Schutzmaßnahmen ergriffen werden, darunter:

• Verwendung moderner Frameworks, die XSS von Haus aus entkommen, wie z. B. Ruby on Rails oder React
• Erlernen der Einschränkungen des XSS-Schutzes eines Frameworks und Angemessener Umgang mit den Ausnahmen
• Escapen von nicht vertrauenswürdigen HTTP-Anforderungen
• Validierung, Filterung oder Bereinigung von nutzergenerierten Inhalten
• Verwenden einer Content Security Policy (CSP) als Tiefenverteidigungskontrolle
• Vermeiden von HTML-Eingaben, verwenden Sie andere Optionen
• Ergreifen von Cookie-Sicherheitsmaßnahmen
• Festlegen von WAF-Regeln zum Blockieren seltsamer Anfragen an den Server

Lesen Sie unseren vollständigen Leitfaden zu den OWASP Top Ten für weitere Informationen.

UpGuard Vendor Risk kann den Zeitaufwand Ihres Unternehmens für die Bewertung der damit verbundenen Informationssicherheitskontrollen und der Informationssicherheitskontrollen von Drittanbietern minimieren, indem es Lieferantenfragebögen automatisiert und Vorlagen für Lieferantenfragebögen bereitstellt.

Wir können Ihnen helfen, die externen Sicherheitskontrollen Ihrer Anbieter kontinuierlich zu überwachen und eine unvoreingenommene Sicherheitsbewertung zu erstellen.

Wir stützen unsere Bewertungen auf die Analyse von 70+ Vektoren, darunter:

• Anfälligkeit für Man-in-the-Middle-Angriffe
• Unsichere SSL/TLS-Zertifikate
• SPF-, DKIM- und DMARC-Einstellungen
• HTTP Streng Transport Sicherheit (HSTS)
• E-Mail-Spoofing und Phishing-Risiko
• Schwachstellen
• Anfälligkeit für Malware
• Unnötige offene Administrations-, Datenbank-, App-, E-Mail- und Filesharing-Ports
• Gefährdung durch bekannte Datenschutzverletzungen und Datenlecks
• Anfällige Software
• HTTP-Zugänglichkeit
• Sichere Cookie-Konfiguration
• Ergebnisse intelligenter Sicherheitsfragebögen

Wir können Ihnen auch dabei helfen, Ihre aktuellen und potenziellen Anbieter sofort mit ihrer Branche zu vergleichen, damit Sie sehen können, wie sie abschneiden.

Für die Bewertung Ihrer Informationssicherheitskontrollen kann UpGuard BreachSight Ihr Unternehmen auf 70+ Sicherheitskontrollen überwachen, eine einfache, leicht verständliche Cybersicherheitsbewertung bieten und automatisch kompromittierte Anmeldeinformationen und Datenoffenlegungen in S3-Buckets, Rsync-Servern, GitHub-Repos und mehr erkennen.

Der Hauptunterschied zwischen UpGuard und anderen Anbietern von Sicherheitsbewertungen besteht darin, dass es sehr öffentliche Beweise für unsere Expertise bei der Verhinderung von Datenschutzverletzungen und Datenlecks gibt.

Unsere Expertise wurde unter anderem in der New York Times, dem Wall Street Journal, Bloomberg, der Washington Post, Forbes, Reuters und TechCrunch veröffentlicht.

Lesen Sie mehr darüber, was unsere Kunden in den Gartner-Bewertungen sagen.