Cross Site Scripting (Reflected)

Cross Site Scripting

Copyright © Shutterstock/ Artur Szczybylo

Was ist Cross Site Scripting (Reflected)?

Definition

Beim Cross Site Scripting (Reflected) handelt es sich um ein bekanntes Sicherheitsrisiko, das regelmäßig in der OWASP Top 10 gelistet ist. In dieser Liste werden von der Organisation Open Web Application Security Project (kurz: OWASP) typische Anfälligkeiten veröffentlicht, mit dem Ziel die Sicherheit zu verbessern.

Beschreibung

Bei reflectierten Cross Site Scripting Angriffen neutralisiert die Software die vom Benutzer kontrollierbaren Eingaben nicht oder falsch, bevor sie in eine Ausgabe eingefügt werden, die als Webseite für andere Benutzer verwendet wird.

XSS-Schwachstellen (Cross Site Scripting) treten auf, wenn:

  1. Nicht vertrauenswürdige Daten werden normalerweise aus einer Webanforderung in eine Webanwendung eingegeben.
  2. Die Webanwendung generiert dynamisch eine Webseite, die diese nicht vertrauenswürdigen Daten enthält.
  3. Während der Seitengenerierung verhindert die Anwendung nicht, dass die Daten Inhalte enthalten, die von einem Webbrowser ausgeführt werden können, z.B. JavaScript, HTML-Tags, HTML-Attribute, Mausereignisse, Flash, ActiveX usw.
  4. Ein Opfer besucht die generierte Webseite über einen Webbrowser, der schädliche Skripts enthält, die mit den nicht vertrauenswürdigen Daten eingefügt wurden.
  5. Da das Skript von einer Webseite stammt, die vom Webserver gesendet wurde, führt der Webbrowser des Opfers das schädliche Skript im Kontext der Domäne des Webservers aus.
  6. Dies verstößt effektiv gegen die Absicht der Web-Browser-Richtlinie “Same Origin“, die besagt, dass Skripts in einer Domäne nicht auf Ressourcen zugreifen oder Code in einer anderen Domäne ausführen dürfen.

Auswirkung

Sobald das schädliche Skript injiziert ist, kann der Angreifer verschiedene schädliche Aktivitäten ausführen. Der Angreifer kann private Informationen, wie z.B. Cookies, die Sitzungsinformationen enthalten, vom Computer des Opfers an den Angreifer übertragen. Der Angreifer kann im Namen des Opfers böswillige Anfragen an eine Website senden. Dies kann besonders gefährlich für die Website sein, wenn das Opfer über Administratorrechte zur Verwaltung dieser Website verfügt.

Phishing-Angriffe können verwendet werden, um vertrauenswürdige Websites zu emulieren und das Opfer dazu zu bewegen, ein Kennwort einzugeben, wodurch der Angreifer das Konto des Opfers auf dieser Website gefährden kann. Schließlich könnte das Skript eine Sicherheitsanfälligkeit im Webbrowser ausnutzen, die möglicherweise den Computer des Opfers übernimmt, der manchmal als “Drive-by-Hacking” bezeichnet wird.

Tipp

Überprüfen Sie die Sicherheit Ihrer Website mit unserem kostenlosen Security Crawler oder mit der OSG Performance Suite Free Version.

Lösung

Cross Site Scripting Scanner beginnen mit dem Versenden eines ‘sicheren’ Werts und der Analyse aller Positionen, an denen dieser Wert in der Antwort vorkommt (sofern vorhanden). Anschließend werden eine Reihe von Angriffen gestartet, die speziell auf die Stellen abzielen, an denen die einzelnen Instanzen auftreten; dazu gehören Tag-Attribute, URL-Attribute, SRC-Attribut unterstützte Tags, HTML-Kommentare usw.

  • Hinweis: es werden nur HTTP-PUT-Anforderungen bei LOW-Threshold gescannt. Wenn sich eine XSS-Injection in einer JSON-Antwort befindet, wird ein LOW-Risiko und ein LOW-Vertrauensalarm ausgelöst.

Es ist sicherzustellen, das der Kontext, in dem die Daten verwendet werden, und die zu erwartende Kodierung verständlich sind. Dies ist besonders wichtig, wenn Daten zwischen verschiedenen Komponenten übertragen werden oder wenn Ausgaben generiert werden, die mehrere Kodierungen gleichzeitig enthalten können, z. B. Webseiten oder mehrteilige E-Mail-Nachrichten. Es sollten alle erwarteten Kommunikationsprotokolle und Datendarstellungen untersucht werden, um die erforderlichen Kodierungsstrategien zu bestimmen.

Alle Daten, die auf einer anderen Webseite ausgegeben werden, insbesondere für Daten, die von externen Eingaben empfangen wurden, ist die entsprechende Kodierung für alle nicht-alphanumerischen Zeichen zu verwenden.

Für Teile des gleichen Ausgabedokuments sind möglicherweise andere Kodierungen erforderlich, die davon abhängen, ob die Ausgabe in folgendem Format vorliegt:

  • HTML-Text
  • Elementattribute (z. B. src = “XYZ”)
  • URIs
  • JavaScript-Abschnitte
  • Cascading Style Sheets und Style-Eigenschaft
  • etc.

Zu beachten ist, dass die HTML-Entity-Codierung nur für den HTML-Body geeignet ist.

Zusätzliche Informationen

In vielen Fällen kann der Angriff gestartet werden, ohne dass sich das Opfer dessen bewusst ist. Selbst bei vorsichtigen Benutzern verwenden Angreifer häufig verschiedene Methoden, um den Angriffs zu kodieren, beispielsweise URL-Kodierung oder Unicode, sodass die Anforderung weniger verdächtig erscheint.

Datenbanklink zur Schwachstelle

https://cwe.mitre.org/data/definitions/79.html 


Sie haben noch Fragen?

Kontaktieren Sie uns

Kostenloser SEO-Check der OSG


Weitere Inhalte