User controllable HTML element attribute (potential XSS)

Was bedeutet User controllable HTML element attribute (potential XSS)?

Beim User controllable HTML element attribute kann es sich m├Âglicherweise um ein Cross-Site-Scripting handeln. Die Software neutralisiert die vom Benutzer kontrollierbaren Eingaben nicht oder fehlerhaft, 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 in eine Webanwendung eingegeben, normalerweise aus einer Webanforderung.
  2. Die Webanwendung generiert eine Webseite dynamisch, 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, etc.
  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 in der Lage sein sollten, auf Ressourcen zuzugreifen oder Code in einer anderen Dom├Ąne auszuf├╝hren.

In DOM-basierten XSS f├╝hrt der Client die XSS Injection in die Seite ein. Beim DOM-basierten XSS handelt es sich im Allgemeinen um ein Server-gesteuertes, vertrauensw├╝rdiges Skript, das an den Client gesendet wird, z.B. Javascript, das die Sicherheits├╝berpr├╝fungen eines Formulars ausf├╝hrt, bevor der Benutzer es sendet. Wenn das vom Server bereitgestellte Skript vom Benutzer bereitgestellte Daten verarbeitet und anschlie├čend wieder in die Webseite einf├╝gt (z.B. mit dynamischem HTML), ist DOM-basiertes XSS m├Âglich.

Bei dieser Pr├╝fung┬áwerden Benutzereingaben in Abfragezeichenfolgeparametern und POST-Daten gepr├╝ft, um zu ermitteln, wo bestimmte HTML-Attributwerte gesteuert werden k├Ânnen. Dies erm├Âglicht die Erkennung von Hotspots f├╝r XSS (Cross-Site-Scripting), f├╝r die eine weitere ├ťberpr├╝fung durch einen Sicherheitsanalysten erforderlich ist, um die Ausnutzbarkeit zu ermitteln.

L├Âsung

Verstehen Sie den Kontext, in dem Ihre Daten verwendet werden, und die erforderliche Kodierung. 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. Untersuchen Sie alle erwarteten Kommunikationsprotokolle und Datendarstellungen, um die erforderlichen Kodierungsstrategien zu bestimmen.

Verwenden Sie f├╝r alle Daten, die auf einer anderen Webseite ausgegeben werden, insbesondere f├╝r Daten, die von externen Eingaben empfangen wurden, die entsprechende Kodierung f├╝r alle nicht-alphanumerischen Zeichen.

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.

Beachten Sie, dass die HTML-Entity-Codierung nur f├╝r den HTML-Body geeignet ist.

Allgemeiner Schwachstellen-Datenbanklink

Wenn Sie noch Fragen bez├╝glich des Themas haben, dann k├Ânnen Sie sich gerne weiter ├╝ber die Seite der CWE Organisation mithilfe des ersten Links, oder auch durch die Seite der PortSwigger mithilfe des zweiten Links weiter informieren.┬á


Sie haben noch Fragen?

Kontaktieren Sie uns

Kostenloser SEO-Check der OSG


Weitere Inhalte