• IT-Karriere:
  • Services:

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 , Hanno Böck
Sicherheitslücken in der Google-Suche gibt es nicht oft, doch kürzlich wurde eine XSS-Lücke darin gefunden.
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.

Stellenmarkt
  1. itdesign GmbH, Tübingen (Home-Office möglich)
  2. Universität Hamburg, Hamburg

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.

Bitte aktivieren Sie Javascript.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
  • ohne Werbung
  • mit ausgeschaltetem Javascript
  • mit RSS-Volltext-Feed


Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)

Kein Kostverächter 02. Apr 2019

XSS (Cross Site Scripting) ist der Oberbegriff von Methoden, Javascript im Kontext einer...

hab (Golem.de) 02. Apr 2019

Ich hab das jetzt im Text so umformuliert dass klar wird dass die Sachen bereits gefixt sind.


Folgen Sie uns
       


Watch Dogs Legion - Raytracing im Vergleich

Wir zeigen die Auswirkungen von Raytracing-Spiegelungen im integrierten Benchmark von Watch Dogs Legion. Dort wie im Spiel reflektieren Wasserfläche, etwa Pfützen, sowie Glas und Metall - also Fenster oder Fahrzeuge - die Umgebung dynamisch in Echtzeit.

Watch Dogs Legion - Raytracing im Vergleich Video aufrufen
    •  /