Firefox veut en finir avec le XSS

Le 24-06-2009

L'équipe de Firefox travaille actuellement sur une technologie qui permettra de mettre à l'abri les internautes des attaques Cross Site Scripting ou XSS.

Cette vulnérabilité se manifeste lorsque les entrées utilisateurs ne sont pas suffisamment filtrées, le pirate est alors en mesure d'injecter ce qu'il veut sur la page de réponse HTTP, y compris du HTML et du Javascript. Grâce à cette injection de code, il peut facilement modifier l'apparence du site internet, voler le cookie de l'utilisateur (dans le but de s'authentifier à sa place), réaliser du phishing voire même installer des malwares sur les ordinateurs des internautes.

L'origine du problème vient du fait que le client ne peut pas faire la différence entre un Javascript légitime développé par le créateur du site et un javascript injecté par un pirate. Aucun niveau de différenciation n'existe entre les différents scripts présents dans la réponse HTTP.

Le projet Content Security Policy est conçu pour empêcher ces attaques grâce à une police de sécurité précise et un renforcement des contraintes de sécurité.

Concernant la déclaration de la police, le développeur pourra choisir deux modes de communication au navigateur client :

Entête HTTP	X-Content-Security-Policy: DECLARATION_POLICE
Une balise HTML	<meta http-equiv="X-Content-Security-Policy" content="DECLARATION_POLICE"/>

Au cas où les deux déclarations seraient présentes, une nouvelle police sera appliquée issue de l'intersection des deux précédentes. Ainsi il est impossible d'agrandir la portée de la déclaration en ajoutant une balise meta ou un entête HTTP.

Pour ce qui est des restrictions, elles sont nombreuses et vont nécessiter des efforts d'adaptation conséquents :

• L'insertion de javascript entre les balises "<script>JAVASCRIPT</script>" sera interdite par défaut. Toutes les balises actuellement dans ce cas dans les pages HTML devront être supprimées et leur code déplacé dans des fichiers js séparés.
• Les attributs de gestion d'évenements comme par exemple "onclick" seront eux aussi désactivés et l'utilisation de javascript dans les URLs ne sera plus possible (problème pour toutes les applications ayant basé leur fonctionnement sur ce principe et plus basiquement toutes les applications ASP .NET).
• L'exécution à partir de code contenu dans des chaînes de caractères sera interdite. Ainsi les 'eval("alert(2)")' et l'utilisation de setTimeout, setInterval, ... seront maintenant fortement limités.
• Toutes les utilisations de ressources hébergées sur un autre domaine devront faire l'objet d'une déclaration précise. Ainsi l'inclusion d'une image d'un autre site internet aura un impact direct sur la déclaration de la police. On imagine mal comment cette restriction peut s'appliquer sur des sites permettant à leur utilisateur d'insérer du contenu, ...

Voici quelques exemples concrets :

Entête HTTP	META tag
X-Content-Security-Policy: allow self	<meta http-equiv="X-Content-Security-Policy" content="allow self" />

Autorise seulement tous les contenus issus du domaine du site internet

Entête HTTP	META tag
X-Content-Security-Policy: allow self; img-src *; \ object-src media1.com media2.com; \ script-src userscripts.example.com	<meta http-equiv="X-Content-Security-Policy" content="allow self; img-src *; object-src media1.com media2.com; script-src userscripts.example.com" />

Autorise les contenus issus du domaine du site internet, les contenus multimédia des domaines media1.com et media2.com, ainsi que les javascripts hébergés sur userscripts.example.com

Une fois le navigateur client informé, celui-ci pourra mettre en application la police envoyée par le serveur en refusant les contenus non autorisés. Il sera même en mesure d'envoyer des rapports d'erreurs au serveur pour l'informer que certains contenus HTML de son site ne respectent pas la police, par exemple dans le cas d'une tentative d'injection malicieuse.

70% des sites internet possèdent des failles de type XSS, il est clair que cette technologie permettra grandement leur diminution. Malheureusement la spécification actuelle ne permet pas d'éliminer complètement la menace. Plusieurs problèmes nous viennent à l'esprit :

• Si un entête HTTP est utilisé pour déclarer la police et qu'il est possible d'injecter avant celui-ci (typiquement dans le cookie) alors un pirate pourra définir sa propre police et écraser la légitime. "Only the first one received by the user agent will be considered; any additional X-Content-Security-Policy HTTP Response headers in the same request will be ignored" (HTTP Header Placement)
• Le fait que deux déclarations amènent à une nouvelle plus restrictive peut permettre en utilisant la technique précédente d'empêcher le fonctionnement normal du site.
• L'utilisation de E4X (ECMAScript pour XML) permet de contourner la restriction d'autorisation des scripts de même domaine.

<html>
<script src="#"></script>
{alert(1)}
</html>

La source du script est bien la page elle même avec src="#", le code alert(1) est exécuté (The Spanner).

A noter que cette spécification est en pleine étude et surement soumise à des changements significatifs. Enfin, Mozilla assure que cette technologie n'empêchera pas le bon fonctionnement des sites internet qui ne l'implémenteront pas.