© Liashko/Shutterstock.com
Entwickler Magazin
Wie sieht es aktuell mit der Sicherheit von HTML5 aus?

HTML5 Security, reloaded

Seit den letzten beiden Artikeln zur Sicherheit von HTML5 [1], [2] sind zwei Jahre vergangen, und in der Zeit haben sich sowohl HTML5 als auch die Angriffe darauf und darüber weiter entwickelt. Zeit also für eine aktualisierte Bestandsaufnahme.

Carsten Eilers


Video: Intro to HTML5

Los geht es mit einem leidigen Thema: Cross-site Scripting. Was von vielen als lästige Kleinigkeit abgetan wird, lässt durchaus gefährliche Angriffe zu. Und ein Artikel über HTML5 und Sicherheit ohne die Erwähnung von XSS ist ganz einfach unvollständig. Das von Mario Heidrich gepflegte HTML5 Security Cheatsheet [3] führt alle bekannten XSS-Angriffsvektoren auf.

Da fällt mir gerade auf, dass ich immer von HTML5 schreibe, aber was ist das eigentlich? Nun, das weiß niemand so genau, denn HTML5 als Standard ist „Work in Progress“ – ein sich mehr oder weniger langsam weiter entwickelnder Standard also. Das Gleiche gilt für die Implementierung von HTML5 in den Webbrowsern: alles und überall „Work in Progress“. Und um dem Ganzen die Krone aufzusetzen, haben W3C und WHATWG die Zusammenarbeit aufgekündigt. In Zukunft gibt es also zwei sehr wahrscheinlich langsam auseinanderdriftende Versionen von HTML5. Und das ist genau das, was man nicht brauchen kann, wenn man etwas sicher entwickeln und implementieren will. Es ist also mit weiteren Angriffsvektoren für XSS-Angriffe zu rechnen, weil die Browser die Tags, Attribute etc. unterschiedlich interpretieren.

Betrachten Sie also Ihre XSS-Schutzmaßnahmen ruhig auch als „Work in Progress“, sofern Sie nicht HTML in den Eingaben generell verbieten oder über eine restriktive Whitelist auf harmlose Eingabe beschränken können. Aber auch beim Einsatz einer Whitelist sollten Sie mögliche neue Angriffe im Auge behalten und die Whitelist ggf. anpassen, damit sie keine gefährlichen Eingaben erlaubt.

HTML5 gefährdet alle Webanwendungen – auch alte!

Ob eine Webanwendung selbst HTML5 verwendet oder nicht, ist für den Angriff erst einmal völlig egal. Entscheidend ist, dass der eingeschleuste XSS-Code nicht ausgefiltert wird und das Opfer einen HTML5-fähigen Webbrowser verwendet. Und welcher Webbrowser ist heutzutage nicht HTML5-fähig? Das folgende Beispiel verdeutlicht das Problem sehr schön: Nehmen wir mal an, Ihre Webanwendung enthält den Code

echo "";

Mit der Eingabe

" autofocus onfocus=alert(1) "

ergibt das in der erzeugten HTML-Seite

Das autofocus-Attribut lenkt den Fokus automatisch auf das input-Tag, und wenn es im Fokus ist, wird der Code im onfocus-Attribut ausgeführt: Treffer, versenkt! – Die Alert-Box geht auf.

Ist Ihnen an der Eingabe etwas aufgefallen? Der XSS-Angriff kommt ohne aus. Sollte Ihr ...

Entwickler Magazin
Wie sieht es aktuell mit der Sicherheit von HTML5 aus?

HTML5 Security, reloaded

Seit den letzten beiden Artikeln zur Sicherheit von HTML5 [1], [2] sind zwei Jahre vergangen, und in der Zeit haben sich sowohl HTML5 als auch die Angriffe darauf und darüber weiter entwickelt. Zeit also für eine aktualisierte Bestandsaufnahme.

Carsten Eilers


Video: Intro to HTML5

Los geht es mit einem leidigen Thema: Cross-site Scripting. Was von vielen als lästige Kleinigkeit abgetan wird, lässt durchaus gefährliche Angriffe zu. Und ein Artikel über HTML5 und Sicherheit ohne die Erwähnung von XSS ist ganz einfach unvollständig. Das von Mario Heidrich gepflegte HTML5 Security Cheatsheet [3] führt alle bekannten XSS-Angriffsvektoren auf.

Da fällt mir gerade auf, dass ich immer von HTML5 schreibe, aber was ist das eigentlich? Nun, das weiß niemand so genau, denn HTML5 als Standard ist „Work in Progress“ – ein sich mehr oder weniger langsam weiter entwickelnder Standard also. Das Gleiche gilt für die Implementierung von HTML5 in den Webbrowsern: alles und überall „Work in Progress“. Und um dem Ganzen die Krone aufzusetzen, haben W3C und WHATWG die Zusammenarbeit aufgekündigt. In Zukunft gibt es also zwei sehr wahrscheinlich langsam auseinanderdriftende Versionen von HTML5. Und das ist genau das, was man nicht brauchen kann, wenn man etwas sicher entwickeln und implementieren will. Es ist also mit weiteren Angriffsvektoren für XSS-Angriffe zu rechnen, weil die Browser die Tags, Attribute etc. unterschiedlich interpretieren.

Betrachten Sie also Ihre XSS-Schutzmaßnahmen ruhig auch als „Work in Progress“, sofern Sie nicht HTML in den Eingaben generell verbieten oder über eine restriktive Whitelist auf harmlose Eingabe beschränken können. Aber auch beim Einsatz einer Whitelist sollten Sie mögliche neue Angriffe im Auge behalten und die Whitelist ggf. anpassen, damit sie keine gefährlichen Eingaben erlaubt.

HTML5 gefährdet alle Webanwendungen – auch alte!

Ob eine Webanwendung selbst HTML5 verwendet oder nicht, ist für den Angriff erst einmal völlig egal. Entscheidend ist, dass der eingeschleuste XSS-Code nicht ausgefiltert wird und das Opfer einen HTML5-fähigen Webbrowser verwendet. Und welcher Webbrowser ist heutzutage nicht HTML5-fähig? Das folgende Beispiel verdeutlicht das Problem sehr schön: Nehmen wir mal an, Ihre Webanwendung enthält den Code

echo "";

Mit der Eingabe

" autofocus onfocus=alert(1) "

ergibt das in der erzeugten HTML-Seite

Das autofocus-Attribut lenkt den Fokus automatisch auf das input-Tag, und wenn es im Fokus ist, wird der Code im onfocus-Attribut ausgeführt: Treffer, versenkt! – Die Alert-Box geht auf.

Ist Ihnen an der Eingabe etwas aufgefallen? Der XSS-Angriff kommt ohne aus. Sollte Ihr ...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang