[English]Kleiner Splitter aus der Welt der Webbrowser. Im Chromium-Bug-Tracker gibt es eine Diskussion zu den spitzen Klammern ("<" und ">"), die als Zeichen in HTML-Attributen bzw. in innerHTML-Elementen vorkommen können. Nun soll eine Escape-Behandlung eingeleitet werden, um mXSS-Angriffe zu verhindern. Das könnte aber die Chromium-Browser (und weitere Browser) "kaputt" machen.
Admin-Passwörter schützen mit Windows LAPS. eBook jetzt herunterladen » (Anzeige)
Was ist mXSS?
Das Kürzel mXSS steht für "mutation cross-site scripting". Dieser Cross-Site-Scripting-Vektor (XSS), wurde laut dieser Quelle, bereits im Jahr 2007 durch Hasegawa entdeckt. Der Forscher war in einer Browser-Implementierung auf eine falsche Verwendung des Backtick-Zeichens (` ) gestoßen.
Sah dies zunächst wie ein Implementierungsfehler aus, zeigte sich, dass man auf das erste Beispiel für eine neue Klasse von XSS-Vektoren, später als mutationsbasierte XSS-Vektoren (mXSS) bezeichnet, gestoßen war. Diese mXSS-Vektoren können in innerHTML und verwandten Eigenschaften auftreten.
Konkret geht es um Zeichen, die in HTML-Attributen und Tags vorkommen können. So könnten die spitzen Klammern ("<" und ">"), die eigentlich HTML-Tags in HTML auszeichnen auch als Zeichen in Werten von Attributen dieser Tags auftreten.
Dann müsste der Browser eine Escape-Sequenz einleiten, die dafür sorgt, dass die Zeichen als Werte und nicht als einleitende und abschließende spitze Klammer für HTML-Tags interpretiert werden. Oder HTML-Tags werden, wie in nachfolgender Anweisung, falsch geschachtelt:
<form id="outer"><div></form><form id="inner"><input>
Durch entsprechende Zeichen ("<" und ">") in einem Attribut eines HTML-Tags könnte ein Angreifer schädlichen Code in eine Webseite oder eine Web-App einbetten, der dann ausgewertet und ausgeführt wird. Auf GitHub gibt es ein mXSS Cheat Sheet mit Beispielen. mXSS betrifft alle drei großen Browserfamilien: IE, Firefox und Chrome.
Worum geht es bei der Chromium-Diskussion?
Die Behandlung von mXSS-Codes in innerHTML-Elementen ist aber bei den Chrome Browser-Implementierungen nicht gelöst. Statt eine Escape-Sequenz einzuleiten wird der Inhalt geparst und ausgeführt.
Ich bin die Tage über obigen Post von Lukasz Olejnik auf das Thema gestoßen, was im Chromium Issues-Tracker seit Februar 2025 unter Escape "<" and ">" when escaping HTML attribute values to avoid mXSS diskutiert wird.
Es gibt einen Pull-Request Escape "<" and ">" when serializing attribute values #6362, um mXSS-Angriffe im Chromium-Browser zu eliminieren. Jemand gibt zu bedenken, dass die Kompatibilitätsauswirkungen für das Web für diese Änderung noch nicht bekannt ist.
Was bekannt sei, ist, dass die Änderung des aktuellen Verhaltens zurück auf das Jahr 2008 (oder wahrscheinlich 2011 für WebKit) zurück geht, wo diese Implementierung ausgeliefert wurde. Wenn ein mXSS-Schutz in Browsern implementiert wurde, könnte das zu gravierenden Auswirkungen führen.
MVP: 2013 – 2016
> alle drei großen Browserfamilien: IE, Firefox und Chrome.
Oh Du scheinst Webkit aka Safari oder Gnome Web nicht am Schirm zu haben…
Und IE? Bitte…
Der derzeit meist genutzte Browser:
https://www.stetic.com/de/market-share/browser/
"Interessante" Statistik, die du da ausgegraben hast. Die meisten Seiten beziehen sich auf Statcounter, wo die Zahlen ganz anders aussehen und wohl auch eher der Realität entsprechen:
https://gs.statcounter.com/browser-market-share
Die größte Datenbasis dürfte Cloudflare haben:
https://radar.cloudflare.com/reports/browser-market-share-2025-q1
*traue keiner Statistik die du selber nicht gefälscht hast*
Finde es echt interessant wie Cloudflare und Statcounter bei großen 3 doch fast deckungsgleich sind :)
Aber die "stetic" Statistik ist meines Erachtens nicht aussagekräftig. Es wird ja nicht mal die Erhebungsgrundlage genannt.
Naja das wurde eben aus der uralten Originalquelle übernommen. Da war IE halt noch ein Thema.
so sieht es aus… traue keiner Statistik, die du nicht selbst gefä…. ich meine irgendwoher her geholt hast…
Je nach Linse und Bubble, die man betrachtet (SEO-Schlangenöl Verkäufer, allgemeine Newsseiten, Tech-Bubble) schwanken die Anteile. Nur sollte der Anteil der Safari Mobile User nicht unterschätzt werden, dürfte mit der Anzahl der verkauften iOS Geräte recht gut korrelieren und die ist zumindest hier bei uns rund 1/3 zu 2/3 Android
Das mit den "innerHTML-Elementen" dürfe einigen Browser Editoren, die über eine Textarea hinausgehen, eher weniger gefallen…
Nach dem was ich bisher in den verlinkten Quellen gelesen (und verstanden) habe, hat Lukasz Olejnik nicht genau nachgelesen oder er hat es falsch formuliert. Es geht NICHT darum, dass alle spitzen Klammern aus dem HTML Standard entfernt werden sollen. Es geht nur um Werte mit spitzen Klammern in ATTRIBUTEN. Werden solche Klammern in HTML-Attributen oder innerHTML verwendet, also so etwas wie div class="", dann können die Browser damit nicht sicher genug umgehen.
Da es nicht um spitze Klammern generell geht, ist derzeit noch unklar, ob die vorgeschlagene Änderung überhaupt negative Auswirkungen hat. Der aktuelle Vorschlag ist, das Web-Archiv als Datenbasis zu nehmen und damit Tests auf mögliche Probleme zu machen.
Ich sehe hier nichts von "das Internet bricht bald zusammen".
Möglicherweise hat Du nur die Aussagen im Post von Lukasz Olejnik berücksichtigt oder meinen Text falsch interpretiert. Im Blog-Beitrag hatte ich explizit drauf hingewiesen, dass es um spitze Klammern in Attributen und in innerHTML geht. Sprich: Es werden HTML-Tags in einem HTML-Tag fehlerhaft geschachtelt, oder die Codes für spitze Klammern stehen als Werte in einem HTML-Attribut.
An dieser Stelle habe ich als Browser-Entwickler zwei Möglichkeiten:
Letzteres ist als Schutz vor mXSS-Angriffen angedacht. Nun weisen Leute berechtigt darauf hin, dass die Folgen einer solchen Änderung gegenwärtig nicht abschätzbar seien. Und da gebe ich den Leuten Recht – es kann auf "keine bis minimale Auswirkungen" bis "zig Apps und Webseiten funktionieren nicht mehr" hinauslaufen.
Falsch geschachtelte HTML-Tags sollten eigentlich nirgendwo vorkommen.
Selbst so uralte HTML-Editoren wie Microsoft Frontpage melden das als Fehler.
Ich dachte, wir reden über mXSS-Angriffe – die phösen Buben halten sich nicht an Regeln. Und wellformed HTML ist für manche Software ein Fremdwort.
Einfach mal ein paar Webseiten mit dem Validator vom w3c testen. Eine Seite wie t-online.de kommt auf fast 1.000 Zeilen in der Prüfung von denen viele Fehler sind. Es gibt kaum eine Webseite, welche sich an die Standards hält und durchgängig sauberes HTML liefert.
Link: https://validator.w3.org/