Cross Site Scripting (Reflected)

Was ist Cross Site Scripting (Reflected)?

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