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.

Tipp

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

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