MXSS: Cross-Site-Scripting in der Google-Suche

Aufgrund subtiler Unterschiede beim Parsen von HTML-Code gelang es einem Sicherheitsforscher, gängige Filtermechanismen zu umgehen. Betroffen waren zwei Javascript-Bibliotheken und die Google-Suche.

Artikel veröffentlicht am 2. April 2019, 14:56 Uhr, Hanno Böck

Sicherheitslücken in der Google-Suche gibt es nicht oft, doch kürzlich wurde eine XSS-Lücke darin gefunden. (Bild: brionv, Wikimedia Commons/CC-BY-SA 2.0)

Cross-Site-Scripting-Lücken gehören zu den häufigsten Sicherheitsproblemen in Webanwendungen. Eine besonders spezielle Variante einer solchen Sicherheitslücke fand sich jetzt in der Google-Suche. Der Grund ist ein spezielles Verhalten von Browsern beim Verarbeiten des Noscript-Tags. Entdeckt hat das Problem der Sicherheitsexperte Masato Kinugawa von der Firma Cure53, der es an Google gemeldet hatte.

Die Details erklärt ein Hacker mit dem Pseudonym Liveoverflow in einem Youtube-Video. In modernen Webanwendungen ist es häufig üblich, dass man die Filterung von HTML-Daten nicht auf dem Server vornimmt, sondern auf dem Client. Das macht man insbesondere in Fällen, in denen teilweise HTML-Daten erlaubt sein sollen, etwa Formatierungen, andere wie beispielsweise Skripte dagegen nicht.

Filterung von HTML im Client

Dabei nutzt man den Browser-eigenen HTML-Parser, um Daten zu verarbeiten. Mit einem Template-Element in HTML ist es möglich, HTML-Daten zu parsen ohne sie direkt anzuzeigen. Anschließend kann man alle problematischen Tags und Attribute, die etwa eine Ausführung von Javascript ermöglichen, entfernen.

Ein subtiles Problem ergibt sich, wenn man ein solches Template-Element nutzt, um Eingabedaten mit einem Noscript-Tag zu verarbeiten. Der Noscript-Tag bietet Webseitenbetreibern die Möglichkeit, HTML-Code mitzuliefern, der nur angezeigt wird, wenn der Browser kein Javascript unterstützt. Oft wird das lediglich genutzt, um eine kurze Meldung anzuzeigen, die den Nutzer informiert, dass eine Webseite zwingend Javascript benötigt.

Dieser Noscript-Tag zeigt beim Parsen ein sehr spezielles Verhalten: Wenn Javascript aktiviert ist, wird der Inhalt zwischen dem Start und dem Ende des Noscript-Tags schlicht ignoriert. Wenn Javascript deaktiviert ist, wird der Inhalt hingegen als HTML interpretiert.

Sprich: Der Parser verhält sich je nach Situation unterschiedlich. Beim Parsen mit einem Template-Element, was wie oben beschrieben häufig für Filterung genutzt wird, ist Javascript deaktiviert.

Unterschiedliche Parser mit und ohne Javascript

Der XSS-Code, der nun den Bug triggert, lautet:

<noscript><p title="</noscript><img src=x onerror=alert(1)>">

Beim Filtern mit dem Template-Element und ohne Javascript ist dies korrekter HTML-Code. Der Teil in den Anführungszeichen wird, da es ein Attribut ist, nicht weiter beachtet.

Wird das Ganze jedoch im Browser gerendert, ist Javascript aktiviert. Der Teil <p title=" wird dann schlicht ignoriert und der Noscript-Tag mit </noscript> geschlossen. Der dahinterstehende HTML-Teil wird somit gerendert und kann Javascript ausführen.

Closure und Dompurify betroffen

Dieses Problem betraf die von Google entwickelte Javascript-Bibliothek Closure. Diese wird direkt von der Google-Suche zur Eingabefilterung verwendet, somit war diese direkt verwundbar. Auch in Dompurify, einer von Cure53 selbst entwickelten Javascript-Bibliothek, war das Problem ausnutzbar, allerdings nur, wenn man den Noscript-Tag explizit mit einer Whitelist an erlaubten Tags zulässt; betreffen dürfte das daher die wenigsten Webseiten. Inzwischen gibt es für die Bibliotheken Updates und auch die Google-Suche ist nicht mehr verwundbar.

Bei diesem Problem handelt es sich um eine Variante einer sogenannten MXSS-Sicherheitslücke (Mutation Cross Site Scripting). Damit werden Sicherheitslücken bezeichnet, welche die Eigenheiten von HTML-Parsern im Browser ausnutzen.

Nachtrag vom 2. April 2019, 16:29 Uhr

Wir haben im Text klargestellt dass die Sicherheitslücke bereits geschlossen ist.