[W3Conf] Brad Hill: „HTML5 Security Realities“

Man kann nichts über Sicherheit lesen, ohne über HTML-Sicherheit zu stolpern, das mit viel Übertreibung dargestellt wird. Stimmt das? Brad sagt nein. Der Zustand der Sicherheit im Web ist besser als je zuvor, und HTML5 ist zu einem großen Teil dafür verantwortlich.

XSS

Skript-Injektionen (oder XSS, oder „Cross Site Scripting“) sind die häufigste Anwendungsschwachstelle (ca. 95 % aller Webanwendungen).

„Wenn der Code eines anderen in Ihrer Webanwendung ausgeführt werden kann, gehört sie nicht mehr Ihnen.“

Aktuelle Abwehrmaßnahmen

• Eingabefilterung – gefährliche Inhalte entfernen
• Ausgabefilterung – Benutzerdaten kodieren, damit sie nicht als Markup behandelt werden

In HTML5 gibt es mehr davon (daher die Übertreibung), aber diese Filter waren bereits fehlerhaft.

Buch zu diesem Thema: Web Application Obfuscation.

„XSS-Filter waren von Anfang an zum Scheitern verurteilt.“

Denn: Browser sind unterschiedlich, Algorithmen waren geheim, Browser haben proprietäre Funktionen usw.

HTML5 hat jetzt ein „offizielles“ Parsing-Modell (zum ersten Mal). Durch die Standardisierung ist dies eine Positionsänderung in der Sicherheit im Web.

@hillbrad: „Geschlossene Plattformen konkurrieren um Entwickler, indem sie Funktionen anbieten. Offene Plattformen konkurrieren um Benutzer, indem sie Qualität anbieten.“ #w3conf

— Tim Hettler (@timhettler) 22. Februar 2013

Content Security Policy (erfunden von Mozilla, jetzt im W3C). HTTP-Header zur Erzwingung einer Umgebung mit minimalen Rechten für Skripte und andere Inhalte auf dem Client. Keine neue Idee. Brad vergleicht dies mit der Geschichte von Odysseus, der sich an den Mast bindet und jedem befiehlt, nichts zu sagen, was er hört.

Die Content Security Policy ist wie eine Reihe von Anweisungen (Whitelist/Blacklist) für Dinge, die ignoriert/erlaubt werden sollen. Zum Beispiel: Skripte nur von dieser Domain zulassen. Nur iFrames von diesen anderen Domains zulassen (vielleicht YouTube und Vimeo). Nur Schriften von diesen anderen Domains zulassen (vielleicht Ihr CDN). Erinnert mich an eine App-Cache-Manifest-Datei. Ich hatte keine Ahnung, dass das existiert. Anwenden über Meta-Tag.

Templating ist das gängigste Muster für den Aufbau von Webanwendungen. „Sie sind ein Hort von XSS-Schwachstellen“. Es gibt eine neue Spezifikation für Vorlagen, die dies löst.

Sichere Mashups

Diese Art von Apps integriert Inhalte aus mehreren Quellen unter einer. Fast jede App ist auf die eine oder andere Weise so.

Früher erlaubte Flash dies, da es eine cross-domain-policy hatte.

„Ein Stern („*“) in Ihrem crossdomain.xml ist eine riesige Katastrophe.“

#w3conf @hillbrad: Ein „*“ in Ihrer Master-Crossdomain.xml gibt jedem SWF im Internet die Möglichkeit, Ihre Website/Inhalte auszunutzen.

— Faruk Ateş (@KuraFire) 22. Februar 2013

Wie macht man Cross-Domain in HTML? Es gab schon immer eine Lücke. Sie können ein Skript von einer anderen Domain laden und in diesem Skript Inhalte verwenden (JSONP). Brad hat sich lange Sorgen darüber gemacht, aber niemand hat zugehört. Sie haben zugehört, als Facebook vor ein paar Wochen ein riesiges Problem damit hatte.

Cross-Origin Resource Sharing (CORS) (existiert seit 4-6 Jahren) ist der Weg nach vorne.

#w3conf @hillbrad: script src gibt Ihnen Code, dem Sie VERTRAUEN müssen; CORS gibt Ihnen Daten, die Sie VERIFIZIEREN können

— Kevin Marks (@kevinmarks) 22. Februar 2013

(Wir nutzen das immer mehr auf CodePen. Dieses HTML5 Rocks Tutorial ist großartig.)

„Die Same-Origin-Policy freiwillig lockern.“

Manche sagen: „Vorsicht vor dem promiskuitiven Sternchen“ auch bei CORS, aber es ist tatsächlich kein so großes Problem.

Wenn Sie Daten von anderswo benötigen, gibt es mehr Optionen.

• Sandboxed iFrames – <iframe sandbox="allow-scripts" src="different.domain"></iframe>
• postMessage – window.parent.postMessage(loginName, "trusted.mydomain.com");, testen, wenn Sie es erhalten

„Das wichtigste Papier zur Websicherheit seit langem:“ Privilege Separation in HTML5 Applications (PDF) von Devdatta Akhawe, Prateek Saxena und Dawn Song.

„Behandeln Sie Ihren eigenen Code wie ein Mashup.“

Es gibt TONNEN von zukünftigen Entwicklungen in der Sicherheit. Zukunft = hell.

Folien