Wir haben uns kurz vor Heiligabend den Mario Heiderich eingeladen, um über grauenvolle, abstruse und schier unlösbare Sicherheitslücken moderner Browser zu reden. Der richtige Stoff für besinnliche Weihnachtsstimmung und frohlockende Ausblicke ins neue Jahr!
Schaunotizen
- [00:00:11] DOM Clobbering, XSS via CSS, Template Injection, etc.
- Mario Heiderich, ehemaliger Webentwickler, heutiger Security-Experte, erzählt uns von den ganzen, dunklen Seiten der modernen Webentwicklung, die verheerende Schäden anrichten können, ohne das wir uns richtig wehren können. So beschreibt er aktuelle Sicherheitslücken in den Template Engines von AngularJS oder KendoUI und hält auch fest, dass diese Dinge gerne von den Bibliotheksherstellern auch mal auf die lange Bank geschoben werden (wie beispielsweise Frederic Hembergers jQuery Pull Request von „neulich“ zeigt). Es gibt Hilfestellungen, wie beispielswiese Marios DOMPurify, mit dem man Zeichenketten auf verdächtigen Code prüfen und gegebenenfalls bereinigen kann.
Es muss allerdings nicht immer JavaScript sein. Mit CSS kann man mit Hilfe der
@-moz-document
Regel und Regular Expressions im Firefox ganz einfach Session Token aus der URL klauen. Mario erklärt ausserdem, wie man die Paint-Zyklen der Browser und CSS Filter dazu ausnutzen kann, um auf bestimmte Zeichen zu schließen, die der Benutzer eingibt. Zukünftige Spaßquelle bieten SVGs im Allgemeinen und SVGs in Webfonts im Speziellen.Ebenfalls lückenreich und angriffsanfällig ist der DOM. Mit In the DOM, no one will hear you scream gibt es einen mittlerweile sehr bekannten Talk von Mario, der uns das Prinzip des DOM Clobbering näherbringt. Der Abwärtskompatibilität von HTML sei es geschuldet, dass man derartige Dinge überhaupt durchführen kann.
Dass man allerdings auch mit kommenden Technologien allerlei Unfung anstellen kann, zeigt der Ausblick auf Template Strings in EcmaScript 6. Mario sieht sich in seiner Rolle für die nächsten Jahre auf jeden Fall beschäftigt.
Abhilfe gewünscht? Mario lässt uns nicht im Schneeregen stehen, sondern gibt auch ein paar hilfreiche Schutzhinweise. Für hundertprozentige Absicherung empfiehlt die Workingdraft Crew eine Ausbildung zum Reisbauer auf dem zweiten Bildungsweg.
Weitere Links zu den Themen, die besprochen wurden:
- XSS CHallenge Wiki von Mario
- Sicherheitslücken im Test auf html5sec.org
- EcmaScript 6 Compatibilty Table
- Mustache Security
Zu guter Letzt gibt es noch einige Hinweise auf themenbezogene Konferenzen.
[01:35:37] Keine Schaunotizen
- HTTPS Mythen
- Golem klärt auf, was es mit den herumschwirrenden HTTPS Gerüchten und Mythen tatsächlich auf sich hat.
- Let’s make a Firefox Extension, the painless way
- Ein knackiges Tutorial beschreibt, wie man Extensions für Firefox entwickelt.
- Flexbox Adventures
- Schon wieder ein Flexbox Tutorial? Ja! Dieses zeigt allerdings interaktiv und ausführlich, was es mit den Properties
flex-grow
,flex-shrink
undflex-basis
auf sich hat.
Kommentare
Guido #
Geschrieben am 30.12.2014 um 02:29
Tolle Sendung, danke dafür!
Was mir noch nicht ganz klar ist: Was ist nun DOMPurify? Quasi ein HTML Purifier in JS?
Was sollte man denn nun alles an Daten durch DOMPurify jagen?
Stefan #
Geschrieben am 30.12.2014 um 13:31
DomPurify analysiert Strings auf mögliche Bosheiten und schmeisst dir einen gereinigten String zurück, den du dann via innerHTML in deinen DOM jagen kannst. Wir nutzen das zum Beispiel um fremden Code der durch IE Plugins in den DOM kommt zu bereinigen bevor wir damit weiterbasteln.
Die Beispiele hier: https://cure53.de/purify und hier: https://github.com/cure53/DOMPurify sollten dir weiterhelfen.
Sehr hilfreich, braucht halt einen Entwickler, der das dann auch anwendet. Die meisten Bibliotheken pfeiffen ja darauf. Wie jQuery. Dafür gibt’s aber dann wieder ein Plugin von Mario: https://github.com/cure53/jPurify
Guido #
Geschrieben am 30.12.2014 um 14:08
Hi Stefan,
jPurify sieht interessant aus, danke dafür. Ist es richtig, dass man bei jQuery + jPurify nichts mehr „manuell“ mit DOMPurify bearbeiten muss?
Wenn ich ohne jQuery/jPurify arbeite: Sollte dann einfach sämtlicher user generated content durch DOMPurify laufen? Also sowohl Sachen, die vom eigenen Server kommen (z.B. aus der DB) und ursprünglich von einem User stammen wie auch alles was der User direkt irgendwo eingeben kann?
Guten Rutsch und Danke!
Frederic Hemberger #
Geschrieben am 2.01.2015 um 12:37
Hi Guido,
jPurify ist eine jQuery-Extension, die alle jQuery-Methoden, die DOM-Strings verarbeiten überschreibt und den Inhalt erst mal durch DOMPurify durchjagt. DOMPurify muss dazu trotzdem noch geladen sein. Also statt z.B.
var clean = DOMPurify.sanitize(dirtyDOMString); $('body').append(clean);
kannst du damit$('body').append(dirtyDOMString); /* clean output via DOMPurify */
schreiben. Vorteil: Du musst deinen bestehenden jQuery-Code nicht umschreiben und kannst so auch für keine Stelle den sanitize-Aufruf vergessen.Prinzipiell gilt: Wenn deine Applikation Eingaben erlaubt, in denen an irgendeiner Stelle HTML vorkommen kann, solltest du die Eingaben filtern (und sei es nur bei der Ausgabe). DOMPurify läuft dabei momentan leider nur im Browser (entweder „vanilla“, als AMD-Modul für Require.js oder CommonJS-Modul für Browserify), leider noch nicht unter Node.js oder anderen JS-Umgebungen. Da fehlt uns momentan noch eine ausreichende Implementierung der DOM-Methoden, die wir zum Filtern nutzen. Es gibt fürs Backend aber auch alternative Tools, etwa für PHP, Java oder C#.
Guido #
Geschrieben am 2.01.2015 um 22:15
Hups, der Beitrag „2.01.2015 um 22:14“ sollte eigentlich hierhin, sorry…
Guido #
Geschrieben am 2.01.2015 um 22:14
Danke Frederic, das werde ich gleich mal einbauen.
Schützt ein Aufruf von htmlentities() oder der HTML Purifier bei der Ausgabe eigentlich ausreichend, so dass hier kein DOMPurify mehr nötig ist?
Frederic Hemberger #
Geschrieben am 3.01.2015 um 15:57
Der HTML Purifier macht im wesentlichen in PHP genau das, was DOMPurify in JS macht. Wie jetzt aber genau die Implementierung aussieht oder ob da Fälle bei den beiden Tools unterschiedliche gehandhabt werden, kann ich dir leider nicht sagen. Im Zweifelsfall kannst du gerne die DOMPurify Testcases mit nem Script gegen HTML Purifier laufen lassen und die Ausgaben vergleichen.
htmlentites()
alleine hilft dir ja an der Stelle nicht weiter, wenn der String nachher wieder als gültiges HTML auf der Seite dargestellt werden soll. Beim dafür nötigen Zurückwandeln hast du ja ggf. die ganzen XSS-Ferkeleien wieder drin.RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.