Wie lang darf eigentlich ein class-Attribut sein?

Ich arbeite nicht erst seit gestern mit HTML, aber diese Frage habe ich mir nie gestellt. Der aktuelle Security Now Podcast (Folge #810) mit seiner Beschreibung der interessanten ‘Prime+Probe 1, JavaScript 0: Overcoming Browser-based Side-Channel Defenses’ Forschungsarbeit hat mich erst darauf gebracht: Darin geht es um einen Ansatz um Nutzer*innen im Webbrowser ganz ohne Javascript zu tracken und der trickreiche Ansatz um mal wieder Cache Timings als Seitenkanal zu nutzen verwendet – Achtung! – 2 Millionen Zeichen lange Klassennamen. Zitat:

CSS Prime+Probe Implementation. Figure 3 shows a code snippet implementing CSS Prime+Probe, using CSS Attribute Selectors to perform the attack. Specifically, Line 9 defines a div with a very long class name (two million characters).

Kann das sein? Warum sollte die HTML Spezifikation derart lange Namen erlauben? Hätte ich vorher darüber nachgedacht wäre mein Tipp vermutlich bei 1024 oder maximal 32.768 Zeichen gelandet. Das sollte auch für sehr sprechende und exzessive Anwendungen von CSS Klassennamen ausreichen, wie sie z. B. die BEM Vorgehensweise nahelegt.

HTML Code mit sehr langem class-Attribut

Aber die Antwort, warum die Spezifikation solche langen Namen erlaubt, scheint einfach zu sein: Sie macht hier überhaupt keine Vorgabe! Demnach setzen nur die konkreten HTML Implementierungen der Webbrowser Grenzen, schon um zu verhindern, dass solche absurden Inhalte den Speicher zum überlaufen bringen. Aber wenn es solche Grenzen gibt, dann liegen sie offenbar weit jenseits dessen, was sich ‘vernünftig’ anfühlt.

Ob die Browserhersteller angesichts solcher Tricksereien nun anfangen engere Begrenzungen zu definieren? In regulären Webanwendungen sind jedenfalls kaum Anwendungen vorstellbar, die mehr als 1024 Zeichen für Klassennamen verwenden. Oder?

Kleines Pwn2Own Fazit – Lehren für Sicherheit im Webbrowser

In dieser Woche hat sich der jährliche Pwn2Own Wettbewerb ereignet, bei dem es schon seit einigen Jahren darum geht aktuelle Browser und Betriebssysteme (und dieses Jahr erstmalig auch VMs) zu hacken.

Einige Änderungen hat es in den letzten Jahren gegeben: Bekam der erfolgreiche Hacker zunächst nur das gehackte (‚pwn‘) Gerät geschenkt (‚own‘), so sind die insgesamt ausgeschütteten Preisgelder inzwischen in den 6-stelligen Bereich gegangen.

Sie vollziehen damit den Trend nach, den man allgemein beobachten kann: Sicherheitslücken sind ein wertvolles Gut geworden, welches sich bei staatlichen Abnehmern bzw. den sie versorgenden Spezialisten wie VUPEN oder HackingTeam für gutes Geld verkaufen lässt. Google, Mircosoft etc. haben daher auch die Prämien ihrer Bug Bounty Programme immer weiter angezogen.

Eine andere Änderung betrifft den Ausrichter, der nun zu Trend Micro gehört. Da die angetretenen Hacker ebenfalls zu großen Teilen zu auf IT Sicherheit spezialisierten Unternehmen gehören ist der Wettbewerb wohl noch stärker zu so etwas wie einem kleinen Familientreffen der Sicherheitsindustrie geworden.

Aber nun zu den Ergebnissen:

Chrome zeigt sich als ’sicherster‘ Browser

Von den Browsern, die die Ausrichter als Ziele genannt haben, sind alle gefallen, auch Chrome. Warum kann man Chrome trotzdem als den sichersten Browser bezeichnen? Weil eine Kombination von 4 Fehlern notwendig war, um ihn zu Fall zu bringen, davon 2 in Flash und einer im Windows Kernel. Der verbleibende Chrome Fehler war Google schon zuvor von anderer Stelle gemeldet worden, daher bekamen die Hacker nur einen Teil der Punkte für diesen Erfolg. Insgesamt zeigt dies wohl die große Robustheit, die Chromes Sandbox erreicht hat.

bugs
Ein Bug bleibt selten allein

Warum setze ist das ’sicherster‘ oben dann trotzdem in Anführungszeichen? Weil Sicherheit kein Zustand ist, sondern ein Prozess, der sich immer weiterentwickelt und morgen schon wieder anders aussehen kann. Da allerdings Google das Thema Sicherheit in Chrome in den letzten Jahren immer aggressiv verfolgt hat, kann man erst einmal davon ausgehen, dass man mit Chrome auf der sicheren Seite ist und bleibt.

Auch Microsofts Edge Browser schlägt sich offenbar viel, viel besser, als es früher dem IE gelang. Anscheinend bringt der Abschied von der alten Codebasis in dieser Hinsicht einiges.

‚Mozilla’s Firefox browser was intentionally dropped from the competition due to its complete lack of a sandbox, a critical security feature which raises the bar for exploitation.‘

Traurig ist hingegen der Stand von Firefox: Zwar ist der freie Webbrowser nach StatCounter immer noch knapp der weltweit zweithäufigst verwendete Browser, aber in Kreisen ernstzunehmender Hacker wird seine Überwindung anscheinend als so lächerlich einfach angesehen, dass man damit keine Anerkennung ernten kann. Man kann wohl eigentlich niemandem mehr raten Firefox zu nutzen, jedenfalls nicht, wenn man auf Sicherheit achtet.

Flash: Gefährlich und zunehmend unnötig

Ein alter Bekannter in Bezug auf Sicherheitsprobleme im Webbrowser ist natürlich das Flash Plugin, welches ja schon beim Chrome Hack eine Rolle spielte und in dem noch weiteren Lücken demonstriert wurden.

Ich habe meinen Chrome Browser schon vor einiger Zeit bei der Pluginausführung auf ‚Click to play‚ umgestellt, so dass Plugins erst gestartet werden, wenn ich es explizit will. Damit ist man auf diesem Wege deutlich weniger verwundbar.

Nach meiner Erfahrung nimmt die Zahl der Flash Einbindungen im Web – zumindest in dem Teil, in dem ich mich bewege – rasch ab. Es ist glaube ich schon Wochen her, dass ich einmal einen Inhalt unbedingt sehen wollte, der nur über Flash erhaltbar war.

Neues Angriffsziel: Die Betriebssystemkerne

Ein interessanter – und besorgniserregender – Trend bei diesem Pwn2Own Wettbewerb war die Konzentration der Hacker auf Fehler in den Betriebssystemen, an Stelle von Fehlern in den Browsern. Dies mag der Tatsache geschuldet sein, dass die Browser in Sicherheitshinsicht stark aufgerüstet haben und die Hacker nun zuerst an anderen Stellen suchen, wo sie einfacher Erfolg haben. Eine Folge davon war dann, dass die erfolgreichen Exploits gleich Systemrechte erlangen konnten, also quasi allmächtig sind im kompromittierten System.

Das kann man als Argument nehmen, dass der grundlegende Ansatz von Googles ChromeOS zumindest nicht falsch ist, nämlich das ein Betriebssystem eher weniger können sollte und dafür besser gehärtet werden kann.

Wer sich die beiden Tage des Wettbewerbs in Filmform ansehen möchte, der findet das hier:

http://ingoogle.com/pwn2own-2016-windows-os-x-chrome-edge-safari-all-hacked/

Wiederholt Google mit Chrome die Geschichte von Microsoft und dem Internet Explorer?

“Cynics surely look at this [the web version of Inbox is Chrome-only] as the second coming of Microsoft’s IE-only web technologies from the late ’90s, but my guess is that support for additional browsers iscoming .. and they shipped Chrome-first only because it was the fastest way they could ship.” — John Gruber | Montag, 3. XI 2014

Eine alte Darstellung des Pflügens (Quelle: Internet Archive): So wie der Bauer das Land bestellt, bereitet Google mit Chrome den Acker für zukünftige Webtechnologien.
Eine alte Darstellung des Pflügens (Quelle: Internet Archive): So wie der Bauer das Land bestellt, bereitet Google mit Chrome den Acker für zukünftige Webtechnologien.

Ist das eine merkwürdige Frage? Dieser Vergleich von Googles bisher unendlichem Fortschrittsdrang bei der Weiterentwicklung der Webtechnologien in seinem Chrome Browser, und der bleischweren Zeit eines Internet Explorers 6, der Microsoft nach dem Sieg über Netscape und dem Erringen der uneingeschränkten Hegemonie über das Web dazu diente, dieses technologisch quasi einzufrieren? Ich glaube schon. Aber warum eigentlich?

John Gruber kommt auf dieses Thema am Rande einer interessanten Betrachtung zu Google’s neuem ‘Material Design’, der Gestaltungssprache, die sich gerade über alle Google Dienste, Betriebssysteme und Apps ausbreitet. Er kann dabei nicht umhin auf zwei Punkte hinzuweisen:

Google, das Unternehmen, welches am längsten für den Triumph des Websals übergreifender Entwicklungsplattform über die nativen Apps gekämpft hat, setzt zum einen inzwischen intensiver als je zuvor auf solche Apps, jedenfalls für Android und iOS. Zum anderen zeigt er am Beispiel der brandneuen INBOX auf, dass die hier verfügbare Webversion zur Zeit einzig und allein unter Chrome funktioniert.

Ist das nicht genauso schlimm wie die proprietären Funktionen, die Microsoft damals in seinen Internet Explorer einbaute, und die anderen Browserherstellern das Leben schwer machten?

Es gibt dabei einen entscheidenden Unterschied: Google unterstützt andere Browser (in einigen Fällen) nicht, weil diese noch nicht die Funktionen bieten, die Chrome bereits enthält. Mit Chrome hat sich Google ein Mittel geschaffen das Web insgesamt im 6-Wochen-Takt voran zu bringen und hat hier als einzigen ‘Konkurrenten’, der dieses hohe Tempo mitmacht, die Mozilla Foundation. Alle anderen relevanten Hersteller — also Apple und Microsoft — nehmen ggf. die von den beiden Vorreitern entwickelten, getesteten, und schon im Einsatz befindlichen Standards dann später auf, wenn sie in ihren viel langsameren Releasezyklen mal wieder eine neue Version von Safari oder dem Internet Explorer veröffentlichen.

Im Gegensatz zur Versteinerung des Zeitalters der Microsoft Hegemonie befinden wir uns nun also in einem rasanten Zeitalter der unterschiedlichen Entwicklungsgeschwindigkeiten, bei dem es immer Beispiele wie INBOX geben wird, die so nahe an der ‘bleeding edge’ der Webtechnologie sind, dass sie schon aus Prinzip nicht von allen Browsern unterstützt werden können.

Es gibt daher keinen Grund eine erneute Versteinerung des Webs zu befürchten, solange Google von Mozilla, Microsoft und Apple ein Mindestmaß an Konkurrenz erfährt.