Devoxx 2012 – Securing the client side

Depuis quelques années, le développement web s’oriente vers toujours plus de code côté client. Cependant, ce transfert de responsabilités pose de nombreux problèmes de sécurité.

Heureusement HTML5 arrive avec une série de standards pour améliorer la sécurité de vos sites au niveau du navigateur.

J’ai donc suivi une conférence de Mike West, membre de l’équipe de développement de Google Chrome, à Devoxx pour en savoir plus sur le sujet.

HTTPS à tous les étages

La première chose à faire pour sécuriser votre site est d’activer HTTPS. En effet, c’est le seul moyen de limiter la possibilité qu’un tiers puisse intercepter vos données avec une attaque de type man in the middle.

Et si l’on regarde un peu comment nous utilisons le web au quotidien, on se rend compte que les possibilités pour ce type d’attaque sont beaucoup plus élevées qu’on ne le croit. En effet nous utilisons de plus en plus de wifi gratuits dont nous n’avons aucun contrôle que ce soit dans les fastfoods, les parcs, les bars, etc.

Cependant, même si votre site est en HTTPS, l’utilisateur peut toujours se connecter en HTTP. En général une redirection 301 est mise en place pour le renvoyer vers le HTTPS mais cette première connexion n’est pas sécurisée.

Heureusement, un nouvel en-tête HTTP est disponible :  strict-transport- security qui permet d’obliger le client à passer en HTTPS.

Un autre problème est que, pour faire du HTTPS, il faut un certificat SSL valide. Pour cela Mike West recommande startssl.com qui permet d’obtenir des certificats valides basiques gratuitement ou avec des options de validation en payant un prix assez bas.

Le cross Scripting à l’assaut de vos sites

Le cross scripting (XSS) est un type d’attaque souvent sous-estimé par les développeurs web et qui peut être très dangereux. En gros, le navigateur se base sur la notion d’origine pour savoir à quoi a accès le code javascript exécuté.

Tant que le script s’exécute sur votre domaine, ce qui est le cas puisqu’il est injecté dans votre page HTML, il aura accès aux cookies, local storages, etc… sans que le navigateur puisse savoir qu’il est malicieux.

Pour se protéger de ce type d’attaque, la théorie est globalement de : valider toutes les données dont la source n’est pas fiable (une information saisie par l’utilisateur étant très peu fiable par nature 🙂 ) et, avant d’afficher des informations dynamiques, échapper le texte pour éviter du code malicieux de s’exécuter.

La théorie est simple, la pratique l’est beaucoup moins. En effet, il peut être important de laisser les utilisateurs saisir des choses potentiellement dangereuses. De même, la manière d’échapper du texte dépend de l’endroit où celui-ci est inséré (html, css, javascript, commentaires, etc.), ce qui complexifie la tâche.

Pour résoudre ce problème, Google propose un framework pour faciliter la gestion de ce type de problèmes. Mais cela n’est toujours pas parfait : il n’est pas possible de garantir qu’il ne reste pas un bug dans un navigateur permettant une attaque XSS.

Pour limiter les risques, il est important de limiter les accès au maximum, comme cela est le cas sous unix pour la gestion des droits et où les applications sont lancées via un utilisateur aux droits limités.

Définir une politique de sécurité

Depuis Firefox 4, Mozilla a introduit une fonctionnalité permettant de définir une politique de sécurité au niveau du contenu a.k.a Content Security Policy. Depuis peu, cette fonctionnalité est en cours de validation par le W3C pour devenir un standard HTML5.

Le principe est relativement simple, il consiste à établir une liste blanche de domaines pour chaque contexte (css, iframe, médias, javascript, etc.) d’où pourront être téléchargés et exécutés les fichiers.

Ainsi, si vous avez un bouton google+, vous ajoutez le domaine qui expose le script google+ à cette liste et il pourra s’exécuter sur votre site. Si votre site subit une attaque XSS et que quelqu’un essaie d’injecter un script sur un autre domaine, il ne pourra pas s’exécuter.

Cela se fait via un header HTTP :

Content-Security-Policy: script-src 'self' https://apis.google.com

Pour encore plus de sécurité vous pouvez interdire l’exécution de script inline dans vos pages HTML. Cela vous obligera à mettre tout votre javascript dans des fichiers séparés et vous empêchera de mélanger la vue et le contrôle de celles-ci, poussant votre code vers un modèle MVC. Pour certains c’est une bonne chose mais pour d’autres c’est un des défauts des politiques de sécurité de contenu.

Pour plus d’informations sur les options possibles, Mike a écrit un article sur HTML5 rocks.

Sandboxing des iframes

Avec HTML5 arrive un nouvel attribut sur les iframes sandbox qui permet de les lancer dans un process sécurisé et séparé de celui du reste du site.

Cet attribut vous permet également de définir de manière fine ce que peut faire cette iframe : exécuter du javascript, ouvrir des popups, etc.

Si l’on couple cet attribut et les politiques de sécurité de contenu, il est possible de désactiver la fonction eval() dans votre site principal et de créer une page qui s’exécutera dans une iframe sandboxée si vous en avez besoin.

L’exemple que donne Mike est celui de Handlebar qui est un framework de templating utilisant la fonction eval(). En utilisant l’API de messaging de HTML5, il est possible d’envoyer du contenu à notre iframe qui exécutera notre template et renverra à son tour le code HTML généré à la page.

De cette manière l’appel dangereux, ici eval(), sera fait dans un bac à sable sécurisé et ne pourra pas compromettre votre site.

Au passage, il souligne que l’attribut innerHtml des objets représentant les noeuds HTML est potentiellement dangereux car il exécute le javascript qui lui est injecté.

De nouveaux attributs font également leur apparition sur les iframes :

• seamless qui permet d’appliquer les CSS de la page principale à l’iframe
• docSrc qui permet de créer une iframe en lui passant le contenu et donc en évitant une requête HTTP au serveur.

Conclusion

La présentation était vraiment intéressante et présentait des solutions concrètes pour lutter contre le XSS, ce qui manque souvent dans les présentations orientées sur la sécurité. Pour le moment, ces solutions ne sont pas encore supportées sur tous les navigateurs et sont en cours de standardisation. Mais ça s’annonce plutôt bien avec des supports partiels dans IE10, et avec une dégradation naturelle pour les navigateurs qui ne les supportent pas puisqu’il s’agit de simples headers HTTP ou d’attributs.