AntiXSS : une nouvelle attaque webintroduite par les filtres XSS des

navigateurs

Vincent Delaunayvincent.delaunay@insa-lyon.fr

Tuteur de PFE : François Lesueur

Projet de Fin d’Etudes Département Télécoms, Services et Usages INSA de Lyon

18 Juin 2015Résumé

Ce travail explore les effets secondaires de l’apparition d’un nouveau dispositif de sécurité dans lesnavigateurs web. Ce dispositif vise à protéger les utilisateurs d’une classe d’attaques web, les attaquespar Cross Sites Scripting (XSS), et est donc appelé filtre XSS.

Après une clarification du contexte technologique du web, et un état de l’art présentant les évolutionsdes filtres XSS, je montrerai que ceux-ci peuvent être sujet à des faux positifs, et l’impact de leur réactiondans ce cas.

Cela permettra de poser la problématique suivante : ces faux positifs peuvent-ils être contrôlés par unattaquant, et la réaction du filtre peut-elle compromettre la sécurité de l’utilisateur ?

Ce rapport présente l’ensemble des résultats obtenus, qui comprennent une étude montrant que pourle plus moderne de ces filtres XSS, XSSAuditor, il est en effet possible pour un attaquant de manipulersuffisamment le comportement du filtre pour monter une attaque, jusqu’ici ignorée, et que je baptiseAntiXSS. Je présente ce faisant les techniques que j’ai mises au point pour cela, et les éléments à réunirque j’ai identifiés pour que l’attaque puisse avoir lieu.

Afin d’illustrer ces résultats, je propose ensuite une série de proofs of concept, scénarios d’applicationsdont je présente des parties de l’implémentation, qui sont vulnérables, et pour lesquelles je présente uneattaque par AntiXSS, avec ses conséquences.

Enfin, afin d’assister dans l’analyse d’une application web pour y détecter des AntiXSS potentielles,je propose un outil intégrant les conclusions de mon étude : AntiXSS-Auditor.

Keywords

Web - Security - Cross Sites Scripting (XSS) - Client-side filters - XSSAuditor - Induced false positives

TABLE DES MATIÈRES

I Introduction 4

II Contexte du travail 5

II-A Page web, navigateur, DOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

II-B Bug, vulnérabilité, attaque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

II-C Cross Sites Scripting (XSS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

II-C1 Une vulnérabilité par injection . . . . . . . . . . . . . . . . . . . . . . 6

II-C2 Trois types de XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

II-C3 Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

II-C4 Risque associé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

II-D Filtres XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

II-E AntiXSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

III Analyse de la problématique et cahier des charges 9

III-A Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

III-B Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

III-B1 Etudier les détails du comportement d’un filtre et les moyens de lecontrôler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

III-B2 Concevoir et illustrer des contextes dans lesquels on peut parler d’attaque 9

III-B3 Développer un outil pour assister à la recherche de tels contextes . . . 9

III-B4 Utiliser cet outil pour déterminer l’existence de ces contextes . . . . . 9

IV Etat de l’art 10

IV-A NoScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

IV-B Internet Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

IV-C La faille Universal XSS (UXSS) de IE8 . . . . . . . . . . . . . . . . . . . . . . . 11

IV-D XSSAuditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

IV-D1 En finir avec les expressions régulières . . . . . . . . . . . . . . . . . 12

IV-D2 Limiter les effets de bord d’un faux positif . . . . . . . . . . . . . . . 13

IV-D3 Design et architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

IV-D4 Le filtre étudié au cours de ce travail . . . . . . . . . . . . . . . . . . 14

V Etude théorique et appliquée d’une AntiXSS 15

V-A Scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

V-B Les codes critiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

V-B1 Actif ou passif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

V-B2 Discrétion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

V-B3 Importance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

V-B4 Un exemple concret de code critique idéal . . . . . . . . . . . . . . . . 16

V-C Contrôler un faux positif avec XSSAuditor . . . . . . . . . . . . . . . . . . . . . 16

V-C1 Les points d’entrée du moteur javascript . . . . . . . . . . . . . . . . . 16

V-C2 Provoquer un faux positif de XSSAuditor . . . . . . . . . . . . . . . . 17

V-C3 Cibler un code critique . . . . . . . . . . . . . . . . . . . . . . . . . . 17

V-D Remarques et principales difficultés attendues . . . . . . . . . . . . . . . . . . . . 17

V-D1 La concaténation des fichiers javascript . . . . . . . . . . . . . . . . . 18

V-D2 Enregistrement des évènements depuis le javascript . . . . . . . . . . . 18

VI Réalisations 19

VI-A Proofs of concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

VI-A1 Code critique sur une fonctionnalité, depuis un attribut HTML . . . . 19

VI-A2 Code critique de sécurité, depuis un script inline . . . . . . . . . . . . 20

VI-A3 Code critique seulement partiellement Discret . . . . . . . . . . . . . . 21

VI-B AntiXSS-Auditor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

VI-B1 Objectifs et fonctionnalités visées . . . . . . . . . . . . . . . . . . . . 23

VI-B2 Pistes et choix de conception . . . . . . . . . . . . . . . . . . . . . . . 24

VI-B3 Choix d’implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . 25

VI-B4 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

VI-B5 Difficultés rencontrées pour AntiXSS-Auditor . . . . . . . . . . . . . . 27

VII Conclusion et perspectives 28

VII-A Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

VII-B Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Références 30

I. INTRODUCTION

La question de la sécurité des systèmes et usages est sans cesse plus centrale dans la technologie.Avec une quantité toujours croissante de notre activité et de nos informations qui sont présentes en ligne,le web est un secteur particulièrement concerné.

De nouvelles solutions sont constament proposées, testées, voir implémentées, pour répondre à desmenaces qui sont parfois identifiées depuis longtemps. Cependant, il est toujours important, lorsqu’unnouvel élément est intégré ainsi, de bien étudier les impacts parfois imprévus qu’il pourrait avoir parailleurs.

Les Cross Sites Scripting (XSS) sont une classe d’attaques web bien connues. Bien que largementdocumentée [1], les vulnérabilités sur lesquelles l’attaque repose restent très répandues, laissant lesutilisateurs en risque.

Les moyens de sécuriser une application web contre les XSS sont également connus [2], maisnécessitent du développeur d’une part d’avoir conscience du risque, et d’autre part d’avoir les compétencespour appliquer correctement ces solutions. Le fait que les attaques par XSS soient toujours si populairesindique que ces conditions ne sont pas assez souvent réunies pour s’estimer satisfait de la situation.

Il est intéressant de noter que pour la majorité de ces attaques par XSS, il n’y a de conséquence quepour l’utilisateur d’un site web vulnérable, et aucun effet sur le fonctionnement ou l’intégrité du sitelui-même.

La situation n’étant pas adressée de manière satisfaisante par les propriétaires de ces sites, une nouvellepiste de solution a émergé du côté des utilisateurs. Elle consiste en l’ajout d’un filtre au niveau dunavigateur web, qui tentera de détecter et neutraliser les tentatives d’attaques par XSS.

Cependant, il n’existe pas de signature de référence d’une attaque par XSS. Ces filtres reposent surdes heuristiques pour déterminer s’ils doivent se déclencher ou non.

De la nature nécessairement imparfaite de ce filtrage découle l’existence de faux négatifs comme defaux positifs. Ces faux négatifs sont en pratique des moyens de contourner le filtre, et confirment queces filtres ne sauraient que mitiger la menace des XSS.

Quant aux faux positifs, il s’agit de cas où le filtre se déclenche et agit sur un élément de la pagepourtant légitime. Or, il s’avère que ces faux positifs peuvent être volontairement provoqués, et c’est làl’idée originale de mon travail : déterminer leur impact, du point de vue de la sécurité de l’utilisateur.

Ce document commencera par introduire le contexte de mon travail (partie II), en clarifiant les notionsnécessaires à sa compréhension telles que les XSS, ou le fonctionnement interne d’un navigateur. Jepourrai alors, en partie III, présenter la problématique que j’ai définie, et le cahier des charges qui endécoule. La partie IV proposera un état de l’art qui présentera l’évolution des filtres XSS des navigateurs,ainsi que leur état actuel, et permettra de positionner le travail effectué lors de ce projet.

Cela posé, je présenterai mes travaux dans les parties V et VI. Partie V, je présenterai en détail monétude autour du concept d’AntiXSS que je propose, et mes conclusions sur comment cette attaque peut sedérouler, dans quelles circonstances, et quelles méthodes j’ai identifiées pour y parvenir. Dans le but devalider expérimentalement l’étude précédente, je présenterai ensuite, partie VI, des scénarios que j’ai misau point pour lesquels je ferai la démonstration de telles attaques. Enfin, je décrirai le processus ayantaboutit à la création d’un outil permettant d’auditer des pages web, afin d’identifier celles qui présententun contexte dans lequel une AntiXSS est un risque.

Ce rapport se terminera par une conclusion sur le travail effectué et ses perspectives.

II. CONTEXTE DU TRAVAIL

Cette partie sera consacrée à la présentation de notions nécessaires à la compréhension du reste dece document. Certaines sont relativement générales et pourront sembler évidentes mais méritent toutefoisd’être définies, d’autres sont plus spécifiques et seront explorées en détail par la suite.

A. Page web, navigateur, DOM

Dans le web moderne, on parle volontiers d’"application" plutôt que de "page" [4]. En effet, lespages web ont fortement évolué depuis l’époque où elle n’étaient que des documents statiques, et ellesembarquent aujourd’hui souvent une part importante de logique, permettant de les considérer comme desprogrammes à part entière.

Le langage dans lequel un programme peut être écrit pour ces pages (le plus répandu, et celui quinous concerne ici), est le javascript.

Ce qui permet au javascript d’être exécuté est la capacité du navigateur à l’interpréter et à l’exécuter.A l’aide de javascript, le développeur de l’application peut alors contrôler certains comportements dunavigateur, par exemple modifier la page affichée ou envoyer des requêtes HTTP vers d’autres ressources.

Pour afficher le contenu d’une page web, le navigateur part du code source HTML de la page, présentdans la réponse HTTP à sa requête pour la page. Ce code source est analysé par un parseur HTML,élément fondamental du navigateur (parfois appelé tokenizer), pour créer le Document Object Model(DOM) [5].

Le DOM est une abstraction nécessaire au dynamisme d’une page web. C’est la structure de données(sous forme d’arbre) qui représente l’état d’une page telle qu’elle est affichée. Généré initialement àpartir du code source en HTML, il peut ensuite être modifié par le code javascript qui y serait présent,afin d’ajouter, modifier, ou supprimer des éléments de la page.

Lorsque, au cours de la construction du DOM, le parseur HTML rencontre ce qui est déclaré commedu code javascript, il l’envoie au moteur javascript (js engine), afin d’être interprété et exécuté (évalué).

Le javascript pouvant modifier le DOM et ajouter de nouveaux éléments intégrant eux-même dunouveau code javascript, ce circuit est une boucle.

La chaîne de ces opérations est illustrée figure 1.

FIGURE 1. Parsing flow de HTML5, d’après les spécifications [3]

B. Bug, vulnérabilité, attaque

Un comportement non attendu de la part d’un programme est un bug. C’est une erreur du développeur,qui peut accidentellement affecter l’utlisateur. Par contre, un bug qui peut être déclenché et contrôlé par

un tiers soulève des questions de sécurité car il pourrait être utilisé à dessein, potentiellement pour nuireà cet utilisateur.

Cette capacité pour un tiers, appelé l’attaquant, de contrôler en partie le comportement de l’applicationhors du cadre prévu par le développeur suffit pour parler de "vulnérabilité". Les proportions dans lesquellesle comportement pourra être modifié, et la nature du nouveau comportement, détermineront si l’on peutensuite parler d’une possible "attaque", ou non.

C. Cross Sites Scripting (XSS)

OWASP (Open Web Application Security Project) [1] donne une définition très générique des XSS :"Une XSS apparaît où une application web utilise une donnée fournie par un utilisateur dans la sortiequ’elle génère, sans correctement la valider ou l’encoder.". Je vais présenter ici quelques détails supplé-mentaires.

1) Une vulnérabilité par injection: .

L’absence de validation appropriée est exploitée par l’attaquant en utilisant des caractères spéciaux quiont un sens syntaxique en html ou javascript. Si ceux-ci ne sont pas "désactivés", il peut alors modifierlocalement la structure du document afin qu’une partie de ce qu’il a fourni soit interprété comme unscript, donc évalué et exécuté.

Par exemple, si à la requête :

example.com/?name=John

...le site répond :

Hello <b>John</b> !

...sans valider le contenu de la variable "name", alors la réponse à la requête :

example.com/?name=</b><script>alert(’XSS’)</script>

...sera :

Hello <b></b><script>alert(’XSS’)</script> !

Où "alert(’XSS’)" sera considéré comme du code javascript, et exécuté, ici faisant s’ouvrir une fenêtrede dialogue.

2) Trois types de XSS: .

1) Reflected : le paramètre contrôlé par l’attaquant est présent dans la requête, et se retrouvedirectement dans la réponse du serveur à cette requête malicieuse spécifique (cf exemple ci-dessus).

2) Stored : le paramètre contrôlé par l’attaquant est stocké par le serveur, et se retrouve dans laréponse du serveur à des requêtes légitimes.

3) DOM-based : le paramètre contrôlé par l’attaquant est manipulé par du javascript légitime de lapage web et se retrouve inséré dans le Document Object Model (DOM), ou directement évalué.

Comme nous le verrons plus tard, les filtres XSS s’attaquent aux XSS de type Reflected, et seulementà certaines DOM-based qui se comportent de manière similaire. Ce sont celles désignées par le terme"XSS" dans la suite de ce document.

3) Exploitation: .

Exploiter une XSS nécessite de créer le code que l’on veut faire exécuter à ses victimes, et decomposer un lien pointant sur la vulnérabilité, et déclenchant l’exécution du code. Il faut ensuite fairecharger ce lien à la victime, les moyens sont multiples : le lui envoyer ou le mettre comme source d’uneiframe chargée lorsque la victime visite un site créé par l’attaquant, pour citer les plus courants.

La figure 2 illustre un exemple d’attaque par XSS, et représente les échanges HTTP successifs entrele navigateur de la victime, le site de l’attaquant, et le site vulnérable. La seule action de la victimeest de demander le chargement de la page présente sur le site de l’attaquant. Son navigateur envoieune requête au site "attaquant.com", à laquelle le site de l’attaquant répond par une page contenantune balise "iframe". Lors du chargement de cette page par le navigateur de la victime, une requêteest automatiquement envoyée par le navigateur à la source de l’iframe. Cette requête arrive donc sur"target.com", avec en paramètre une chaîne de caractères choisie par l’attaquant. La vulnérabilité XSSprésente sur le site vulnérable lui fait intégrer cette chaîne de caractères dans la réponse, et puisqu’elledéfinit ici une balise "script", le navigateur va en exécuter la source. Le code javascript présent dans"evil.js" s’exécute alors dans le contexte de "target.com".

FIGURE 2. Exemple d’une XSS Reflected, servie par l’attaquant à l’aide d’une iframe. Le résultat est que la victime exécute lescript "evil.js", défini par l’attaquant, et ce dans le contexte de "target.com", alors qu’il ne faisait que naviguer "attaquant.com".

4) Risque associé: .

Une attaque XSS réussie aboutit à l’exécution du code créé par l’attaquant, dans le navigateur de lavictime, donc dans son contexte, avec sa session. Les possibilités sont multiples également : effectuern’importe quelle action disponible sur le site web ciblé au nom de la victime, récupérer n’importe quelleinformation privée de l’utilisateur sur ce site, mais aussi récupérer son mot de passe ou l’ajouter à unréseau d’ordinateurs partiellement sous le contrôle d’un même attaquant (botnet) [6].

D. Filtres XSS

Plusieurs implémentations existent, d’âges et de conceptions différentes, dont les spécificités, détailset avantages comparés seront décrits dans la présentation de l’état de l’art. Je vais présenter ici les grandeslignes du fonctionnement des plus modernes.

Pour détecter si une tentative d’attaque XSS est en cours pour une requête donnée, ces filtres reposentsur l’analyse de ses paramètres, comparés avec sa réponse. Si une correspondance est détectée, le filtres’assure de "neutraliser" la chaîne de caractères en question au sein de la réponse.

Il est important de réaliser que le filtre étant situé dans le navigateur, côté client, il n’a pas connaissancedu comportement légitime de l’application à laquelle il fait face. La méthode présentée ci-dessus luipermet de soupçonner raisonablement qu’une tentative d’attaque est en cours, mais rien ne lui permet des’apercevoir si une correspondance entre les paramètres et la réponse est une coincidence et ne devraitpas solliciter de "neutralisation". Il en découle l’existence nécessaire de faux positifs.

E. AntiXSS

Du point de vue de l’application web, le blocage d’une exécution par le filtre est perçue comme unbug : un comportement non attendu.

Ce bug peut être volontairement provoqué par un attaquant, puisque le comportement du filtre dépendde paramètres contrôlables eux-mêmes par l’attaquant : de manière similaire à une XSS, en créant unlien qui contienne, en paramètre, un script, mais ici un script légitime de la page ciblée. Même si laprésence du script dans la requête n’est pour rien dans sa présence dans la réponse, le filtre se déclenche,et neutralise ce script pourtant légitime.

C’est une vulnérabilité qui peut se transformer en attaque envers l’utilisateur si l’exécution de cescript était "critique", terme qui reste à définir et le sera plus tard dans ce document.

"AntiXSS" est le nom que j’ai choisi pour qualifier de telles attaques. Leur description et explorationen détail sera l’objet de la partie V.

III. ANALYSE DE LA PROBLÉMATIQUE ET CAHIER DES CHARGES

L’audit de la sécurité d’une application web est aujourd’hui effectué en analysant ses comportements,tels qu’ils y sont implémentés. Avec l’ajout d’un filtre XSS dans le navigateur et dans le cas d’un fauxpositif, le comportement effectif de l’application, telle qu’elle est chargée par le navigateur, n’est passtrictement identique à son comportement tel qu’il a été pensé par le développeur, et implémenté.

A. Problématique

La problématique étudiée est la suivante : déterminer l’impact sur la sécurité que peut avoir lecomportement des filtres face à des faux positifs.

Cette problématique se découpe en plusieurs questions, auxquelles il faudra répondre afin de déter-miner précisémment si le filtre introduit un risque, et si ce risque est suffisant pour pouvoir parler depotentielles "attaques AntiXSS".

Comment un attaquant peut-il en pratique provoquer un faux positif du filtre, et donc un "bug" dansl’application ? Dans quelle mesure peut-il contrôler ce "bug" ? Y a-t-il des contextes dans lesquels soneffet justifie de parler d’attaque ? Ces contextes correspondent-ils à des cas réels ?

B. Cahier des charges

1) Etudier les détails du comportement d’un filtre et les moyens de le contrôler: .

Le prémice d’une AntiXSS est un faux positif provoqué par l’attaquant. La première étape sera doncde déterminer précisément les moyens par lesquels cet attaquant pourra les provoquer et dans quellemesure il peut donc manipuler l’action du filtre.

2) Concevoir et illustrer des contextes dans lesquels on peut parler d’attaque: .

L’attaquant pouvant contrôler les faux positifs, il faut ensuite identifier les facteurs contextuels quidéterminent si les modifications du comportement de l’application, provoqués par le filtre en réaction aufaux positif, constituent une menace pour l’utilisateur.

Une fois ces facteurs identifiés, il sera utile d’utiliser cette connaissance pour construire des applica-tions où sont présents de tels contextes, et d’y présenter une démonstration d’attaque AntiXSS.

3) Développer un outil pour assister à la recherche de tels contextes: .

Une fois ces contextes caractérisés, on a la possibilité d’auditer des applications réelles afin de détectersi elles présentent un tel contexte. Il faudra donc développer un outil permettant d’assister l’auditeur danscette tâche.

4) Utiliser cet outil pour déterminer l’existence de ces contextes: .

Selon l’avancement du PFE, une fois cet outil développé, il est envisagé de l’utiliser pour évaluer si detels contextes se rencontrent souvent en pratique, ou non, dans des applications réelles. Cela permettraitde percevoir la mesure du risque auquel sont exposés les utilisateurs du fait des AntiXSS.

IV. ETAT DE L’ART

Je vais présenter les différents filtres XSS côté client existants dans le navigateur, de manière chrono-logique, en mettant à chaque fois l’accent sur les avantages et inconvénients. Je ne vais pas présenter lesattaques visant à contourner ces filtres, puisqu’elles ne sont pas pertinentes dans ce travail, où je chercheà exploiter des faux positifs et non des faux négatifs. Ces attaques pourront tout de même être évoquéespour expliquer les raisons qui ont motivé l’évolution des filtres.

A. NoScript

NoScript [7] est un plugin Firefox. Entre autres fonctionnalités, ce fût le premier qui introduisit, en2007, la notion de filtre XSS côté client.

A l’aide de blacklists et d’expressions régulières, il examine les paramètres des requêtes HTTP sor-tantes pour identifier celles qui pourraient être potentiellement malicieuses (celles qui semblent chercherà injecter un script dans la page ciblée).

Les paramètres suspects de la requête sont directement modifiés avant que la requête soit envoyée,de manière à les rendre inoffensifs. Le fonctionnement est illustré dans la figure 3.

FIGURE 3. Fonctionnement du filtre XSS de NoScript

Par exemple, si je tente d’envoyer une requête depuis un navigateur équipé de NoScript, avec enparamètre une chaîne de caractères représentant une balise script valide :

localhost/?p=<script>alert()</script>

la requête reçue par mon serveur, après la modification effectuée par NoScript est :

localhost/?p=/ script>ALERT /script>

Même si une vulnérabilité XSS était présente sur cette page, le paramètre réfléchi ne correspond plusà une balise script valide, et est donc inoffensif.

L’approche de NoScript peut définitivement être qualifiée d’agressive, puisqu’elle banit tout simple-ment une liste de mots-clés qui deviennent interdits dans tout paramètre HTTP.

Cette approche est imposée par la nature de NoScript, qui en tant que plugin n’a le contrôle que d’unepartie des comportements du navigateur, et ne pourrait notamment pas accéder au contenu des réponsesaux requêtes. Ne sachant si la présence de ces mots-clés se retrouve dans la réponse, et encore moinss’ils mènent finalement à une exécution de code, NoScript envisage le pire et assume que c’est le cas.

Une étude quantitative du taux de faux positifs des principaux filtres XSS [8] confirme effectivementque ceux-ci sont les plus fréquents pour NoScript.

Enfin, NoScript est encore à ce jour le seul filtre XSS disponible pour les utilisateurs de Firefox.L’ajout d’un filtre plus moderne, intégré au navigateur, est en cours de travail, et celui-ci devrait s’inspirerdu design du filtre XSSAuditor [9].

B. Internet Explorer

Microsoft introduisit son propre filtre XSS pour Internet Explorer 8 (IE8) [10]. Contrairement àNoScript, qui est limité dans l’espace utilisateur du navigateur, celui-ci réside entre le navigateur et lacouche réseau : il voit passer les requêtes mais aussi les réponses, et peut modifier celles-ci avant de lesfaire passer au reste du navigateur pour les traiter et les afficher. Cela lui permet de mettre en place lefonctionnement suivant [11] (illustré dans la figure 4) :

a) Détection de paramètres suspects: à l’aide d’expressions régulières.

b) Génération de signatures pour ces paramètres: sous la forme d’une expression régulière.

c) Neutralisation dans la réponse des paramètres réfléchis: identifiés à l’aide de leur signature,ils sont directement modifiés. Par exemple :

Paramètre de la requête:<script>alert(0)</script>.

Retrouvé dans le code source:<sc#ipt>alert(0)</script>.

FIGURE 4. Fonctionnement du filtre XSS de Internet Explorer

Comparé à celui de NoScript, ce fonctionnement permet de réduire grandement la probabilité de fauxpositifs (le filtre ne se déclenchera pas si les paramètres, même suspects, sont présents dans la requêtemais pas dans la réponse), et leur impact (seule la réponse telle qu’elle est chargée par le navigateur estmodifiée, pas la requête elle-même).

Les principaux problèmes qui persistent sont liés à l’utilisation d’expressions régulières pour :1) évaluer les paramètres à considérer comme "dangereux"2) modifier directement la réponse, le code source

En effet, le parsing du code source par le navigateur est complexe et souvent difficile à prédire. Encoreplus difficile à reproduire à l’aide d’expressions régulières. Des erreurs sont vite arrivées...

C. La faille Universal XSS (UXSS) de IE8

La première implémentation du filtre de IE8 fournit une démonstration impressionante du risque àmodifier directement le contenu de la réponse.

Parmi les opérations utilisées pour neutraliser une tentative d’injection, se trouvait le remplacementdu caractère "=" par "#". Cette opération était en fait très dangereuse, car, contrôlée par un attaquant àl’aide d’un faux positif, elle pouvait être utilisée pour faire diverger le parsing du code source par leparser HTML, entraînant la génération d’un DOM différent.

Exemple :

Pour une application où un paramètre est réfléchi ainsi:

<img alt="[[paramètre_réfléchi]]" src="x.png" >

Un paramètre inoffensif, qui n’exploite pas une XSS, et ne déclenche

donc pas le filtre, pourrait être:

x onload=alert(0) x

Menant à la génération du code source suivant (ou il n’y a pas d’exécution):

<img alt="x onload=alert(0) x" src="x.png" >

Par contre, quand, à l’aide d’un faux positif contrôlé, l’attaquant pousse lefiltre à transformer"alt=" par un "alt#":

<img alt#"x onload=alert(0) x" src="x.png" >

Les chaînes ’alt#"x’ et ’x"’ sont invalides en HTML, et ignorées par le parseur,qui génère un DOM équivalent à celui de:

<img onload=alert(0) src="x.png" >

Où "alert(0)", chaîne contrôlée par l’attaquant, est évaluée et exécutée.

Le fait que cette attaque permette à l’attaquant de créer ses propres XSS pour une page qui n’étaitpas vulnérable à la base est ce qui lui a valu ce nom de Universal XSS [12].

D. XSSAuditor

XSSAuditor fut conçu et initialement implémenté dans le cadre d’un travail sur les limitations etdéfauts des filtres antérieurs, notamment leur usage d’expressions régulières [13].

Une implémentation a été integrée à WebKit [14], qui est un Web Browser Engine. WebKit (oudans certains cas, une version "forkée" par le projet Chromium, du nom de Blink [15]) est au coeur denavigateurs tels que Chromium [17], Chrome [16], Safari [18] ou plus récemment Opéra [19].

1) En finir avec les expressions régulières: .

Je vais présenter ici en quoi l’usage d’expressions régulières présente à la fois un risque et unecomplication.

A priori, tenter de parser du HTML à l’aide d’expressions régulières est déjà très fortement déconseillé[20]. En effet, un document XML est structuré, et en HTML une même chaîne de caractères peut avoirdes sens différents en fonction de son contexte. En guise d’illustration, dans l’exemple suivant :

<textarea><script>alert()</script>

</textarea>

" <script>alert()</script>" ne sera pas interprété comme une balise script, mais comme du simpletexte, contenu dans la balise " <textarea>".

Mais surtout, dans ce contexte, il faut considérer que l’important n’est pas le contenu de la chainede caractère, mais plutôt la manière dont elle sera interprétée par le navigateur. Or, dans une optiquede robustesse et permissivité, les navigateurs tendent à faire leur maximum pour interpréter du HTMLmême invalide, et en extraire un DOM tout de même (une illustration de ce comportement est utilisédans l’attaque UXSS).

Cela veut dire que l’expression régulière d’un filtre devrait être capable de parser non seulementdu HTML, mais également de reproduire toutes les corrections (peu prédictibles et non documentées)appliquées ensuite par le parseur HTML.

Enfin, les navigateurs supportent plusieurs encodages, permettant à un même caractère d’être repré-senté de nombreuses façons différentes, et chacun nécessitant donc d’être pris en compte dans l’expressionrégulière. Le filtre de IE8 pouvait par exemple être complètement contourné simplement en utilisant UTF-7.

FIGURE 5. Réponse HTTP (à gauche) face au résultat en sortie du parser HTML (à droite) (schéma extrait de [13])

Dans la figure 5, on peut voir à gauche la réponse HTTP brute, telle qu’elle est reçue, et à droite,ce qu’elle représente une fois le HTML parsé : le DOM correspondant. Les caractères en rouge dans laréponse sont responsables des éléments en rouge dans le DOM.

Cette figure illustre combien il est plus simple et plus fiable de repérer les points d’entrées au moteurjavascript en sortie du parseur HTML, où la nature et la portée de chaque élément y sont clairementidentifiée, plutôt qu’au moyen d’une expression régulière directement dans la réponse HTTP.

En pratique, dans l’exemple fourni en IV-A à propos de NoScript, la requête "localhost/ ?<script>alert()</script> " a été motifiée car matchée par l’expression régulière suivante (raccourcie ici, mais longue de3815 caractères) :

<[^\w<>]*(?:[^<>"’\s]*:)?[^\w<>]*(?:\W*s\W*c\W*r\W*i\W*p\W*t|\W*f ...

Le filtre de IE8, lui, utilisait pas moins de 22 expressions régulières, certaines aussi longues quel’exemple de NoScript, pour identifier un paramètre comme "suspect" [12].

Celles-ci sont finalement aussi risquées à bien concevoir, que compliquées à maintenir et faire évoluer.

En conclusion, un filtre reposant sur des expressions régulières pour détecter des injections estfortement susceptible d’être contournable, et tous les filtres connus en ont fait l’expérience [21].

2) Limiter les effets de bord d’un faux positif: .

Avec NoScript, un faux positif provoque l’altération de la requête, ce qui peut avoir des répercussionsinattendues. Avec le filtre de Internet Explorer, c’est la réponse qui est modifiée, avec également desrépercussions potentielles, dont l’attaque UXSS est un exemple impressionant.

Dans chacun de ces cas, alors que le but n’est que de contrer une exécution malveillante de script,c’est un élément extérieur qui en subit les effets négatifs.

Dans l’idéal, un filtre XSS ne devrait ni avoir à, ni pouvoir, modifier les requêtes ou le DOM. Ildevrait pouvoir se contenter de bloquer l’exécution d’un script identifié comme malveillant.

3) Design et architecture: .

C’est sur la base des deux points précédents que XSSAuditor est proposé comme évolution. Les autresfacteurs importants dans la conception d’un filtre XSS restent valables également, notamment avoir unimpact minimal sur les performances du navigateur et ne pas sacrifier en usabilité du navigateur.

Le fonctionnement de XSSAuditor est présenté dans la figure 6, et sa différence fondamentaleavec le filtre de Internet Explorer est d’être intégré au Browser Engine, plutôt que rajouté par-dessus.Cette position lui permet d’agir directement entre le parseur HTML et le moteur javascript, et d’éviterl’utilisation d’expressions régulières.

Pour déterminer si un code demandant à être exécuté est suspect, il le compare avec les paramètresde la requête. S’il y a une correspondance, le code est considéré comme étant le résultat d’une tentatived’injection, et neutralisé en étant remplacé par une instruction n’ayant aucun effet :

void(0)

Cette architecture répond également au besoin évoqué de limiter les effets de bord d’un faux positif.Ici, c’est uniquement l’exécution du code suspect qui est affectée, et rien d’autre.

FIGURE 6. Fonctionnement de XSSAuditor

Limiter les effets de bord correspond à un besoin de sécurité comme on l’a vu, mais aussi à unevolonté claire de la part des développeurs de ne pas sacrifier l’usabilité du navigateur à la sécurité. Ilscherchent donc à rendre le blocage d’une potentielle injection aussi silencieux que possible, et à maintenirau maximum le bon fonctionnement de la page. C’est le fait que la page soit autorisée à fonctionnermême partiellement qui sera utilisé dans le cadre d’une attaque par AntiXSS.

De la même façon, ils se montrent réticents à trop augmenter la sensibilité de leur filtre. Sollicités àpropos des méthodes de contournement connues, ils répondent : "We are aware of a few ways to bypassthe filter, but, on balance, we think that the filter is providing enough benefit to enable it by default"[22].

En effet, ce serait à eux d’assumer les conséquences d’un filtre qui bloquerait complètement un tropgrand nombre de pages web, et ce, dans un effort pour n’offrir qu’un palliatif (un filtre côté client nepourra pas tout prévenir) à un défaut de sécurité qui n’est pas le leur (mais celui du site web).

4) Le filtre étudié au cours de ce travail: .

Bien qu’imparfait, XSSAuditor reprèsente ce qui se fait de plus moderne en terme de filtres XSS côtéclient : "Up to now, the XSS Auditor constitutes the state-of-the art in client-side XSS mitigation" [23].Cela est également confirmé par la volonté de Firefox de s’en inspirer pour le sien, à venir.

Cela considéré, avec également le fait qu’il soit présent dans un grand nombre des principauxnavigateurs, justifie que ce soit le filtre sur lequel j’ai décidé de concentrer mon travail.

V. ETUDE THÉORIQUE ET APPLIQUÉE D’UNE ANTIXSS

Dans cette partie, je vais présenter ma contribution sur la définition des AntiXSS, l’étude de celles-ciet des techniques associées.

Bien que le concept d’AntiXSS ne soit pas restrictif et pourrait être étendu à d’autres filtres, ayantconcentré mon travail exclusivement sur XSSAuditor (comme expliqué dans l’état de l’art), je ne décriraiici que les capacités, limites et prérequis pour des AntiXSS envers XSSAuditor, et c’est ce que je mettraiderrière le terme "AntiXSS".

L’attaquant possède la capacité de créer des liens qui, chargés dans un navigateur intégrant XSSAu-ditor, pousseront le filtre à désactiver un script donné. Nous étudierons ici dans quels cadres cela peutêtre problématique, profitable pour l’attaquant, et comment celui-ci s’y prendrait.

A. Scénario

Une attaque par AntiXSS se déroule dans un premier temps comme une attaque par XSS de typeReflected. L’attaquant :

1) crée un lien particulier2) y expose sa victime

Ensuite, contrairement aux XSS où du code ajouté par l’attaquant est exécuté, ici, c’est du code de lapage qui, lui, ne s’exécute pas.

Toute la difficultée est donc, pour l’attaquant, d’identifier du code de la page dont il pourra profiterde l’absence. Un tel code sera appelé "code critique".

B. Les codes critiques

Comme introduit précédemment, un "code critique" est un bout de code javascript présent dans lapage ciblée, et qui serait intéressant à désactiver (pour un attaquant).

Je vais ici présenter les caractéristiques que j’ai définies pour qu’un code soit "critique" dans le cadredes AntiXSS, et qui me permettront donc de l’évaluer comme tel.

1) Actif ou passif: .

-Passif : le code est exécuté automatiquement lors de la création de la page. Par exemple une librairiechargée, ou la création d’une interface utilisateur.

-Actif : le code est exécuté suite à une action de l’utilisateur. Par exemple le clic sur un bouton.

2) Discrétion: .

Puisque le bout de code recherché sera retiré de la page, il est important, pour que l’attaque ait unsens, que son absence ne bloque pas complètement le chargement de la page ou l’intègralité de sonfonctionnement.

Des exemples de codes peu discrets : génération ou modification d’une partie importante du DOM,donc de l’aspect visuel de la page, ou la déclaration de fonctions ou variables largement utilisées parl’application.

Des exemples de codes discrets : affectation ou modification de variables, appels de fonctions, etdéclarations de variables ou fonctions qui ne sont pas ou peu utilisés hors du bout de code.

Ce facteur n’est intéressant à considérer que dans le cas des codes passifs à priori.

3) Importance: .

Que peut-on attendre de la désactivation d’un bout de code ? Cela dépendra, mais pourra avoir delourdes conséquences dans le cas où le code en question est responsable de :

1) Un élément de la sécurité de l’application elle-même :a) la validation de paramètres utilisés par le javascript (menant donc à de potentielles XSS de

type DOM-based)b) une réécriture de liens, remplaçant "http" par "https" si le client a accedé à l’application via

du https (dans cet exemple, l’application ne voudrait alors pas abaisser le niveau de sécuritéglobal en faisant charger des ressources via HTTP, si le client peut le faire en HTTPS).

c) un dispositif de frame busting, pour lutter contre le clickjacking (ce cas est présenté plus endétail dans la partie V-B4).

2) Une fonctionnalité de l’application attendue par l’utilisateur, qui le met dans une situation difficilesi elle venait à être "sautée" :a) de la cryptographie : l’étape de chiffrement, ou d’initialisation de l’aléab) la sauvegarde automatique d’un projetc) une étape de confirmation avant une suppressiond) le paramètrage d’options de confidentialité ou de vie privée.

Il apparaît clairement combien cette notion d’"important" sera spécifique à une application donnée, ettout particulièrement l’importance d’une fonctionnalité. Du côté des éléments de sécurité cependant, il ya plus de chances de voir le même dispositif utilisé par plusieurs applications.

4) Un exemple concret de code critique idéal: .

Le clickjacking est une attaque où l’attaquant crée une page web, dans laquelle il charge une pageciblée à l’aide d’une iframe, et la cache ou camoufle derrière des éléments de sa propre page. Ainsi, il peutpiéger un utilisateur, faisant croire à sa victime qu’elle exécute des actions anodines sur "attaquant.com"alors qu’en même temps elle en exécute d’autres sur "cible.com".

Une protection historique contre le clickjacking était d’intégrer le bout de code suivant dans la pageà protéger, afin de lui permettre de "casser" une iframe dans laquelle elle serait affichée :

<script>if (parent.frames.length > 0) {

top.location.replace(document.location);}

</script>

Un tel code est parfaitement Discret : un simple appel de fonction, Important : protège contre leclickjacking, et en même temps générique : utilisé par "tout" site web désirant se protéger. C’est le codecritique idéal pour une AntiXSS.

Bien sûr, ces méthodes pour se protéger du clickjacking n’ont jamais été satisfaisantes, et ont étéremplacées depuis [24].

C. Contrôler un faux positif avec XSSAuditor

Une fois un code critique identifié, pour mener une attaque par AntiXSS, il faut pouvoir le désactiveren lui faisant déclencher un faux positif du filtre.

1) Les points d’entrée du moteur javascript: . De par sa conception, XSSAuditor examine et peutdésactiver tout ce qui mène au moteur javascript. Les moyens les plus couramment utilisés par lesdéveloppeurs pour définir du code sont illustrés ici :

1) Les scripts, "inline" (le code est directement présent dans le corps de la balise ) ou externes (lecode est présent dans un fichier qui est donc chargé) :Inline :

<script>alert()</script>

Externe :<script src="external.js"></script>

2) Les attributs liés à un évènement de la page. Le code s’exécute lorsque l’évènement se déclenche.Il y en a un pour chaque évènement [25] :Syntaxe générale :

on[[event]]

Exemple ("alert()" déclenche sur un clique du bouton) :<button onclick="alert()">button</button>

3) Les URL dont le protocole est "javascript" (le code est exécuté quand l’adresse est chargée parle navigateur) :Lorsque l’utilisateur clique sur le lien :

<a href="javascript:alert()">link</a>

Lorsque le navigateur charge l’iframe (automatiquement) :<iframe src="javascript:alert()"></iframe>

2) Provoquer un faux positif de XSSAuditor: Pour prévenir une exécution, avant de passer uneinstruction au moteur javascript, XSSAuditor la compare avec les paramètres de la requête.

En ne prenant en compte que les facteurs qui nous intéressent, une URL peut être formatée ainsi :

http://site.com/page.html?param_1=value_1&param_2=value_2#anchor

D’après la conception de XSSAuditor, on doit donc pouvoir lui faire comparer toute tentative d’exé-cution avec "faux_positif" à l’aide d’une requête de la forme :

http://site.com/page.html?fake_param=faux_positif

D’après mes expérimentations, il s’avère que dans sa version actuelle il se déclenche aussi pour :

http://site.com/page.html?faux_positifhttp://site.com/page.html#faux_positif

La version avec l’ancre "#" présente un avantage : le contenu de l’ancre est en fait uniquement àdestination du navigateur (par exemple pour indiquer quelle partie de la page centrer). Elle ne fait enréalité pas partie de la requête HTTP, et n’est jamais envoyée au serveur.

Déclencher un faux positif depuis l’ancre plutôt que depuis un paramètre évite d’envoyer au serveurweb de la page ciblée un paramètre factice qui pourrait réveler notre attaque.

Si l’on veut déclencher plusieurs faux positifs pour plusieurs codes différents, il suffit de les séparercomme l’on séparerait deux paramètres :

http://site.com/page.html#faux_positif_1&faux_positif_2

3) Cibler un code critique: .

XSSAuditor implémente une politique qualifiée "Whole Script Filtering Policy" [8] :1) le filtre se déclenche si un script correspond intégralement avec un paramètre.2) quand le filtre se déclenche, l’intégralité du script est bloquée.En conséquence du premier point, il faudra soigneusement inclure le code à désactiver exactement

tel qu’il est présent dans la page. Notamment, commentaires, espaces, et retours à la ligne inclus. Afinde pouvoir insérer des caractères tels que des retours à la ligne dans une URL, il faudra les encoder.

En conséquence du second point, on ne pourra choisir de cibler quelques lignes au sein d’un codejavascript. Le code critique sera donc nécessairement un élément de la page dans son intégralité.

D. Remarques et principales difficultés attendues

La politique Whole Script Filtering rend le facteur Discrétion d’un code critique particulièrementimportant. Plus le code d’une page est rassemblé au même endroit (même script externe ou inline), plusil y a de chances que désactiver cette source fasse "planter" la page dans des proportions qui ne profitentplus à l’attaquant. Une AntiXSS profitera au contraire d’avoir le code de la page nettement séparé enmodules isolés les uns des autres (désactivables indépendamment).

Cela met en avant les attributs HTML d’évènements (onclick, etc.) comme sources de code critique :ils servent généralement à accomplir une action précise, et sont donc très discrets.

Plusieurs pratiques, associées au contexte technologique actuel du web, vont à l’encontre de cespoints tout juste établis, et sont présentés ci-dessous. Toutefois, il faut noter que si ces pratiques sontconsidérées comme "bonnes pratiques" aujourd’hui et sont préconisées, elles ne sont ni suivies de manièresystématique, ni ne motiveront à modifier des applications développées antérieurement.

1) La concaténation des fichiers javascript: .

Pour des questions de performances, afin de ne pas multiplier les requêtes que le navigateur doiteffectuer pour rassembler toutes les ressources d’une page, il est de bonne pratique aujourd’hui deconcaténer ses fichiers javascript [26]. Evidemment, cela n’est pas pour autant systématique.

La toute nouvelle version de HTTP, 2.0, n’encouragera plus la concaténation des fichiers [27], etpourrait donc involontairement augmenter les possibilités d’AntiXSS . Il est cependant difficile d’évaluerquand HTTP 2.0 sera suffisamment déployé pour voir une évolution des habitudes, et la disparition decette pratique.

2) Enregistrement des évènements depuis le javascript: .

Les attributs HTML d’évènements (onclick, etc.) présentent un grand interêt pour trouver des codescritiques. Cependant, ce n’est pas le seul moyen d’associer des instructions à un évènement pour unélément, et ce n’est pas non plus le plus moderne.

L’alternative est de le faire depuis du code javascript. Par exemple :

Tel que spécifié par le W3C :$(’button’).addEventListener(’click’,stuff,false) ;

A l’aide d’une librairie populaire :$(’button’).on(’click’,stuff) ;

Du fait de l’existence et des avantages de ces méthodes, les évènements sont souvent enregistrésdirectement dans le code javascript, au détriment de ces attributs HTML si pratiques pour les AntiXSS.

VI. RÉALISATIONS

J’ai présenté dans la partie V la théorie et les applications de cette nouvelle attaque que je propose.Je vais présenter ici les productions concrètes que j’ai pu réaliser.

A. Proofs of concept

Cette partie est consacrée à des exemples de contextes dans lesquels une AntiXSS peut prendre placeavec des conséquences graves. Les pages HTML que je vous présente sont des cas d’école que j’aiconçus pour illustrer une application et un scénario. Leur fonctionnements peut être reproduits dans descas réels.

Pour chaque proof of concept, je décrirai le scénario que j’ai choisi, et me placerai du côté del’attaquant pour discuter des propriétés du code critique de l’application selon les critères que j’ai proposésdans la partie V-B. Je fournirai ensuite l’attaque par AntiXSS que peut lancer l’attaquant, et décrirai sesconséquences.

Egalement, je proposerai une méthode avec laquelle la même application auraît pu être concue demanière à ne pas pouvoir être attaquée ainsi. Il est important de réaliser que du point de vue fonctionnel del’application, les alternatives que je vais proposer ne présentent aucune différence, et seraient équivalentesen termes de sécurité comme d’usage si l’on ne prenait pas en compte XSSAuditor et les AntiXSS.

1) Code critique sur une fonctionnalité, depuis un attribut HTML: .

Ce premier proof of concept présente un bouton qui pourrait être inclu à une page de création decontenu d’un réseau social. Lorsque l’utilisateur crée par exemple un album photo, ou un évènement,ceux-ci serait par défaut publique et ce bouton permettrait de le passer en accès restreint, privé.

createpage.html :

<button onclick="makeThisPagePrivate()">Make the page private so that onlyyou and your friends can view it.

</button>

La fonction "makeThisPagePrivate" est supposée définie ailleurs, et ses détails ne nous intéressentpas : elle s’occupe simplement d’appliquer le changement d’option.

Le code critique ici est (évidemment) :

makeThisPagePrivate()

Il est :1) Actif : exécuté sur une action de l’utilisateur (click)2) Important : il appelle la méthode appliquant la modification réclamée par l’utilisateur3) Discret : d’un intérêt généralement minime pour les codes actifs, on souhaite ici que l’utilisateur

poursuive son utilisation de la page même après le "bug" provoqué par l’AntiXSS, et publie soncontenu. On peut légitimement supposer que l’absence d’appel à la fonction "makeThisPagePri-vate" ne causera pas d’effets de bord empêchant la poursuite de l’utilisation.

L’attaque AntiXSS correspondante est :

createpage.html#<button onclick="makeThisPagePrivate()">

Depuis la page chargée pour cette URL, l’action associée au click du bouton est désactivée.

En conséquence d’une telle attaque, l’utilisateur aura beau avoir cliqué sur le bouton pour passer enmode privé, la page qu’il va créer sera publique.

Une mesure qui aurait permis au développeur de se protéger aurait été de d’associer l’appel de "ma-keThisPagePrivate" à l’évènement "click" depuis du code javascript présent dans un fichier rassemblantl’ensemble du code nécessaire au bon fonctionnement de la page (comme évoqué en V-D2).

2) Code critique de sécurité, depuis un script inline: .

Ce scénario présente une page web permettant d’effectuer de simples calculs.

calc.html

<script>unsafeEval = eval; // unsafeEval réfère désormais à la

// fonction standart "eval".function eval(operation){ // Reféfinit la fonction "eval" :

if ( /^[\d\+\-\*\/]+$/ // Si le paramètre ne comprend que des.test(operation) ) // caracteres parmi les suivants:

// 0-9, +, -, *, /{ unsafeEval(operation) }// On peut alors l’evaluer sans risque

} // en la passant à unsafeEval</script>

<button onclick="input = document.location.hash.substr(1); // Recupere l’ancre de l’URL,eval(input); // et en effectue une évaluation sécurisée

">Compute

</button>

Pour utiliser ce calculateur, l’utilisateur indique le calcul qu’il veut effectuer en le passant dansl’ancre :

calc.html#1+2-3*4/5

Il peut ensuite cliquer sur le bouton "Compute" pour que son calcul soit évalué.

Le développeur de cette application est conscient qu’exécuter la fonction "eval", qui permet d’inter-prêter une chaîne de caractères comme du code javascript et de l’exécuter, sur des données fournies parl’utilisateur, expose son application à des attaques par XSS (de type DOM-based).

Il prend donc soin d’utiliser une expression régulière pour vérifier que la chaîne fournie par l’utilisateurcomprend uniquement des caractères autorisés, suffisants pour effectuer des calculs, mais ne permettantpas d’exécuter du code arbitraire.

La validation de cette chaîne de caractère se fait dans la redéfinition de la fonction "eval".

Le code critique ici est donc la redéfinition de cette fonction "eval" :

unsafeEval = eval;function eval(operation){if ( /^[\d\+\-\*\/]+$/.test(operation) ){ unsafeEval(operation) }}

Pour des raisons de simplicité par la suite, j’en ai retiré les commentaires et retours à la ligne.Cependant, s’ils sont bien présents dans le code source de la page, il faudra encoder le code critiquepour l’utiliser dans une AntiXSS fonctionnelle (comme évoqué dans la partie V-C3).

Ce code critique est :1) Passif : exécuté automatiquement au chargement de la page2) Important : il redéfinit "eval" de manière à la restreinte à l’évaluation de calculs3) Discret : si "eval" n’est pas redéfinie, un appel à "eval" exécutera la fonction standart "eval" à la

place, sans lever d’exception.L’attaque AntiXSS correspondante est :

calc.html#<script>unsafeEval =eval;function eval(operation){if ( /^[\d\+\-\*\/]+$/.test(operation)){ unsafeEval(operation) }}</script>

Depuis la page chargée pour cette URL, "eval" n’est pas redéfinie, et ne valide pas la chaîne decaractères pour s’assurer qu’elle soit inoffensive.

Il est donc possible de construire une attaque AntiXSS mettant à jour une vulnérabilité XSS, etl’exploitant pour exécuter du code arbitraire :

calc.html#alert(’XSS’)//&<script>unsafeEval =eval;function eval(operation){if ( /^[\d\+\-\*\/]+$/.test(operation)){ unsafeEval(operation) }}</script>

Le résultat du chargement de la page depuis cette URL est que cliquer sur le bouton "Compute"provoque l’ouverture d’une boîte de dialogue annonçant "XSS". En effet, le contenu de l’ancre est :

alert(’XSS’)//&<script>unsafeEval = eval;function eval(operation){if( /^[\d\+\-\*\/]+$/.test(operation) ){ unsafeEval(operation) }}</script>

Il est évalué selon la syntaxe de javascript, dans laquelle "//" indique un commentaire, permettantd’ignorer toute la partie qui a servi au déclenchement de l’AntiXSS, et est désormais inutile. Le codeexécuté est donc équivalent à :

alert(’XSS’)

En conclusion, l’utilisation d’une AntiXSS a permit de créer une vulnérabilité XSS (DOM-based)dans une page qui n’en possédait pas à l’origine.

Une mesure qui aurait permis au développeur de se protéger aurait été de ne pas redéfinir "eval",mais plutôt de définir nouvelle fonction sous un autre nom, et d’appeler celle-ci. Désactiver la définitionde cette fonction aurait mené à une erreur lors de son appel. Cependant, son choix, même étonnant, n’estpas interdit pour autant et ne devrait certainement pas avoir des conséquences telles que celles que l’ondémontre ici.

3) Code critique seulement partiellement Discret: .

Ce dernier proof of concept est à la fois plus réaliste, et plus subtil que les précédents. Il met enscène une application web dans laquelle l’utilisateur dispose d’un éditeur de texte (qui pourrait êtrecollaboratif), et peut l’utiliser pour développer un programme par exemple.

La fonctionnalité centrale de CodeCertifier.com est de pouvoir générer une signature cryptographiquedu code que l’on a produit, afin de pouvoir le partager avec d’autres en garantissant qu’il n’est pasmodifié par un tiers.

Le développeur de CodeCertifier, soigneux, a appliqué un design pattern recommandé de javascript,avec une classe centrale qui peut être complétée de modules isolés. L’organisation des fichiers del’application est la suivante :

CodeCertifier.js : où se trouve la déclaration de la classe principale.

function CodeCertifier() {}

CodeCertifier-crypto.js : où sont définies les fonctions de cryptographie. Bien sûr, ici "btoa" (base64)est utilisée, qui n’a aucune valeur cryptographique mais simulera une fonction de hash.

CodeCertifier.prototype.sign = function(str) {return btoa(str)

};

CodeCertifier-utils.js : où sont définies les méthodes utilisées pour interagir avec la page.

CodeCertifier.prototype.watch = function(node){var that = this; // Conserver la référence à CodeCertifier.$(node).on(’keyup’,function(){// Sur l’évènement "keyup" de l’élément

// à surveiller,that.code = $(node).val(); // copier le contenu de cet élément dans

}) // un attribut "code" de CodeCertifier.};

codecertifier.html : l’application elle même, qui charge les dépendances externes, contient une zonede texte et un bouton, et finalement un script inline pour lancer l’application.

<script src="jquery.js"></script> // Librairie pour manipuler le DOM.<script src="CodeCertifier.js"></script> // Définition de la classe principale.<script src="CodeCertifier-crypto.js"></script>// Extension crypto de la classe

// principale.<script src="CodeCertifier-utils.js"></script> // Extension de la classe principale

// pour les interactions avec la page.

<textarea>Write here.</textarea> // La zone de texte.<button onclick="alert(CC.sign(CC.code))"> // Le bouton sur lequel cliquer pour

Generate a signature for this code // obtenir la signature du code.</button>

<script>var CC = new CodeCertifier(); // Instanciation de CodeCertifier.CC.watch("textarea"); // Indique à CodeCertifier de

// surveiller la zone de texte.</script>

Cette application est tout à fait rudimentaire mais fonctionnelle : elle affiche une signature différentepour des textes saisis différents.

Le code critique que je propose est celui contenu dans CodeCertifier-utils.js.

Il est :1) Passif : exécuté automatiquement au chargement de la page2) Important : il définit la méthode synchronisant la valeur de CC.code avec le contenu de la zone

de texte à signer3) Partiellement Discret : qu’il définisse cette méthode, et qu’il crée CC.code, sont deux points qui

limitent sa Discrétion.Ce code critique est intéressant puisqu’il semble à priori ne pas bien remplir les attentes d’un code

critique Discret. Je montrerai par la suite quelles particularités lui permettent d’être tout de mêmeutilisable.

L’attaque AntiXSS correspondante est :

codecertifier.html#<script src="CodeCertifier-utils.js"></script>

Depuis la page chargée pour cette URL, quoi que l’on mette dans la zone de texte, cliquer sur lebouton retournera "dW5kZWZpbmVk". Cette valeur est constante, puisque une fois "CodeCertifier-utils"désactivé, "watch" n’est pas définie, donc la valeur de CC.code n’est jamais modifiée.

En conséquence d’une telle attaque, l’utilisateur obtient une signature qui est invalide pour son code,et connue à l’avance par l’attaquant (car toujours identique). Selon l’usage auquel est voué ce code, lesconséquences peuvent être significatives.

Ce qui rend cet exemple particulier, ce sont les deux techniques utilisées ici de "bug contrôlé" :

1) la fonction "CC.watch" est appelée alors qu’elle n’est pas définie. Cela cause une erreur, et l’exé-cution s’interrompt. Mais au sein du bloc script inline où CC.watch est appelée, cette instructionest la dernière. L’exécution s’arrête donc bien, mais sans nuire à aucune autre instruction.

2) on utilise la valeur de "CC.code" sans l’avoir déclarée. En effet, si accéder à une variable nondéclarée soulève une exception et interrompt l’exécution, accéder à un attribut non défini d’un objetse contente de retourner l’élement "undefined". Ensuite, la gestion souple des types en javascriptnous permet d’utiliser cet objet "undefined" en lieu et place de notre code, par un casting implicitevers le string "undefined". C’est celui dont est finalement faite la signature.

Connaître le comportement de javascript dans de tels cas permet donc d’identifier de tels cas où mêmesi le code critique étudié (ici CodeCertifier-utils.js) n’est pas complètement Discret, il peut être utilisépour peu que les bugs induits n’impactent pas le bon déroulement de l’attaque.

Une mesure qui aurait permis au développeur de se protéger aurait été de concaténer toutes sesdépendances et de les charger depuis un même fichier. Cependant, s’il ignore la possibilitité d’une attaquepar AntiXSS, il n’a aucune raison de penser que cette action ait un quelconque impact sur la sécurité deson application.

B. AntiXSS-Auditor

AntiXSS-Auditor est l’outil que j’ai développé pour assister à la recherche de contextes dans lesquelsune AntiXSS serait une menace et pourrait conduire à une attaque. Un tel contexte dépend de la présenced’un "code critique", tel que défini dans la partie V-B.

1) Objectifs et fonctionnalités visées: .

Si l’objectif final de AntiXSS-Auditor est de fournir un moyen efficace de détecter des codes cri-tiques, l’objectif immédiat est surtout de les étudier et de caractériser la forme qu’ils prennent dans desapplications réelles.

La notion de code critique n’existe encore que dans la forme théorique selon laquelle je l’ai définie,qui est extrémement générale. Les premiers cas concrets de codes critiques qui pourront être identifiéspermettront de déterminer s’il y a une structure récurrente, un schéma qu’ils pourraient partager, quipourrait permettre de les reconnaître plus efficacement et qui m’aurait échappé lors de la caractèrisationthéorique.

Actuellement, la recherche et l’identification de codes critiques peut se résumer aux étapes suivantes,qui sont donc des fonctionnalités de AntiXSS-Auditor :

1) Extraction :Lister les éléments d’une page pouvant être désactivés

2) Caractériser un code :Relever ce sur quoi il agit, ce qui est différent après qu’il se soit exécuté. Extraire le sens et lafinalité d’un code n’est à ma connaissance pas possible. A défaut, il s’agira de déterminer uneliste de facteurs qui nous intéressent, et d’étudier quelles évolutions l’exécution du code leur faitsubir. Les facteurs choisis sont :a) l’état du DOMb) les variables et fonctions déclaréesc) les évènements enregistrés, et quelles fonctions sont associéesd) les exceptions levées lors du chargement du reste de la page, afin de déterminer si l’absence

du code provoque des erreurs.Deux approches seraient possibles. La première, statique, repose sur l’analyse du code lui-même.J’ai décidé d’abandonner cette piste périlleuse au profit de l’approche dynamique, qui consisteraà exécuter le code et constater les évolutions à posteriori.

3) Evaluation de la Discretion et de l’Importance :Une fois caractérisés, identifier les codes suffisament Discrets et Importants pour présenter uninterêt.

Enfin, la dernière fonctionnalité sera de pouvoir générer automatiquement l’AntiXSS neutralisant uncode critique ciblé.

Un tel outil est nécessaire pour assister l’auditeur dans ces différentes étapes car dans le cas d’uneapplication réelle, une même page web va intégrer de très nombreux codes javascript. La complexitéde ces codes ira de souvent simple, dans le cas de l’enregistrement d’un évènement depuis un attributHTML, à potentiellement très complexes, dans le cas du code contrôlant l’application, ou dans le casd’une librairie.

Déterminer l’impact de l’exécution de chacun de ces codes, pour en déterminer si leurs Discretionet Importance permettent de les considérer comme des codes critiques, est une tâche qu’on ne sauraitsérieusement envisager d’effectuer manuellement.

2) Pistes et choix de conception: .

Pour développer AntiXSS-Auditor, ma première réaction fut de me tourner vers le framework w3af(Web Application Attack and Audit Framework [28]), et de mettre au point un module qui pourrait êtreutilisé pour auditer une application web à la recherche d’AntiXSS, en même temps que des autres faillesque permettent de rechercher d’autres modules de w3af.

a) Les avantages de w3af: .1) Le framework s’occupe de toutes les tâches annexes, qui ne concernent pas la détection de vulné-

rabilités à proprement parler, permettant de se concentrer uniquement sur le corps du problème.Quelques exemples :- Crawling : à partir de la racine d’un site, w3af se charge de trouver toutes ses ramifications etutilise le module pour auditer chacune des pages découvertes.- Gestion de l’authentification : selon toute probabilité, une AntiXSS fait sens dans l’espace d’unsite où un utilisateur est authentifié. W3af prend en charge cette partie proprement.- Interfaces utilisateur : que ce soit pour l’utilisation ou la configuration d’un programme, il fautégalement développer une interface. W3af en propose une efficace dans laquelle les modulespeuvent facilement exposer leurs méthodes ou options.

2) Le partage :Un module pour un framework réputé permet à d’autres de facilement intégrer la recherched’AntiXSS dans leur procédure d’audit. Cela permet à un plus grand nombre d’en profiter, etouvre la porte aux contributions.

3) python :Le langage et son environnement ne méritent pas d’être l’argument principal, mais certainementd’être pris en compte tout de même.

Malgrè la validité de ces points, le premier prototype a rapidement mis en évidence les limitationsd’un tel choix de conception.

b) Problèmes et contraintes identifiées: .

Un plugin w3af est naturellement conçu pour effectuer l’audit d’une page web en partant de son codesource, puis de passer à l’audit des pages suivantes, et ce jusqu’à présenter un rapport avec toutes lesvulnérabilités détectées.

Cela est convenable pour la partie "Extraction", car il existe des parseurs HTML en python. Mêmes’ils ne seront pas capables de reproduire exactement le comportement du navigateur en cas de HTMLinvalide, ignorer ces divergences est acceptable si l’on considère que la majorité des sites web font uneffort pour ne pas présenter de violations trop excessives des normes de HTML.

Par contre, pour la partie "Caractériser un code", l’étude dynamique nécessite de pouvoir exécuter lecode, pour en étudier ensuite les effets. La simulation de l’exécution n’a de sens que si elle se dérouledans un environnement identique à celui dans lequel le véritable code serait lui-même exécuté.

Recréer tout l’environnement du navigateur (DOM, APIs du navigateur, ressources externes), dans unmodule python, n’a pas semblé être une ambition raisonnable, même en considérant l’effort de projetstels que PythonWebKit [29].

Enfin, pour la partie "Evaluation de la Discretion et de l’Importance", si je sais que la caractérisationdu code ("que fait il ?") est nécessaire pour répondre à cette question, je n’ai trouvé aucune piste pourdéterminer de manière automatique dans quelle mesure le code devait être considéré Discret ou Important.Ces notions dépendent bien trop du contexte, et du scénario que l’attaquant va tenter de réaliser.

La solution ici est donc de se rabattre d’un processus d’évaluation automatique vers une aide à ladécision. Cette transition rend nécessaire une certaine interactivité, chose qui est impossible dans le cadrede w3af qui fonctionne avec un cycle audit / rapport.

c) La solution retenue : devtools: .

Suite à ces constats, la piste de w3af a été abandonnée, pour une nouvelle solution de conception quipermet de mieux répondre à ces problématiques :

1) afin d’être au plus près de l’environnement du navigateur, autant se placer directement dans celui-ci2) afin d’être interactif, on peut utiliser les facilités offertes pour le développement d’extensions.Cependat, un nouveau problème apparaît alors : le navigateur, aux premières lignes dans l’usage de

nombreux utilisateurs, est un environnement très surveillé du point de vue de la sécurité, et qui est doncconçu de manière cloisonnée afin de limiter les actions possibles depuis chaque environnement.

Ainsi, une extension peut accéder au DOM des pages web, mais pas à leur contexte d’exécutionjavascript (ni les variables et fonctions déclarées, ni les évènements enregistrés, ni les exceptions levéesen cours d’exécution). C’est une limitation sévère puisque ce sont des éléments dont on aura besoin pour"Caractériser un code".

La solution vient des devtools (outils de développements) de Chromium (ou Chrome), pour lesquelsil est également possible de créer des extensions. En échange d’une demande de permissions supplémen-taires et d’un développement complexifié, celles-ci ont un accès direct et privilégié aux contextes desdifférentes pages.

Puisque ceux-ci peuvent également faire tout ce que peut faire une extension classique, les devtoolssont également une réponse satisfaisante à la question de l’interactivité.

3) Choix d’implémentation: .

Je vais apporter dans cette partie des précisions sur l’architecture de AntiXSS-Auditor, et sur lesmanières d’implémenter les méthodes choisies pour répondre aux différentes fonctionnalités.

a) Architecture: .

AntiXSS-Auditor est organisé en plusieurs entités disctinctes, imposées par l’environnement de dé-veloppement de Chromium :

1) Le "devtool" à proprement parlerC’est le module qui est instancié lorsque l’on accède à AntiXSS-Auditor pour un onglet donné,via la console de développement de Chromium. C’est lui qui peut accéder au contexte javascriptde la page inspectée, et servira donc à la partie Caractérisation, pour obtenir les évolutions desdéclarations, des évènements, et des exceptions.C’est aussi lui qui gère toute l’interface par laquelle l’utilisateur utilise AntiXSS-Auditor.

2) Des "content-scripts"Ce sont des modules qui sont injectés dans un onglet. Ils ont alors accès à son DOM, et sont doncutilisés pour la partie Extraction ainsi que pour la Caractérisation d’un code en ce qui concernel’évolution du DOM.

3) Un "background"C’est le module central, qui contrôle le comportement du navigateur lui-même (par exemple ouvrirun nouvel onglet), et qui surtout se charge de dispatcher les messages entre les devtools et lescontent-scripts de différents onglets.

b) Extraction: .

Pour repérer les points d’entrée, j’ai choisi de rechercher ceux-ci dans le DOM. Par opposition à"depuis le HTML de la réponse", puisqu’il serait inefficace de ne pas profiter du travail du parseurHTML. Et aussi par opposition à "en les interceptant entre le parseur HTML et le moteur javascript",puisque je souhaite pouvoir détecter des points d’entrée même s’ils ne sont pas activés par mon utilisationde l’application web auditée (les codes "actifs").

La contrepartie est que pour d’obtenir la liste exhaustive des points d’entrées (il en existe certainsque je n’ai pas présentés car très peu utilisés), il est alors nécessaire de rechercher spécifiquement ceuxde chaque type. Ce n’est absolument pas impossible, mais du fait de l’ensemble restreint de ceux utilisésrégulièrement, une liste exhaustive ne semble pas être une priorité.

Des points d’entrée peuvent cependant être également créés, et supprimés, lors de l’exécution. Parexemple, un code unique présent dans le code source peut réécrire intégralement le DOM afin de mettreen place l’application telle qu’elle est finalement utilisée, et se supprimer dans le processus. Ce cas estextrême et ne saurait être assez Discret pour être un code critique, mais d’autres peuvent être plus subtils.

Analyser le DOM uniquement lorsque l’application est chargée peut donc faire rater des opportunités.Pour pallier à ce problème, il convient, dès le début du chargement d’une page, d’examiner l’évolutiondu DOM également, afin de détecter si un point d’entrée venait à disparaître. Cela est possible grâce àun objet particulier rendu disponible par le navigateur, du nom de "MutationObserver".

c) Caractériser un code: .

Comme expliqué dans la partie VI-B1, caractériser un code se fera en comparant l’état des paramètreschoisis, après et avant l’exécution du code. Une solution élégante et optimisée existe probablement pourcopier un contexte et y exécuter le code, ou mieux, se raccrocher au moteur javascript pour identifier lafenêtre d’exécution du code et comparer les états précédents et suivants l’exécution.

Ces méthodes sont par contre de toute évidence compliquées, et méritent d’être plus soigneusementexaminées pour déterminer de potentiels effets secondaires inattendus (exécution asynchrone de plusieurscodes par exemple).

J’ai donc pris la décision de me tourner vers une solution moins efficace mais plus simple : pourchaque code à caractériser, AntiXSS-Auditor chargera à nouveau la page, dans un nouvel onglet, maisen désactivant le code à l’aide d’une AntiXSS. Une fois toutes les informations recherchées récupérées,le nouvel onglet peut être fermé.

En ne passant pas par une simulation mais en réalisant réellement les conditions du contexte que jesouhaite caractériser, j’obtiens de manière simple la garantie d’une mesure fiable, mais ce, au prix de laperformance.

d) Evaluation de la Discrétion et de l’Importance: .

Comme annoncé dans la partie VI-B2, en définitive, les évaluations de la Discrétion et de l’Impor-tance d’un code seront laissées à l’utilisateur. Mais pour ce faire, il pourra utiliser les résultats de lacaractérisation préalable du code.

e) Génération de l’AntiXSS: .

Une fois un code sélectionné comme code critique, la construction de l’AntiXSS se fait simplementune fois que l’on a récupéré l’élément qui contient ce code critique :

URL + "#" + encodeURIComponent(element)

4) Prototype: .

FIGURE 7. Capture d’écran de AntiXSS-Auditor en cours d’utilisation

La figure 7 illustre AntiXSS-Auditor en cours d’utilisation. On y voit une partie de la liste des pointsd’entrées trouvés pour la page auditée. La liste est organisée en 4 colonnes :

1) ElementIndique la localisation du fichier pour un script externe, "inline script" pour un script inline, et lesélecteur (moyen d’identifier un élément au sein du DOM) pour un point d’entrée "actif".Cette colonne est de plus une zone "cliquable", et permettra de visualiser rapidement des infor-mations en fonction du type de point d’entrée.Pour un point d’entrée "actif" (onclick, etc.), il est utile de voir à quel élément de la page ilcorrespond. Pour ceux-ci, cliquer provoquera le défilement de la page pour la centrer sur l’élémenten question, et colorera celui-ci (en rose, pour quelques secondes).Pour un point d’entrée "passif", il est utile de voir quels éléments de la page en dépendent. Ceuxqui ne seraient pas créer s’il était désactivé. Pour les points d’entrée "passifs", cliquer provoqueraà également le défilement de la page et une coloration, mais cette fois-ci sur chacun des élémentsdépendant de ce point d’entrée, successivement.

2) DetailsPour un point d’entrée "actif", cela indique quel évènement lui est rattaché.Pour un point d’entrée "passif", cela donne un pourcentage des éléments du DOM qui viendraità manquer si le code ne s’exécutait pas.

3) CodeAffiche le code associé au point d’entrée.

4) ExploitUn bouton qui déclenche l’ouverture d’un nouvel onglet, avec pour URL l’AntiXSS correspondanteau point d’entrée choisi.

Les points d’entrée "actifs" sont également mis en évidence dans la page à l’aide d’un cadre bleu,afin de pouvoir facilement les repérer.

5) Difficultés rencontrées pour AntiXSS-Auditor: .

La première difficulté rencontrée fut de trouver des pistes de réponse satisfaisantes à tant de questionsouvertes. La direction que j’ai prise pour répondre à "Comment résumer ce que fait un code ?" a soulevéencore de nouvelles questions tout aussi floues. Par exemple :

Comment définir la différence entre deux DOM ? Le déplacement d’un élément constitue-t-il unedifférence pertinente à relever ? De toute évidence, cela pourra dépendre de l’élément en question : leDOM est structuré sous forme d’arbre, certains éléments en contiennent donc de nombreux autres.

Et la modification d’un attribut ? Egalement, cela pourra dépendre de l’attribut : ce peut être le stylequi est modifié, aussi bien que l’enregistrement d’un nouvel évènement.

Répondre à ce genre de questions était d’autant plus compliqué que la forme exacte de ce dont jeveux assister la recherche, les AntiXSS, n’est pas non plus déterminée précisément.

La seconde difficulté principale est liée au cloisonnement du navigateur. Il a fallu du temps poursuffisamment bien saisir les limites de toutes les possibilités techniques, et finalement trouver celle quirendrait AntiXSS-Auditor possible. Et même si les devtools rendaient cela possible, ce cloisonnementimpose de fortes contraintes de développement, ce que la présentation de l’architecture peut laisserapercevoir.

VII. CONCLUSION ET PERSPECTIVES

A. Conclusion

Le travail effectué durant ce PFE portait sur un dispositif de sécutité présent dans les navigateursweb : les filtres cherchant à limiter l’impact d’attaques par XSS, attaques liées à une vulnérabilité pouvantêtre présente dans une applications web, répandue, et pouvant fortement nuire aux utilisateurs.

La problématique étudiée était de déterminer si la présence de ces filtres peut introduire de nouveauxmoyens pour un attaquant de compromettre la sécurité d’un utilisateur.

Dans ce rapport, après avoir introduit le contexte actuel du web, des attaques par XSS, et d’une partiedu fonctionnement des navigateurs, j’ai pu présenter l’état de l’art des filtres XSS que ceux-ci peuventaujourd’hui intégrer.

Je présente ensuite l’ensemble des résultats obtenus.

Grace à cette étude, j’ai pu montrer que, pour le plus moderne des filtres XSS, XSSAuditor, la sécuritéétait compromise, et je présente les méthodes et contextes que j’ai pu identifier et qui permettent le bondéroulement d’une telle attaque, que je baptise AntiXSS.

Afin de démontrer la réalité de ces attaques par AntiXSS, et de les illustrer, j’ai réalisé des proofs ofconcept, scénarios mettant en scène des applications web qui auraient pu être considérées comme tout àfait fonctionnelles et sécurisées jusqu’ici, mais sont vulnérables à cette nouvelle attaque.

Outre le fait d’être une nouvelle menace, cette attaque possède une autre particularité qui mérite d’êtreremarquées : elle est parfaitement silencieuse, son exploitation ne laissant aucune trace observable dansles logs du serveur web hébergeant l’application ciblée, puisqu’elle prend forme exclusivement au seindu navigateur de la victime.

S’il est relativement simple d’exploiter une vulnérabilité par AntiXSS, la difficulté est de l’identifier.En effet, celle-ci est intimement liée au fonctionnement et aux fonctionnalités de l’application danslaquelle elle se trouve, nécessitant une compréhension précise de cette application. Cela compliquefortement toute recherche d’une méthode générale pour identifier ces vulnérabilités.

Ayant prouvé la potentielle existence d’applications vulnérables aux AntiXSS, et considérant la diffi-culté d’identifier une application réelle comme vulnérable, je propose ensuite un outil, baptisé AntiXSS-Auditor, permettant d’assister efficacement dans un audit de sécurité recherchant des AntiXSS.

Je présente et justifie pour AntiXSS-Auditor les choix de conception et les moyens d’implémentations,ainsi qu’un prototype. AntiXSS-Auditor est fonctionnel et peut être utilisé, mais laisse place à desaméliorations qui seront abordées dans les perspectives.

Ce travail était particulièrement intéressant car partait d’un sujet vierge, et consistait en grande partied’une phase d’exploration autour de comportements imprévus (une AntiXSS repose sur des faux positifs)d’entités dont l’existence même est souvent ignorée (les filtres XSS des navigateurs).

B. Perspectives

Je vais maintenant présenter les perspectives issues des résultats de mon travail, dont j’estime qu’ellesméritent d’être considérées.

1) Evaluer la fréquence de vulnérabilités par AntiXSS dans des applications réellesLa réalité des AntiXSS désormais établie, il est nécessaire d’évaluer si des applications webactuelles sont vulnérables en pratique, et selon quelle fréquence. AntiXSS-Auditor est prévu pourassister cette recherche.Cela devra cependant aller de pair avec l’évolution, et l’amélioration progressive, de AntiXSS-Auditor.

2) Evolutions de AntiXSS-AuditorLa première évolution dont AntiXSS-Auditor aura besoin est l’approfondissement de sa fonction"Caractérisation d’un code". D’une part, j’ai déjà présenté pourquoi extraire les paramètres perti-nents du contexte d’exécution javascript méritait d’être implémenté. D’autre part, j’ai égalementprésenté les difficultés d’implémentation que cela impliquait, de par la nature très ouverte de cesquestions.Certains de mes choix d’implémentation, pour l’analyse de ces paramètres, "différences entredes états", auront probablement à être remis en cause, et ces nouveaux choix seront justifiés par

l’expérience aquise en consacrant le temps nécessaire à la recherche d’AntiXSS dans des casréels, et par l’analyse des codes critiques identifiés.Pour ces raisons, je crois que AntiXSS-Auditor ne pourra évoluer de manière efficace qu’au filde découvertes de vulnérabilités réelles par AntiXSS.Une autre piste d’évolution est une nouvelle fonctionnalité que je n’ai pas évoqué dans ce rapport,qui repose également sur l’acquisition d’expérience : s’aider de techniques de machine learning.Il serait pour cela envisageable de constituer une base de donnée des codes rencontrés par AntiXSS-Auditor lors de son utilisation, et de fournir à l’utilisateur la possibilité de les noter sur la Discretionet l’Importance. Le jeu de données ainsi constitué serait utilisé pour entraîner un réseau de neuronespar exemple, selon les paramètres issus de la "Caractérisation" du code, ou d’autres à déterminer.AntiXSS-Auditor pourrait en retour automatiquement présenter l’évaluation, d’après son appren-tissage, de la Discretion et l’Importance de nouveaux codes rencontrés.

3) Contributions malveillantesIl est compliqué d’identifier une vulnérabilité par AntiXSS, et plusieurs facteurs limitent laprobabilité qu’un contexte favorable à une AntiXSS soit créé par inadvertance dans le cadredu développement d’une application.Mais il est en revanche relativement aisé de créer volontairement un tel contexte, et ce, de manièreanodine. La simple séparation d’un module en deux fichiers, qui passera facilement passer pourune volonté de structurer un projet, peut suffire pour introduire une vulnérabilité par AntiXSS.C’est pourtant une modification tout à fait anodine : son impact fonctionnel est strictement nul.Mais elle suffira à pouvoir mettre en place une attaque efficace (et, on l’a vu, silencieuse).Le fait qu’une vulnérabilité AntiXSS soit compliquée à identifier, et le fait qu’elle n’apparaîssepas dans le contenu du code de l’application, font qu’une AntiXSS volontaire aura très peu dechance d’être un jour découverte.Ce constat est inquiétant pour de nombreux acteurs : projets open source, sites web employant denombreux développeurs, ou quiconque faisant développer une application web par un prestataire.

4) Responsabilité face aux AntiXSSLa question, en cas d’application vulnérable, est délicate et intéressante. Une AntiXSS peut ciblerdes applications dont la sécurité est irréprochable en tout point, et qui ne sont rendues vulnérablesque par le comportement excessif d’un composant du navigateur (le filtre XSS), mais ce composantsemble par ailleurs trop crucial dans de nombreuses autres situations des cas pour être retiré. Aqui alors de s’adapter, à l’application ou au navigateur ?

5) Un produit dérivéUn produit dérivé de ce travail sur les AntiXSS pourrait en utiliser les résultats pour une touteautre finalité : lutter contre la prolifération de scripts répandus, et utilisés entre autres pour letracking des internautes.L’exemple de référence est "google analytics", qui fournit des statistiques de fréquentation auxwebmasters, en échange de l’utilisation de ces même données par Google. Google analytics étantextrêmement répandu sur le web [30], un recoupement d’information permet à Google de suivreun utilisateur lors de sa navigation de sites en sites.Google analytics est déployé sous la forme d’un script que le développeur intègre à sa page web,et il s’avère que ce script partage des propriétés avec un "code critique" : il est parfaitementDiscret, par design, mais, pour l’utilisateur, pas du tout Important. On peut le désactiver sansrisque de nuire à l’expérience utilisateur.Mais en réalité, c’est un "code critique" qui pourrait être considéré comme nuisible pour lesutilisateurs, ce qui amène à la proposition du produit dérivé suivant : un script, également mis àdisposition des développeurs, qui se chargera d’automatiquement rajouter à chaque lien présentdans la page une "AntiXSS" qui cible google analytics, et le désactive.Quand un utilisateur clique sur un lien depuis une page intégrant ce script, google analytics estdésactivé dans la nouvelle page qu’il visite, et l’omniprésence de Google recule un peu.

RÉFÉRENCES

[1] OWASP, Cross Sites Srcipting, http ://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

[2] OWASP, XSS (Cross Site Scripting) Prevention Cheat Sheet, https ://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

[3] W3C, HTML5,http ://www.w3.org/TR/html5/syntax.html#overview-of-the-parsing-model

[4] What’s the difference between a web site and a web application ?, http ://stackoverflow.com/questions/8694922/whats-the-difference-between-a-web-site-and-a-web-application

[5] Mozilla, Document Object Model (DOM), https ://developer.mozilla.org/fr/docs/DOM

[6] BeefProject, The Browser Exploitation Framework Project, beefproject.com/

[7] NoScript’s features, Anti-XSS protection, https ://noscript.net/features#xss

[8] Riccardo Pelizzi, R. Sekar, Stony Brook University, Protection, usability and improvements in reflected XSS filters, Proceeding,ASIACCS ’12 Proceedings of the 7th ACM Symposium on Information, Computer and Communications Security, Pages 5-5

[9] Mozilla, Security/Features/XSS Filter, https ://wiki.mozilla.org/Security/Features/XSS_Filter

[10] Microsoft, IE8 Security Part IV : The XSS Filter, http ://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx

[11] Microsoft, E8 XSS Filter design philosophy in-depth, http ://blogs.msdn.com/b/dross/archive/2008/07/03/ie8-xss-filter-design-philosophy-in-depth.aspx

[12] Eduardo Vela Nava, David Lindsay, Abusing Internet Explorer 8’s XSS Filters,https ://www.sysdream.com/sites/default/files/Abusing_IE8s_XSS_Filters (1).pdf

[13] Daniel Bates, Adam Barth, Collin Jackson, Regular Expressions Considered Harmful in Client-Side XSS Filters,http ://dl.acm.org/citation.cfm ?id=1772701

[14] WebKit, https ://www.webkit.org/

[15] Chromium Project, http ://www.chromium.org/blink

[16] Google, https ://www.google.com/chrome/browser/desktop/index.html

[17] Chromium Project, http ://www.chromium.org/Home

[18] Apple, https ://developer.apple.com/safari/

[19] Opera, https ://dev.opera.com/blog/300-million-users-and-move-to-webkit/

[20] http ://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454

[21] Eduardo Vela, David Lindsay, BlackHat 2009, Our Favorite XSS Filters/IDS and how to Attack Them,https ://www.blackhat.com/presentations/bh-usa-09/VELANAVA/BHUSA09-VelaNava-FavoriteXSS-SLIDES.pdf

[22] Chromium blog, Security in Depth : New Security Features ,http ://blog.chromium.org/2010/01/security-in-depth-new-security-features.html

[23] Sebastian Lekies, Ben Stock, Martin Johns, BlackHat US 2014, A tale of the weaknesses of current client-side XSS filtering,https ://www.blackhat.com/docs/us-14/materials/us-14-Johns-Call-To-Arms-A-Tale-Of-The-Weaknesses-Of-Current-Client-Side-XSS-Filtering-WP.pdf

[24] IETF, HTTP Header Field X-Frame-Options, https ://tools.ietf.org/html/rfc7034

[25] Mozilla, Event reference, https ://developer.mozilla.org/en-US/docs/Web/Events

[26] Mozilla, Fantastic front-end performance Part 1, https ://hacks.mozilla.org/2012/12/fantastic-front-end-performance-part-1-concatenate-compress-cache-a-node-js-holiday-season-part-4/

[27] ietf, Hypertext Transfer Protocol (httpbis) - Charter for Working Group,https ://datatracker.ietf.org/wg/httpbis/charter/

[28] Web Application Attack and Audit Framework, http ://w3af.org/

[29] PythonWebKit, https ://wiki.python.org/moin/PythonWebKit

[30] Over 10M Websites Now Using Google Analytics, 2010, http ://techcrunch.com/2012/04/12/google-analytics-officially-at-10m/