Sécurité des applications web avec HTML5

mieux protéger une application internet

Ce site ne sera plus alimenté de contenu après août 2014. Tous les nouveaux articles seront redigés pour www.waitingforcode.com
La démocratisation de l'HTML 5 approche à grands pas. La régression des navigateurs obsolètes continue avec chaque nouvelle campagne publicitaire (Chrome, Opera, Internet Explorer 9). Est-ce que nous, les développeurs, nous avons quelque chose à craindre par rapport à ces changements ? Quels problèmes de sécurité amène l'HTML 5 et lesquels il pourra résoudre ?

Dans la première partie d'article on verra rapidement quels bouleversements auront/pourront avoir lieu avec la démocratisation des applications développées en HTML5. Ensuite on abordera quelques aspects sécuritaires des applications web écrites en HTML5.

HTML5 = Une facilité pour le développeur
Le HTML5 rendra les applications web modifiables plus facilement. Et tout cela sans devoir écrire des lignes en JavaScript. Grâce à l'attribut contenteditable l'internaute pourra éditer le contenu de la page.

Autre, de nouveaux balises pourront être une vraie alternative au Flash. <audio />, <video /> remplaceront tous les lecteurs vidéo et audio écrits en Flash. Ils pourront être utilisés pour lire le contenu multimédia.

La sémantique a également été améliorée. Les balises <header /> et <footer /> vont, par exemple, faciliter la prise en main des projets par de nouveaux développeurs.

La gestion des formulaires a aussi été enrichie. L'attribut required permettra au navigateur de valider si tous les champs obligatoires ont été saisis. Toujours du côté de validation, on pourra spécifier la valeur minimale et maximale d'un champ (min et max). Un autre élément, placeholder, rendra possible le pré-remplissage du champ qui sera vidé après l'événement onblur. L'attribut autofocus, quant à lui, activera automatiquement le champ donné après le chargement de la page.

Danger du Cross-Origin Resource Sharing (CORS)
Après le CSRF (Cross-Site Request Forgery) , encore une chose qui commence par Cross. Dans le cas du CORS, il s'agit d'une spécification qui permet de récupérer les informations provenant de noms de domaines différents (par exemple via un appel en AJAX). La seule condition à respecter par ces ressources distinctes est d'être la source de Cross-Origin. Ceci peut être garanti avec un en-tête Access-Control-Allow-Origin.

La démocratisation de cette solution flexible provoque néanmoins quelques soucis. Tout d'abord, la valeur de l'en-tête Access-Control-Allow-Origin risque d'accepter toutes les connections (par exemple pour une application très ouverte). Cela signifie que les requêtes de la part de tous les sites seront admises. L'exposition de l'application au danger est donc encore plus forte. Deuxièmement, même si l'on se limite à quelques noms de domaine, il y a toujours une possibilité de falsifier les en-têtes HTTP envoyés par l'application tiers.

Cette nouvelle spécification n'est pas un danger en soi. Au contraire, elle peut s'avérer très utile lors de l’interconnexion des applications. Elle devient problématique seulement à partir du moment où les règles de la bonne conduite ne sont pas respectées. Krzysztof Kotowicz évoque une faille sur minus.com. Dans ce cas, le site Minus a été vulnérable aux attaques CSRF à cause d'une protection insuffisante. Cette vulnérabilité a pu être exploitée, en grande partie, grâce au CORS.

Danger du WebSQL
L'apparition du système de stockage propre au navigateur renforcera les performances des applications en permettant d'y déplacer une partie de données. Mais ce sont aussi les attaquants qui auront désormais un endroit de plus pour exploiter des failles liées à SQL injection. La protection contre ce type d'attaque est la même que pour les bases de données côté serveur : les prepared statements.

Cependant, un autre problème surgit, XSS lié à DNS Spoofing. Le WebSQL adopte le concept Same Origin Policy. Selon lui, le serveur SQL du navigateur fait confiance à toutes les données originaires du même nom de domaine. Si l'attaquant réussit à exécuter une attaque Man-in-the-middle et d'usurper un nom de domaine, il pourra envoyer n'importe quelles informations au navigateur du client. L'essentiel pour se protéger est non seulement de bien échapper les données mais aussi de bien les encoder. Or, l'attaquant peut injecter les informations en encodage totalement différent de celui utilisé par nos filtres anti-XSS.

ClickJacking
Grâce à l'utilisation de nouveaux attributs, les applications pourront désormais être intégrées encore plus strictement. Par exemple, on pourra préciser si l'on accepte que notre système exécute le JavaScript contenu dans un <iframe />. Tout cela est garanti avec l'attribut sandbox.

L'attribut sandbox protège contre, entre autres, l'exécution dynamique des scripts JavaScripts inclus dans un <iframe />. Cela renforce la sécurité de notre application web en la préservant contre les attaques du type ClickJacking (redirection automatique après le chargement de l'iframe), XSS ou Phishing.


<iframe src="http://localhost/clickjacking/bad.html" id="frame1" sandbox />

Ce code affichera le contenu de la page bad.html, mais n'exécutera pas son JavaScript. Vous pouvez jouer avec cet attribut en téléchargeant le package d'exemple et en modifiant le fichier iframetest.html .

La protection contre ClickJacking, mais de nouveaux problèmes potentiels avec le WebSQL et CORS ce ne sont que quelques exemples des points qu'il faudra surveiller en plus pendant la mise à jour et le développement de nouvelles applications web, adaptées aux normes du HTML5.

L'article écrit en rythme de:

Jacky Rapon - Fallait pas
Bartosz KONIECZNY 18-12-2011 11:25 sécurité des applications web
Un conseil Android

Comment accéder au localhost ?

A la place de 127.0.0.1 il faut utiliser 10.0.2.2.