UNIVERSIT DE LIMOGES COLE DOCTORALE Sciences et Ingnierie pour lInformation FACULT DES SCIENCES ET TECHNIQUES

Thse No 69/2012

THSE pour obtenir le titre de DOCTEUR DE LUNIVERSIT DE LIMOGES Discipline / Spcialit : Informatique prsente et soutenue par Nassima Kamel le 20 dcembre 2012

Scurit des cartes puce serveur Web embarqu

Thse dirige par Jean-Louis Lanet, co-encadre par Julien Iguchi-Cartigny

JURY Rapporteurs : Mme. Samia Bouzefrane M. Christophe Bidan Examinateurs: Mme. Marie-Laure Potet M. Christophe Clavier M. Jean-Louis Lanet M. Julien Iguchi-Cartigny Professeur Ensimag, Grenoble INP Professeur lUniversit de Limoges Professeur lUniversit de Limoges Matre de Confrences lUniversit de Limoges Matre de Confrences (HDR) au CNAM de Paris Matre de Confrences (HDR) Suplec de Rennes

Remerciements
Je tiens tout dabord remercier les rapporteurs Dr. Samia Bouzeframe et Dr. Christophe Bidan, davoir accpt de faire un compte rendu de ce mmoire et pour les corrections quils ont apportes. Je remercie galement les examinateurs Pr. Marie-Lore Potet et Pr. Christophe Clavier davoir bien voulu consacrer de leur temps juger ce travail. Je remercie mon directeur de thse Pr. Jean-Louis Lanet de mavoir donn lopportunit datteindre cet objectif de prparer une thse doctorale en me proposant ce sujet, et de mavoir dirige tout le long de ces trois annes. Je remercie galement Dr. Julien Iguchi-Cartigny mon codirecteur, notament davoir contribu la dnition de mon sujet de thse. Mes remerciements vont galement mes adorables collgues (doctorants et ingnieurs), je cite : Amaury, Bhagya, Damien, David, Guillaume et Pierrick, pour leur amiti et pour tous les bon moments de rire et de folie que nous avons passs ensemble. Je remercie encore une fois ceux dentre eux qui ont eu la gentillesse de lire des parties de ce mmoire. Je remercie aussi tous les autres doctorants : Aymrick, Antoine, Richard, Slim, Julien ; les anciens doctorants : Oana, Alex, Agns, Ahmadou et dautres ; les stagiaires passs et prsents de notre quipe ainsi que le personnel technique et administratif en particulier Hubert, Sylvie et Odile, pour leurs amiti et sympathie. Je noublie pas aussi de remercier mes amies de longue date, Fatiha, Kahina et Samira pour leur prsence. Mes plus vifs remerciement vont ma chre famille qui inclue mon anc, de mavoir soutenue et encourage dans les moments diciles. mes parents particulirement, je ddie ce titre de DOCTEUR dont ils seront sans doute plus heureux que je ne le suis. Merci tous ceux qui ont contribu de prt ou de loin laboutissement de cette thse.

ii

Rsum
Les cartes puces sont des dispositifs scuriss, de plus en plus utiliss dans le monde. Leur succs est principalement d leur aspect tamper-resistant qui permet de stocker des informations sensibles (cls de chirement) de manire scurise. Vu les nombreux sensibles domaines dutilisation des cartes puce (bancaire, mdical, tlphonie), plusieurs recherches se sont intresss la scurit et aux attaques possibles sur ces dispositifs. La nouvelle gnration de cartes puce dnit un serveur Web embarqu. Il existe principalement deux types de spcications pour ces nouveaux dispositifs, la premire a t tablie par lorganisation OMA qui propose un simple serveur HTTP nomm Smart Card Web Serveur (SCWS) indpendant de la plateforme dexcution. La seconde est une nouvelle version de Java Card propose par Sun Microsystems (actuellement Oracle), nomme Java Card 3, dition connecte ; elle inclue le support de lAPI Java servlet 2.4, et une amlioration signicativement de lAPI Java Card (thread, String, etc.) et des fonctionnalits de scurit supportes. Lintgration du serveur Web dans la carte puce apporte un ensemble davantages et dnit un nouvel usage de la carte puce. En eet, en plus de laspect authentication robuste que la carte peut dsormais fournir sur le rseau, lutilisation des standards du Web permet davoir une exprience utilisateur continue et enrichit laspect et la convivialit des interfaces fournies via un navigateur Web. Face ces avantages, les risques dattaques augmentent. En plus des attaques classiques connues sur les cartes puce (physiques et logiques), certaines attaques Web connues sur des applications Web standards peuvent se reproduire sur les cartes puce. Parmi ces attaques, la Cross Site Scripting (appele aussi XSS) est lune des plus rpandues ; elle est simple raliser mais ses consquences peuvent tre trs graves. Cette attaque exploite des applications vulnrables qui ne ltrent pas les donnes non ables (entre par un utilisateur) avant de les utiliser. Elle consiste injecter un code malicieux dans une entre fournie par lapplication, qui est ensuite retourn dans une ressource de lapplication et excut dans le navigateur Web de la victime. Dautre part, les spcications des cartes serveur Web embarqu dnissent des protocoles (HTTP, BIP, TCP/IP) qui doivent ncessairement tre implments pour assurer la communication de la carte avec le navigateur Web et sur le rseau. Des failles dimplmentation de ces protocoles peuvent engendrer des vulnrabilits facilitant les attaques sur les cartes puce. Dans cette thse nous nous intressons la scurit des cartes puce serveur Web embarqu deux niveaux. Le premier concerne la scurit des applications Web contre des attaques XSS. Nous proposons dans ce cadre un outil danalyse statique des applications Web Java Card 3, qui a pour objectif de vrier quune application est scurise contre ces attaques, incluant un ltrage des donnes non ables. Notre outil peut tre considr comme un outil de certication de la robustesse des applications Web avant leur chargement dans la carte. Nous avons galement implment une API de ltrage que le dveloppeur peut importer dans son application. Le second niveau de scurit explor, concerne limplmentation du protocole HTTP ; nous suggrons un outil de fuzzing pour tester la conformit et la robustesse du protocole HTTP implment dans une carte. Cet outil apporte un ensemble doptimisations qui rduit le temps du fuzzing et gnre des donnes de test de manire intelligente. Mots cl : carte puce, Java Card , SCWS, XSS, HTTP, analyse statique, dpendance causale, Fuzzing.

iii

Abstract
Smart cards are widely used secure devices in todays world, which can store data in a secured manner and ensure data security during transactions. The success of smart card is mainly due to their tamper-resistant nature which allows them to store sensitive datas like cryptographic keys. Since they are using in multiple secure domains, like banking, health insurance, etc. more and more researches are taken place in this domain for security and attacks. The last generation of smart card, denes an embedded web server. There are two types of specications for these devices, the rst one is dened by OMA organisation that propose a simple HTTP web server named Smart Card Web Server (SCWS), the second is proposed by Sun Microsystems (currently Oracle), consists of a Java card 3 connected edition platform, that includes a Java servlet 2.4 API with improved Java Card API and security features. In addition to network benets from the robustness of smart card, the use of web standards provide a continuous user experience, equivalent to that seen while surng on the internet and it enhances the look and feel of GUI interfaces. The GUI interfaces are accessible from a browser which is located on the terminal on which the card is connected. However, in addition to the classical attacks (physical and logical), the integration of web server on smart card, exposes the smart card to some existing classical web application attacks. The most important one is the cross site scripting attack, also named XSS. It consists of injecting malicious data to the given web application inputs and if the resource returned to the browser includes the malicious code, it will be interpreted and executed, causing an attack. A web application is vulnerable to XSS if it uses an untrusted data without ltering malicious characters before. On the other hand, to ensure the communication between web applications and browser or other network entities, it is necessary to integrate some protocols to the smart card, for example HTTP, BIP or TCP/IP. The vulnerabilities in the implementation of these protocols can facilitate some attacks. Our contribution on this thesis is divided in two parts, in the rst part, we are interested on the security of web applications against XSS attack. We suggest a static analysis tool, based on tainting approach, that allow to verify if a web application is secured or not, including ltering data in all insertion points where XSS is possible. We also implement, an API lter, compatible with Java Card 3 platform, that developers can import during the development of their applications. The second part consists of verifying the conformance and the robustness of the implemented HTTP protocol. For that we propose an intelligent fuzzing tool that includes a set of optimisations that allows to reduce the time of fuzzing. Key words : smart card, Java Card 3, SCWS, HTTP, XSS attacks, Fuzzing, Static analysis, Tainting.

iv

Sommaire
Introduction gnrale 1

Domaine dtude

7
9 9 10 11 12 12 13 13 14 17 21 21 22 22 23 24 25 26 26 27 30 31 32 36

1 Contexte dtude 1.1 1.2 1.3 La carte puce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les protocoles de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 1.3.2 1.3.3 1.4 Le protocole APDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le protocole BIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le protocole HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les cartes puce serveur Web embarqu . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 1.4.2 Les cartes serveur Web SCWS . . . . . . . . . . . . . . . . . . . . . . . . Les cartes Java Card 3 Edition Connecte . . . . . . . . . . . . . . . . . . .

1.5

Cas dutilisation des cartes puce serveur Web embarqu . . . . . . . . . . . . . 1.5.1 1.5.2 1.5.3 1.5.4 Accs rapide et simple aux services oerts par la carte . . . . . . . . . . . . Amlioration de linterface daccs aux services oerts par lmetteur . . . . Scurit de connexion dun terminal distant une application . . . . . . . . Exemple dapplication : le Disque Virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.6

Conclusion

2 Les attaques sur carte puce 2.1 Attaques sur cartes puce standards . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 2.2 Attaques physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attaques logicielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attaques combines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les attaques Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Exemples dattaques Web les plus rpandues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3

Conclusion

vi

SOMMAIRE

II

Scurit des applications Web Java Card 3

39
41 41 41 43 44 45 46 47 52 53 53 55 56 58 59 59 60 61 63 64 64 65 66 67 67 69 70 70 72 72 73 73 75

3 Les attaques Cross Site Scripting 3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.2 3.3 Injection volatile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Injection persistante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Porte et exploitation des attaques XSS . . . . . . . . . . . . . . . . . . . . . . . . Solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 3.3.2 Solutions ct client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Solutions ct serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4

Conclusion

4 Dtection de vulnrabilits dans un programme 4.1 4.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyse statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 4.3 tat de lart des outils danalyse statique . . . . . . . . . . . . . . . . . . . Lanalyse statique dans Java Card . . . . . . . . . . . . . . . . . . . . . . .

La dpendance causale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 4.3.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Travaux existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4

Conclusion

5 Analyse statique de bytecode Java Card 3 5.1 5.2 5.3 Prsentation gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reprsentation dune vulnrabilit XSS . . . . . . . . . . . . . . . . . . . . . . . . Processus dexcution dun bytecode 5.3.1 5.3.2 5.3.3 5.4 5.5 . . . . . . . . . . . . . . . . . . . . . . . . . .

Zones de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les instructions de la JCVM . . . . . . . . . . . . . . . . . . . . . . . . . .

Findbugs et ses limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyse inter-procdurale et interclasses . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 5.5.2 5.5.3 Prsentation du concept de CFG . . . . . . . . . . . . . . . . . . . . . . . . Analyse inter-mthodes et inter-classes . . . . . . . . . . . . . . . . . . . . . Imprcision de lanalyse insensible au contexte . . . . . . . . . . . . . . . .

5.6

Analyse des ux de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 5.6.2 La dpendance causale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . tiquetage des conteneurs . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SOMMAIRE

vii

5.6.3 5.6.4 5.7

Dtection des champs persistants . . . . . . . . . . . . . . . . . . . . . . . . Dpendance causale inter-mthodes . . . . . . . . . . . . . . . . . . . . . .

78 78 79 80 80 81

API de ltrage XSS pour des applications cartes puces . . . . . . . . . . . . . . . 5.7.1 5.7.2 5.7.3 5.7.4 5.7.5 Filtrage des donnes insres dans un lment HTML . . . . . . . . . . . . Filtrage des donnes insres dans des attributs HTML . . . . . . . . . . . Filtrage des donnes insres dans un code JavaScript . . . . . . . . . . . .

Filtrage et validation des donnes insres dans les proprits de style HTML 82 Filtrage des donnes insres dans des valeurs de paramtres dURL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 83 85 85 86 86 88 90 91 91 92 93 94 97 100 101

5.8

Conclusion

6 Implmentation et exprimentations 6.1 6.2 Prsentation de BCEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interprtation abstraite de la JCVM . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 6.2.2 6.2.3 6.3 6.4 Simulation dune frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reprsentation dun item . . . . . . . . . . . . . . . . . . . . . . . . . . . . Plugin XSSDetector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Implmentation de JCXSSFilter

Exprimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 6.4.2 6.4.3 6.4.4 6.4.5 Stratgie dvaluation de loutil danalyse statique . . . . . . . . . . . . . . Temps de lanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dtection de vulnrabilits . . . . . . . . . . . . . . . . . . . . . . . . . . . Faiblesse de lanalyse statique . . . . . . . . . . . . . . . . . . . . . . . . . . Surcot du ltrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.5

Conclusion

III

Scurit du protocole HTTP

103
105 105 106 106 107 108 108 109 110

7 Le protocole HTTP et les techniques de vrication 7.1 7.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les techniques de vrication et de validation de protocoles . . . . . . . . . . . . . 7.2.1 7.2.2 7.3 La vrication formelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Test de logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Le Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 7.3.2 7.3.3 Dnition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . tat de lart des logiciels de fuzzing . . . . . . . . . . . . . . . . . . . . . .

Le fuzzing sur carte puce . . . . . . . . . . . . . . . . . . . . . . . . . . .

viii

SOMMAIRE

7.4

Le protocole HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1 7.4.2 7.4.3 7.4.4 7.4.5 7.4.6 7.4.7 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . Les requtes HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les rponses HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les champs dentte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accs aux ressources protges . . . . . . . . . . . . . . . . . . . . . . . . . Antmmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

111 111 111 111 113 114 115 115 116 117 117 118 118 119 120 123 123 123 128 128 129 130 130 131 132 133 133 136 136 136 138 139 139 141

7.5

Conclusion

8 Fuzzing HTTP 8.1 8.2 Prsentation gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lapplication PyHAT 8.2.1 8.2.2 8.2.3 8.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fonctionnalits de PyHAT . . . . . . . . . . . . . . . . . . . . . . . . . . .

Stratgie danalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Loutil Smart-Fuzz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 8.3.2 8.3.3 8.3.4 8.3.5 8.3.6 8.3.7 8.3.8 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . tude des requtes HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conception dune BNF (Backus Normal Form ) HTTP interactive . . . . .

Modlisation des donnes de test . . . . . . . . . . . . . . . . . . . . . . . . Conguration de Peach pour les cartes puce SCWS . . . . . . . . . . . . . Le paralllisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fichiers de journalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyse des vnements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.4

Conclusion

9 Implmentation et rsultats exprimentaux de Smart-Fuzz et PyHAT 9.1 9.2 9.3 Implmentation de PyHAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rsultats de lanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loutil Smart-Fuzz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.1 9.3.2 9.3.3 9.3.4 9.3.5 Les modles de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les modles dtats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les mutations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conguration des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conguration du processus dexcution . . . . . . . . . . . . . . . . . . . .

SOMMAIRE

ix

9.4

Exprimentations et Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4.1 9.4.2 Temps dexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Failles dtectes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

141 141 142 143

9.5

Conclusion

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IV

Conclusions et perspectives

145
147 148 148 149 149 151 152

10 Conclusions et perspectives 10.1 Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Principales contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.1 Analyse des applications Web . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.2 Fuzzing HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4 Synthse gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

V
A

Annexes

153
155

A.1 Reprsentation du chier assesment.xml . . . . . . . . . . . . . . . . . . . . . . . . A.2 Fichiers de journalisation de Smart-Fuzz . . . . . . . . . . . . . . . . . . . . . . . . B B.1 Exemple de servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.2 Descripteurs de dploiement dune application Web . . . . . . . . . . . . . . . . . . C C.1 Notions Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

155 156 157 157 158 161 161

SOMMAIRE

xi

Liste des tableaux

2.1 3.1 5.1 6.1 6.2 6.3 7.1 7.2 8.1 8.2 Slection dOWASP des dix vulnrabilits les plus rpandues en 2010 . . . . . . . . Exemples dencodages pour outrepasser une liste noire . . . . . . . . . . . . . . . . Exemples de caractres spciaux et leur encodage en entits HTML . . . . . . . . . Temps de lanalyse statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rsultat danalyse des applications Disque virtuel et JC3CreditDebit . . . Rsultats danalyse de lapplication TestPackage . . . . . . . . . . . . . . . . . . . Versions du protocole HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les codes de retour dune rponse HTTP . . . . . . . . . . . . . . . . . . . . . . . Stratgie de dtection des champs HTTP implments . . . . . . . . . . . . . . . . Les requtes conditionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 50 80 94 94 95 111 114 122 127

xii

LISTE DES TABLEAUX

xiii

Table des gures

1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 3.1 3.2 5.1 5.2 5.3 5.4 7.1 7.2 8.1 8.2 8.3 8.4 8.5 8.6 Carte puce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Commande APDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rponse APDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication entre SCWS et tlphone mobile via le protocole BIP . . . . . . . Architecture du SCWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SCWS dans une carte Java Card 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . Composents dune application Web Java Card . . . . . . . . . . . . . . . . . . . . . Exemple dapplication Java Card 3 : le Disque Virtuel . . . . . . . . . . . . . . . . Achage dune fentre de dialogue par un script . . . . . . . . . . . . . . . . . . . Attaque XSS persistante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Automate dune vulnrabilit XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . Reprsentation des structures de la JCVM . . . . . . . . . . . . . . . . . . . . . . . Exemple de graphe CFG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Suivi des ux de donnes inter-mthodes . . . . . . . . . . . . . . . . . . . . . . . . Principe du fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication en HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vue gnrale de loutil de fuzzing HTTP . . . . . . . . . . . . . . . . . . . . . . . . Fonctionnement de lapplication PyHAT sur une carte SCWS . . . . . . . . . . . . Fonctionnement de lapplication Smart-Fuzz (cas des serveurs SCWS) . . . . . . . BNF de lentte Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fuzzing sur SCWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fuzzing parallle sur plusieurs cartes puce . . . . . . . . . . . . . . . . . . . . . . 10 12 12 13 15 16 19 23 42 43 65 65 71 79 109 112 118 119 123 128 129 130

xiv

TABLE DES FIGURES

Introduction gnrale
1 Introduction
Les capacits des cartes puce en termes de taille mmoire et de puissance de traitement, permettent aujourdhui dintgrer un serveur Web. Les premires spcications de cartes puce serveur Web embarqu ont t dnies par lorganisation Open Mobil Alliance (OMA) proposant la spcication Smart Card Web Server SCWS qui dnit linterface dun serveur HTTP/1.0 ou HTTP/1.1 embarqu dans la carte puce [All08a, All08c, All08b]. Cette spcication est destine aux cartes SIM. Elle permet une connexion locale entre le client HTTP (navigateur Web) du terminal et le serveur Web, ainsi quune administration distance via un protocole scuris (TLS) des applications charges dans le serveur. Elle fournit un ensemble de ressources statiques et dynamiques gres par des applications Web (xHTML, JavaScript, etc.), et accessibles lutilisateur via le client (navigateur Web). Les spcications ETSI [ETS10b] dnissent une API et des bibliothques disponibles pour la plateforme Java Card 2.2 utiles au dveloppement des applications Web bases sur des servlets et fournissant des mthodes permettant une servlet de grer les requtes/rponses HTTP. La spcication SCWS nest pas lie la Java Card 3 qui dnit galement un serveur Web embarqu. La spcication de lOMA est plus simple, dissocie de Java Card et a pour but unique de fournir un simple serveur Web embarqu. Elle correspond des cartes qui nont pas les performances susantes pour supporter lAPI Java card 3 et les protocoles TCP/IP. Pour communiquer avec le terminal bas sur la pile TCP/IP, des protocoles ont t dnis dont Bearer Independent Protocol-BIP. Une passerelle BIP est ncessaire dans le terminal pour assurer la communication entre les deux parties. La version Java Card 3.0.2 est la spcication la plus rcente de la plateforme Java Card de Sun Microsystems (aujourdhui Oracle). Elle est disponible en deux ditions distinctes : classique et connecte. La premire [JC309a, JC309e, JC309d] dcrit une volution lgre (API cryptographiques) de la plate-forme Java Card 2.2.2 et cible des marchs faible valeur ajoute en privilgiant la compatibilit avec les plates-formes prcdentes. Ce march reprsente aujourdhui plus dun milliard de cartes par an. La seconde [JC309c, JC309b, JC309f] est conue pour la nouvelle gnration de cartes puce et sadresse donc aux marchs les plus haut de gamme, en particulier les cartes SIM les plus puissantes. Avec cette nouvelle technologie, la carte puce peut communiquer via les protocoles TCP/IP comme tout autre lment dun rseau informatique. Ainsi, elle est capable de fournir ou daccder des services du rseau.

TABLE DES FIGURES

La principale nouveaut de cette dition est lintgration de certains standards Web, notamment HTTP ou HTTPS. Elle conserve les principes des prcdentes versions (notamment, lexcution dapplications multiples et une stricte isolation des applications) et permet le dploiement simultan dapplications des versions prcdentes (applets) et dapplications Web ( laide dun nouveau modle de programmation hrit de JEE : les Servlets [Ser03]). Elle apporte galement des volutions majeures au niveau des APIs et des fonctionnalits supportes (support de types String, programmation multi-tches, vrieur de bytecode obligatoire, etc.). Cette nouvelle technologie oblige repenser toute la scurit de ces dispositifs par rapport au modle traditionnel des cartes puce. Lutilisation de cette technologie rend la carte plus ouverte et plus accessible aux utilisateurs et potentiellement des attaquants travers les protocoles rseau tels que HTTP, TCP/IP et BIP. Des vulnrabilits peuvent provenir de failles dimplmentation des protocoles rseau ou dun dveloppement non scuris des applications Web qui devraient respecter une mthodologie de dveloppement scuris.

2 Cadre de la thse
Les travaux prsents dans cette thse proposent un ensemble de solutions pour rpondre aux nouvelles problmatiques que posent les cartes puce serveur Web embarqu. Nous nous intressons particulirement la scurit deux niveaux. Le premier concerne la scurit des applications Web contre des attaques par injection de code particulirement le cross site scripting, et le second sintresse la vrication de la conformit et la robustesse du protocole HTTP implment dans les cartes puce.

2.1 Scurit au niveau applicatif

Dans cette partie nous nous intressons la dtection et la prvention des attaques Web par injection de code. En eet, si lapplication nest pas soigneusement dveloppe, ne respectant pas une mthodologie de dveloppement scurise [OWA07, OWAa], alors des attaques Web standards pourraient se produire sur la carte puce. La plus rpandue de ces attaques est le cross site scripting appele aussi XSS [KGJE09]. Elle consiste injecter des donnes contenant un script malicieux dans une entre dune application (gnralement du JavaScript). Ce code est ensuite excut dans le navigateur dune victime lorsquune ressource de lapplication intgrant ce code est charge sans avoir t ltr au pralable. Cette attaque peut tre persistante si le code malicieux est sauvegard dans une ressource permanente dans le serveur, ou volatile si elle est gnre uniquement quand lutilisateur accde un lien hostile. Linterprtation du code malicieux peut engendrer le transfert de donnes (cookie par exemple) vers le domaine dun pirate, modier le comportement en local de lapplication (dans le navigateur de la victime) ou encore provoquer une indisponibilit de services. Nous avons dabord considr les solutions existantes dirents niveaux. Une premire solution est lintgration de mcanismes de dtection de code malicieux au niveau du serveur (pare-feux applicatifs) [SS02, Mod] . Ce mcanisme possde lavantage dtre indpendant de lapplication. Cependant il est dicile de direncier le code malicieux du code JavaScript classique (prvu dans lapplication). En gnral ces services ne dtectent que des squences connues comme hostiles,

TABLE DES FIGURES

ce qui est aisment contournable en rcrivant le code malicieux avec des encodages dirents. Les mcanismes de dtection dintrusion IDS [PHP, Gui08] sont une variante de cette approche, ils consistent vrier la lgalit des ux qui transitent entre le navigateur et le serveur an dempcher que des ressources soient rediriges vers le domaine dun attaquant. Cependant, comme toutes les solutions dynamiques (analyse pendant lexcution du code) cette approche engendre des cots supplmentaires en termes de temps de rponse du serveur et doccupation despace mmoire par lIDS. De plus, cette approche ncessite gnralement une instrumentation du bytecode. Cette solution ne conviendrait pas des dispositifs faibles ressources comme les cartes puce. Une deuxime solution est un mcanisme lintrieur du navigateur autorisant ou non lexcution du code JavaScript [MOZ]. La dcision de bloquer un code JavaScript se base sur la dtection de squences particulires ou lutilisation de listes blanches et listes noires. Outre le fait que la dtection de squences est contournable, la dcision de classer un code comme potentiellement dangereux est de la responsabilit de lutilisateur. De plus, il ny aucune garantie que ce mcanisme soit prsent ou actif dans un navigateur communiquant avec la carte. La solution la plus recommande consiste prvenir les vulnrabilits XSS depuis la phase de conception des applications Web en renforant la scurit par de bonnes pratiques de dveloppement [OWAa]. Le dveloppeur doit considrer toutes donnes externes lapplication comme non ables et donc potentiellement malicieuses. Les rponses retournes lutilisateur doivent tre ltres si celles-ci sont gnres partir de donnes malicieuses. Cette solution est dicile appliquer car elle demande une attention ddie de la part du programmeur. Une alternative cette solution consiste utiliser une API de ltrage "de conance" (dveloppe par une tierce partie) capable de ltrer ecacement une variable contenant une donne non able. Cependant, nous navons aucune garantie que lapplication inclue bien une API ltrage, ni si tous les points dinsertion de donnes dans lapplication ont t ltrs. Une solution serait dutiliser la technique de dpendance causale pour suivre la propagation des donnes non ables dans un chemin dexcution du code et de vrier si sur ce chemin les fonctions de ltrage sont appeles avant que la ressource non able soit retourne au client ou sauvegardes en mmoire persistante. Une dpendance causale entre deux objets est prsente sil existe un ux dinformation direct ou indirect entre eux. Un exemple de technique pour vrier si une telle relation existe est de marquer avec une tiquette les entres (les sources) dun programme et de propager celle-ci toute variable assigne partir de ces entres ou une variable possdant dj une tiquette (les drivations). Si les variables tiquetes atteignent des mthodes considres comme critiques (on parle des tats puits) alors le systme considre quil existe une vulnrabilit potentielle. loppos, si une variable tiquete atteint une fonction permettant la dtection ou le nettoyage des donnes alors ltiquette est enleve pour signier que la donne nest plus considre comme critique. Contribution. Notre solution est base sur une analyse statique appliquant la dpendance causale permettant de suivre la propagation des donnes non ables (tiquetes) dans un code et de vrier quelles sont nettoyes par une fonction de ltrage de conance avant dtre retournes dans une ressource vers le navigateur de lutilisateur (XSS volatile) ou sauvegardes en mmoire persistante (XSS persistante). Lobjectif de cet outil est de certier quune application est scurise contre les XSS (volatiles et persistantes) avant son chargement dans la carte puce. Notre outil est bas sur le logiciel danalyse statique FindBugs [Fin] qui est capable deectuer une analyse des ux de donnes partir dune abstraction de lexcution du bytecode. Cependant,

TABLE DES FIGURES

ce logiciel a des limites, en particulier, les analyses inter-procdurale et inter-classes ne sont pas prises en compte. Nous avons donc amlior cette analyse an dtendre FindBugs et permettre la propagation des tiquettes entre objets de mme mthode ou de mthodes direntes qui appartiennent une mme classe ou de classes direntes. Ainsi, notre solution se compose de deux outils : un outil danalyse statique, nomm XSSDetector sous forme de plugin pour FindBugs, capable de suivre lexcution abstraite dune application an de vrier si chaque entre passe par une fonction de ltrage de conance avant dtre retourne lutilisateur ; une API nomme JCXSSFilter base sur lAPI ESAPI dOWASP [ESA], compatible avec la plateforme Java Card 3 permettant de ltrer les donnes contre les attaques XSS. Un programmeur dcidant dutiliser nos outils pour dvelopper son application utilise les fonctions de JCXSSFilter an de nettoyer toutes les entres dans son programme. Puis une fois lapplication ralise, il excute loutil danalyse statique an de vrier que toutes les entres du programme sont bien nettoyes avant dtre sauvegardes en mmoire persistante ou retournes lutilisateur. On peut signaler que notre outil peut tre tendu pour dtecter dautres cas qui peuvent tre grs par analyse statique.

2.2 Scurit au niveau du protocole HTTP

La deuxime contribution de nos travaux sintresse au protocole HTTP qui doit tre ncessairement ajout la carte an dassurer la communication entre le serveur Web et le navigateur Web. Ce protocole est sans tat (chaque requte est traite indpendamment des autres). Il permet deffectuer des demandes de ressources sur le serveur, adresses sous forme dURIs avec des requtes compltes par des enttes. Outre le fait quil fonctionne en mode texte avec des requtes trs longues, les nombreuses enttes composant une requte, ont chacune un comportement particulier quil faut caractriser. De nombreux travaux bass sur les mthodes formelles ont t raliss pour la vrication des protocoles [CMcMW04, MF05, Boc03, Hol91]. Cependant, cette approche permet simplement de vrier si des proprits spcies sont respectes dans limplmentation du protocole. Dautre part, la technique de validation par test consiste utiliser un jeu de tests qui est appliqu au protocole pour vrier dirents critres dont : la conformit la spcication, la robustesse, la scurit. La technique de test la plus classiquement utilise pour lvaluation des protocoles rseaux est le fuzzing. Cest une technique dinjection de donnes invalides sur une cible. En fonction des rponses du serveur, il est possible de dduire des faiblesses dans la gestion des entres de la cible qui peuvent tre dues au non respect de la spcication ou des failles de scurit. Il existe deux grandes classes de gnrations dentres invalides : partir de modles de donnes ou par mutation de squences [TDM08]. Dans notre cas, nous avons utilis la premire approche en se basant sur le logiciel Peach [Micb]. Le choix de cette approche est motiv par le fait que les fabricants de cartes ne fournissent gnralement aucune information sur limplmentation des applications installes dans les cartes puce. Nous supposons donc que nous navons aucune connaissance sur limplmentation du protocole HTTP que nous voudrions tester, que ce soit le code source ou la possibilit dintrospecter les instances en cours dexcution (boite noire). Nous ne pouvons, donc quobserver les entres/sorties sans avoir connaissance du comportement interne de la carte.

TABLE DES FIGURES

Les inconvnients de la technique du fuzzing rsident dans le temps ncessaire pour appliquer tous les jeux de tests possibles sur le systme cibl et aussi dans ltude des rsultats en sortie an de dtecter ses faiblesses. Lapproche classique dun fuzzing pour tudier les rsultats dune squence invalide consiste vrier que la cible fonctionne encore correctement aprs chaque test envoy (processus encore vivant, machine rpondant certaines commandes...). Mais dans notre cas, nayant accs quaux rponses nos requtes (et labsence de rponses parfois), notre analyse consiste donc, comparer les couples requte/rponse aux rsultats attendus fournis par un oracle. Cependant, la gnration de cet oracle ncessite une caractrisation du protocole HTTP implment. La caractrisation serait dicile raliser vu que les fonctionnalits HTTP dnies dans les spcications (RFCs) [FGM+ 99] ne sont pas forcment toutes implmentes. En eet, la spcication HTTP utilise une terminologie qui dnit pour chaque fonctionnalit si celle-ci est obligatoire ou non (utilisation des mots SHOULD , MAY et MUST ). De plus, le protocole implment ne respecte pas forcment la norme HTTP : absence de certaines fonctionnalits, rponses ngatives ou invalides certaines requtes, etc.

Contribution. Loutil de fuzzing que nous proposons est compos de deux outils complmentaires PyHAT et Smart-Fuzz [KBBL11]. Loutil PyHAT permet davoir une description des fonctionnalits et des caractristiques de la cible, la plus prcise possible. Il se base sur lanalyse des rponses des requtes spcies en entre. La plus grande dicult est de pouvoir interprter les rsultats retourns, sachant que certaines rponses nindiquent pas si une erreur sest produite ou si le serveur Web ne respecte pas les RFCs. Pour chaque mthode, version de HTTP et enttes, il a fallu trouver un algorithme dvaluation. Certains cas sont dailleurs indcidables et PyHAT considre alors par dfaut que la carte supporte ce cas. PyHAT gnre donc une grammaire rduite dont certains paramtres sont xs. Cette grammaire est ensuite exploite par notre outil de fuzzing Smart-Fuzz bas sur Peach pour la gnration des requtes HTTP envoys la carte. Lutilisation de cette grammaire rduit considrablement le nombre de donnes de test en se limitant uniquement des fonctionnalits implmentes. Dans Smart-Fuzz, nous avons conu des modles de donnes dcrivant les requtes HTTP et les dirents champs qui la composent. Ce sont ces modles que Peach utilise pour gnrer les donnes de test qui sont envoyes la carte. Cependant Peach ne compte pas parmi ses possibilits de conguration le protocole de communication BIP. Nous avons donc dvelopp une interface permettant de grer cette communication. Nous avons galement optimis le temps dexcution de notre outil par la conguration dun fuzzing parallle sur plusieurs cartes. Smart-Fuzz est galement compos dune application danalyse des vnements recueillis durant la phase du fuzzing et qui se charge de vrier les codes derreurs retourns et la cohrence des enttes et des rponses par rapport un oracle prdni.

3 Organisation du document
Lensemble de ce document est organis en trois parties et contient en tout neuf chapitres. La premire partie sintitule domaines dtude, elle est compose de deux chapitres :

TABLE DES FIGURES

Le chapitre 1 est un rappel sur la dnition dune carte puce et sur les volutions majeures quelle a connues. Nous prsentons galement plus en dtails les cartes puce serveur Web embarqu auxquelles nous nous intressons dans cette thse ; Le chapitre 2 aborde les attaques sur cartes puce en gnral (physiques et logiques) et prsente galement quelques exemples dattaques Web susceptibles de se reproduire sur la cartes puce serveur web embarqu. La deuxime partie prsente la premire problmatique que nous avons traite et qui concerne la scurit des applications Web ddies des cartes puce (en particulier Java Card 3) contre des attaques XSS. Elle est compose de trois chapitres. Le chapitre 3, dnit la vulnrabilit XSS et ses consquences et prsente un tat de lart des direntes approches utilises pour la prvention contre cette vulnrabilit ; Le chapitre 4 prsente un tat de lart des outils de vrication de programmes en particulier lanalyse statique et la dpendance causale ; Le chapitre 5 dtaille notre premire contribution durant cette thse qui consiste en une API de ltrage de donnes compatible avec la spcication Java Card 3 et un outil de dtection de vulnrabilits XSS bas sur une analyse statique du bytecode. Le chapitre 6 prsente limplmentation de notre outil danalyse et des rsultats exprimentaux. La troisime et dernire partie aborde notre deuxime axe de recherche qui concerne la scurit des cartes puce serveur Web embarqu au niveau du protocole HTTP implment. Elle est compose de trois chapitres : Le chapitre 7 dcrit le protocole HTTP et les direntes techniques de vrication et de validation de protocoles. Nous nous attardons particulirement sur la techniques de fuzzing que nous avons adopte ; Le chapitre 8 dtaille notre seconde contribution durant cette thse qui consiste en un outil de fuzzing qui comporte un ensemble doptimisations rendant le fuzzing plus intelligent ; Le chapitre 9 dcrit notre implmentation de loutil de fuzzing et les rsultats exprimentaux obtenus. Nous nissons ce rapport par une conclusion gnrale et de quelques perspectives pour des travaux futurs.

Premire partie

Domaine dtude

Chapitre 1

Contexte dtude
Sommaire
1.1 1.2 1.3 La carte puce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les protocoles de communication . . . . . . . . . . . . . . . . . . . . . 1.3.1 1.3.2 1.3.3 1.4 Le protocole APDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le protocole BIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le protocole HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10 11 12 12 13 13 14 17 21 21 22 22 23 24

Les cartes puce serveur Web embarqu . . . . . . . . . . . . . . . 1.4.1 1.4.2 Les cartes serveur Web SCWS . . . . . . . . . . . . . . . . . . . . . . Les cartes Java Card 3 Edition Connecte . . . . . . . . . . . . . . . . .

1.5

Cas dutilisation des cartes puce serveur Web embarqu . . . . 1.5.1 1.5.2 1.5.3 1.5.4 Accs rapide et simple aux services oerts par la carte . . . . . . . . . . Amlioration de linterface daccs aux services oerts par lmetteur . . Scurit de connexion dun terminal distant une application . . . . . . Exemple dapplication : le Disque Virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.6

Conclusion

Dans ce chapitre nous prsentons notre domaine dtude, savoir, la carte puce serveur Web embarqu. Avant de passer la description de ce type de cartes, nous commenons par une brve dnition de la carte puce et un historique de ses volutions les plus marquantes puis nous prsentons lensemble des dirents protocoles utiliss dans les cartes serveurs Web embarqu. Nous nirons par prsenter lapport de lintgration dun serveur Web dans une carte puce travers quelques cas dutilisation et un exemple dapplication Web ddie ce type de cartes.

1.1

La carte puce

Une carte puce est un composant lectronique, dni par un ensemble de normes tablies par lorganisme international de normalisation (ISO), portant le nom de ISO 7816 [Sta]. Elle permet deectuer des oprations (stocker, calculer, etc.), de faon scurise. Les cartes puce sont

10

1. Contexte dtude

utilises dans dirents domaines (bancaire, tlphonie, etc.). Sa puissance de calcul et sa capacit de stockage dinformations sont restreintes et peuvent tre direntes dune carte lautre.

Fig. 1.1 Carte puce Il existe direntes plateformes logicielles permettant dutiliser les cartes puce. Java Card est lune des plateformes les plus utilises sur le march, elle reprsente lheure actuelle 95% des cartes puce dans le monde. Java Card est un sous-ensemble des technologies Java adapt aux objets faibles ressources comme les cartes puce. Il sagit dune plateforme portable, scurise et multi-applicative qui intgre les avantages du langage Java : la programmation oriente objet oerte par Java (contre lassembleur auparavant) ; une plateforme ouverte qui dnit des interfaces de programmation (APIs 1 ) et un environnement dexcution standardis ; lutilisation dune machine virtuelle permettant la portabilit des applications et une scurit accrue lors de lexcution du code ; une plateforme qui encapsule la complexit sous-jacente (assembleur) et les dtails du systme des cartes puce. Grce la machine virtuelle Java Card (JCVM), il est possible de charger dans la carte plusieurs applications (Applets) capables de sexcuter dans un environnement scuris. Les programmes chargs dans cette plateforme sont gnralement des applets bien que depuis la version 3.0 dition connecte il est possible de charger des servlets aussi. La compilation des applets Java gnre des chiers CAP 2 (plateforme Java Card classique) ou des chiers class (Java card 3.0 dition connecte).

1.2

Historique

Depuis leur invention, les cartes puce ont connu une trs grande volution, commenant par de simples cartes mmoire, suivies par des cartes microprocesseur, puis des cartes multiapplicatives et enn la plus rcente rvolution est la naissance des cartes puce serveur Web embarqu. Dans ce qui suit, nous prsentons un bref historique des volutions les plus marquantes : 1979 : Sortie des premires cartes microprocesseur : La Bull CP8 (1 Ko de mmoire programmable et un cur base de microprocesseur 6805) ; 1983 : Utilisation des cartes puce dans le secteur mdical et social. Dans la mme anne, apparaissent les premires cartes tlphoniques mmoire ;
1. Application Programming Interface ou API est un ensemble de fonctions, procdures ou classes mises disposition par une bibliothque logicielle 2. Format pr-charg des applications Java Card (applets), gnr en dehors de la carte par un outil appel convertisseur et partir de chier class. Ce format est utilis pour des raisons doptimisation des ressources limites des cartes standards

1.3. Les protocoles de communication

11

1984 : Commercialisation des premires cartes mmoire bancaires, conues par Bull, Schlumberger et Philips. 1985 : Bull livre ses premires cartes bancaires dotes de microprocesseur ; 1991 : Lancement des premiers rseaux et services GSM (roaming, SMS, etc.), et des premires cartes Subscriber Identity Module (SIM) ; 1996 : Cration du langage Java Card, un sous ensemble du langage Java ; 1997 : Bull, Gemplus et Schlumburger crent le Java Card Forum an de discuter et de proposer de nouvelles spcications. Java Card devient la plateforme standard de dveloppement des applications pour cartes puce. La Java Card a connu plusieurs versions, nous citons particulirement : la Java Card 2.1, sortie en 1999, qui inclut des modications de quelques APIs, notamment au niveau de la cryptographie et des exceptions. la version Java Card 2.2 (en 2002) a pour principales nouveauts, la prise en charge des canaux logiques et lappel de mthodes distance. la Java Card 2.2.2 est une mise jour de la prcdente ; elle inclut une amlioration de linteroprabilit avec de multiples interfaces de communication et des dispositifs de scurisation normaliss. Elle fournit galement de nouvelles APIs pour un dveloppement plus conomique des applications. Cette version a t adapte pour correspondre aux normes des cartes puce USIM 3 , tout en tant compltement compatible avec les versions prcdentes. 2002 : la technologie de communication near eld communication NFC a et lance par Sony et Philips. Cest une technologie de communication sans-l courte porte et haute frquence, permettant lchange de donnes entre un lecteur et un terminal mobile ou entre les terminaux eux-mmes un dbit maximum de 424 Kbits/s et une distance de 20 cm au maximum. 2008 : lorganisation Open Mobile Aliance (OMA) [All08a, All08c, All08b], a annonc la spcication dun serveur Web Smart Card Web server (SCWS), destin des cartes SIM permettant dexcuter des applications plus riches sur les cartes puce, et communiquant sur le rseau via le protocole Bearer Independent Protocol (BIP). Dans la mme anne en mars 2008, Sun (dsormais Oracle) annonce la spcication Java Card 3.0, dont la plus rcente version est Java Card 3.0.2 en 2010. Elle est dnie en deux ditions distinctes, ldition classique et ldition connecte. Ldition classique est semblable la version Java Card 2.2, avec quelques amliorations aux niveaux des APIs notamment au niveau cryptographique. Ldition connecte dnit un nouveau modle de programmation, les servlets et le support dAPI et de fonctionnalits additionnelles telles que, le multi-taches (Multi-threading ), les types String, le ramasse-miette, etc. Nous prsentons cette version plus en dtail dans la section 1.4.2.

1.3

Les protocoles de communication

La communication entre une carte puce classique et un terminal se fait via un protocole de communication appel Application Protocol Data Unit (APDU). Lintgration dun serveur Web embarqu dans les cartes puce ncessite le support du protocole HTTP permettant lchange
3. Carte puce ddie la tlphonie 3G

12

1. Contexte dtude

de donnes entre les applications et le navigateur Web. Dautre part, les cartes puce serveur Web embarqu sont considres comme une entit dun rseau. TCP/IP sont les protocoles de communication rseau les plus utiliss ; cependant, ils ne peuvent tre supports que sur des cartes hautes ressources. Le protocole BIP est le plus adapt pour des cartes moins performantes. Dans ce qui suit nous prsentons brivement cet ensemble de protocoles.

1.3.1

Le protocole APDU

Le protocole APDU est le protocole de communication dni dans la norme ISO 7816-4, permettant une applet sexcutant sur une carte puce de recevoir des requtes manant du terminal et denvoyer des informations en rponse. Le dialogue entre la carte et le terminal se fait via un change de commandes et rponses APDU. Une commande APDU est une requte envoye par le terminal vers une applet charge dans une carte puce. La gure 1.2 reprsente les dirents champs qui la composent :

Fig. 1.2 Commande APDU CLA : octet de classe dni par lISO 7816 comme fournissant un certain nombre dinformations sur la commande (exemples : 0xBC pour les cartes vitales, 0x0A pour les cartes SIM, 0x00 pour les Mastercard/Visa) ; INS : octet dinstruction ; P1 : paramtre 1 ; P2 : paramtre 2 ; Lc : taille des donnes envoyes la carte (0x00 si pas de donnes) ; Le : taille des donnes attendues en rponse. La rponse APDU contient des informations sur le rsultat de la commande et ventuellement des donnes si ncessaires. Elle est compose dun champ de donne et dun mot dtat (gure : 1.3). La donne doit respecter la taille indique dans le champ Le de la commande. Le mot dtat (status word ) est cod sur deux octets : SW1 et SW2. SW1 indique si la commande t correctement excute et SW2 correspond des informations supplmentaires concernant la rponse. A titre dexemple, la valeur du mot dtat : 90 00 signie que la commande sest excute correctement.

Fig. 1.3 Rponse APDU

1.3.2

Le protocole BIP

Le protocole de communication BIP a t introduit dans la spcication ETSI [ETS10a], il est ddi aux cartes de type (U)SIM. Il permet une carte (U)SIM dutiliser les moyens de communication de lquipement (tlphone) auquel elle est connecte, quel que soit la technologie de

1.4. Les cartes puce serveur Web embarqu

13

communication utilise. Il ore la fois la possibilit daccs des donnes portes par des interfaces (Bluetooth, IrDA, etc.) et des donnes rseau (GPRS, 3G, etc). BIP est dni par un ensemble de commandes proactives permettant douvrir les canaux de communication, dmission et de rception des donnes. OpenChannel : ouvre un canal de communication entre la carte et le tlphone ; GetChannelStatus : demande au tlphone ltat du canal de communication ; SendData : envoie des donnes au tlphone ; ReceiveData : se prpare recevoir des donnes ; CloseChannel : ferme un canal de communication. La communication avec le terminal se fait via des protocoles standards UDP ou TCP (gure : 1.4). BIP est le protocole de communication utilis dans les cartes puce Smart Card Web Server, en remplacement du protocole TCP/IP qui nest pas support. Nous prsentons ce type de cartes dans la section suivante.

Fig. 1.4 Communication entre SCWS et tlphone mobile via le protocole BIP

1.3.3

Le protocole HTTP

Hypertext Transfer Protocol (HTTP) est le protocole de communication le plus utilis sur Internet. Il est bas sur le modle de communication client/serveur, le client HTTP correspondant au navigateur Web partir duquel un utilisateur peut envoyer des requtes un serveur contenant des donnes. La version HTTP/1.1 est dcrite dans la RFC 2616 date de juin 1999. Les cartes puce serveur Web embarqu utilisent ce mme protocole permettant aux applications Web de la carte dchanger des requtes/rponses avec le client Web hberg dans le terminal (le tlphone mobile en loccurrence). Dans la partie III de ce document, nous prsentons plus en dtail ce protocole et nous proposons un outil de fuzzing pour tester et vrier la conformit et la robustesse du protocole HTTP implment dans une carte puce.

1.4

Les cartes puce serveur Web embarqu

La stratgie des fabricants de cartes puce a toujours t dinventer des objets de plus en plus puissants et de nouveaux standards pour chaque nouvelle fonction. Avec larrive du protocole BIP, il est devenu possible dtablir une communication entre la carte SIM et le terminal en utilisant le protocole Internet Protocol (IP). Ainsi, lorganisation OMA a ralis la spcication de SCWS, un serveur Web HTTP embarqu dans des cartes SIM. Gemalto a ensuite fabriqu les premiers produits de ce type de cartes SIM, capables de servir de serveur Web (SCWS), de sauvegarder lensemble

14

1. Contexte dtude

du contenu du tlphone, dimplmenter des fonctions NFC voir GPS indpendantes de celles du tlphone etc. Dautre part, Sun (aujourdhui Oracle) a voulu exploiter les nouvelles volutions matrielles des cartes puce, en annonant les spcications Java Card 3 dition connecte, une nouvelle version de la plateforme Java Card. Cette plateforme est destine des cartes puce de haut de gamme. Elle supporte de nombreuses fonctionnalits et APIs la rendant trs proche de Java. La communication sur le rseau se fait via les protocoles TCP/IP qui sont cette fois directement supports sur cette plateforme.

1.4.1

Les cartes serveur Web SCWS

Le serveur Web SCWS est la technologie normalise par lorganisation OMA et ddie aux cartes SIM [All08d, All08a, All08c, All08b]. La spcication SCWS/1.0 dnit un serveur Web HTTP/1.1 [All08a] intgr dans la carte puce dont le contenu est accessible via une URL. Un protocole dadministration est galement dni permettant de mettre jour et de congurer distance le SCWS, ce protocole est aussi bas sur le protocole HTTP/1.1. Dans la version SCWS/1.1, la gestion distance par direntes entits de conance est optimise. Chaque entit peut tre contrle pour vrier quel contenu et quelle application elle a le droit daccs en utilisant une URL, partir dun client HTTP/HTTPS install sur son terminal distant. Le premier produit de cartes SCWS a t ralis par Gemalto qui a dvelopp des cartes SIM SCWS combin la technologie Near Field Communication (NFC), sur la base dune plateforme Java Card 2.2 [Gem]. Ils ont galement propos le protocole Single Wire Protocol (SWP) dni dans le standard European Telecommunications Standards Institute (ETSI), TS 102 588. Ce protocole permet la carte de communiquer sur un seul l avec un circuit NFC dans nimporte quel "objet intelligent". SWP nutilise quun seul contact, il permet ainsi de librer les deux contacts restants qui pourraient tre utiliss pour tablir une connexion de type USB avec le tlphone pour communiquer en mode IP. En novembre 2008, Gemalto et LG Electronics ont annonc le lancement du premier tlphone mobile commercial avec un serveur Web embarqu sur une carte microprocesseur. Le SCWS nest pas encore une technologie trs rpandue, mais elle pourrait rvler tout son potentiel avec dploiements de la technologie NFC. Architecture du SCWS Le SCWS comprend trois composantes : un serveur HTTP, un dpt (repository ) contenant les donnes SCWS, un gestionnaire de tche dadministration qui met jour le dpt SCWS. Lentit de communication externe (navigateur Web ou application OTA) communique avec la carte en utilisant les requtes/rpenses HTTP. Aprs tre relaye la couche de communication, la requte HTTP est envoye au serveur HTTP. La gestion des multi-requtes est assure par la couche communication, le serveur tant cens recevoir et grer une requte par session. Une session SCWS commence avec la rception de la requte et termine par lmission de la rponse. Le serveur HTTP se charge de transfrer la requte la destination correspondant lURL indique dans lentte de la requte. Cette URL peut pointer vers une ressource dynamique (servlet dans le cas de la plateforme Java Card 2.2), une ressource statique, ou une tache administrative (gure : 1.5).

1.4. Les cartes puce serveur Web embarqu

15

Fig. 1.5 Architecture du SCWS Les spcications de lOMA dnissent un contrleur daccs HTTP qui sappuie sur des ensembles protgs. Un ensemble protg contient des ressources et la liste des utilisateurs qui sont autoriss y accder. Si le chemin daccs indiqu dans lURL de la requte correspond un ensemble protg alors laccs la ressource demande est autorise uniquement aux utilisateurs dnis dans par ensemble. Des politiques de scurit ont t mises en place pour prvenir un accs illgal aux ressources de la carte [NN11] : 1. sparation des URLs : les ressources statiques et les direntes servlets doivent tre spares en terme dURL correspondant chacune delles. 2. pas daccs illgal une ressource statique : laccs ne doit pas tre possible : une ressource qui na pas de correspondance URL ; une ressource qui ne correspond pas lURL indique dans la requte ; une ressource non autorise. 3. pas dinvocation illgale de servlets : une invocation ne peut pas cibler : une servlet non enregistre ; une servlet dont aucune correspondance nest dnie ; les servlets qui ne correspondent pas lURL indique dans la requte ; des servlets non autorises. 4. pas daccs aux ressources externes au serveur : les donnes de la carte puce qui sont externes au serveur Web ne doivent pas tre accessibles. 5. ne pas envoyer des ressources en cas derreur : en cas derreur, la rponse ne doit pas contenir autre que le code derreur. 6. gestion scurise du contenu de la carte : les contenus de la carte (ressources statiques, applets, dpt) sont mis jour uniquement par ladministrateur.

16

1. Contexte dtude

Les cartes serveur Web bases sur la plateforme Java Card Larchitecture dune carte puce base sur la plateforme Java Card 2.2 et contenant un serveur SCWS est prsente dans la gure 1.6. Dans le but davoir des applications interoprables fournissant du contenu dynamique, les spcications ETSI TS.102.588 [ETS10b] dnissent une API et des bibliothques disponibles pour la plateforme Java Card 2.2. Ces bibliothques permettent de dvelopper des applications Web bases sur des servlets et fournissent des mthodes permettant une servlet de traiter les requtes HTTP et de retourner des rponses au client (navigateur Web)(exemple doPost() pour traiter les requtes POST). Les servlets sont des Applets enregistres dans le SCWS.

Fig. 1.6 SCWS dans une carte Java Card 2.2

Communication entre le SCWS et le terminal Le SCWS est utilis en mode serveur lorsquil communique avec le client (navigateur Web) du tlphone et en mode client lorsquil est administr distance par lmetteur de la carte [All08c, GDS07]. Les protocoles TCP/IP ntant pas supports dans la plupart des cartes puce, une passerelle SCWS doit tre installe dans le terminal pour assurer la communication entre le terminal et le protocole de transport local install sur la carte puce. La passerelle SCWS se charge de traduire les requtes HTTP reues par le client HTTP en commandes spcique au protocole local (BIP en loccurrence). Elle assure aussi un contrle daccs scuris aux donnes du SCWS. Le protocole BIP est le protocole de transport local le plus utilis. La carte communique avec le tlphone laide de commandes BIP [GDB06]. Ces commandes sont constitues de un ou plusieurs TLV (Tag Length Value ) correspondant un tag, la taille des donnes et les donnes. Elles font parties de la technologie SIM Application Toolkit (SAT) dnie par lETSI. Le protocole BIP seul ne sut pas pour assurer la transmission des paquets. Deux protocoles de transport sont galement utiliss : TCP est dploy sur le tlphone et utilis lorsque la carte SIM communique avec le tlphone ; CAT-TP (Card Application Toolkit Transport Protocol ) est dploy sur la carte SIM et utilis lorsque la carte communique avec un serveur distant. Le terminal utilise une passerelle BIP permettant dintercepter les commandes BIP envoyes par la carte et de les transformer en commandes TCP an de les renvoyer lapplication HTTP.

1.4. Les cartes puce serveur Web embarqu

17

Cette passerelle joue le rle dun convertisseur de protocole. Pour communiquer avec la passerelle, la carte dispose des commandes BIP SIM Toolkit. chaque commande Sim Toolkit, le tlphone rpond via une commande de type TerminalResponse. De plus, la passerelle interagit avec la carte laide dvnements : DataAvailable : commande dinitiation dun envoi de donnes du terminal la carte. ChannelStatus : commande pour demander la carte, ltat du canal de communication. Toute communication entre la carte et le tlphone dbute par louverture dun canal de communication. Pour cela, le tlphone envoie la commande TerminalProfile an dinformer la carte quil utilise le protocole BIP. Aprs cette commande, la carte attend la commande Fetch avant douvrir un canal de communication avec le tlphone via la commande OpenChannel. La commande Fetch initie une communication avec le terminal. Si le terminal rpond correctement via la commande TerminalResponse, le canal de communication est ouvert. Ensuite, la passerelle BIP coute sur le port 3516 ddi aux communications HTTP et lutilisateur peut interagir avec le SCWS partir de son navigateur Web en utilisant ladresse http ://127.0.0.1 :3516/index.html.

1.4.2

Les cartes Java Card 3 Edition Connecte

La Java Card 3 est la dernire version de la plateforme Java Card, dont la plus grande volution est ldition connecte. Elle apporte le support dun nouveau modle de programmation bas sur des servlets et louverture de la plateforme au rseau IP, via un serveur Web intgr et le support des protocoles standards TCP/IP et HTTP. Cependant, ces nouvelles fonctionnalits font que cette spcication nest supporte que sur des cartes puce haute de gamme (un processeur 32 bits, 128 ko dEEPROM, 512 ko de mmoire ROM, 24 ko de RAM). Dans la suite, nous dsignons par le nom Java Card 3, ldition connecte.

Architecture de la plateforme La plateforme Java Card 3 introduit dans son architecture une nouvelle machine virtuelle et un nouvel environnement dexcution qui supporte, en plus des applets classiques de la version Java Card 2.2, des applets tendues et les applications Web bases sur des servlets. Ces direntes applications se caractrisent respectivement par : Les Applets classiques : communiquent avec le terminal via le protocole APDU (norme ISO 7816-4). peuvent implmenter uniquement les API compatibles avec la prcdente version. Les Applets tendues : communiquent avec le terminal via le protocole APDU. supportent les API des applets classiques et aussi de nouvelles APIs telles que les Threads, Strings, et GCF (Generic Connection Framework ). Les Servlets : communiquent avec le terminal via le protocole HTTP ou HTTPS. Bases sur la spcication des Servlets version 2.4 [Ser03]. La plateforme Java Card est conue pour des cartes puce possdant des interfaces physiques haut dbit. Les protocoles vers des interfaces dE/S additionnelles ont t intgrs, comme : Universal Serial Bus (USB), MultiMediaCard (MMC)

18

1. Contexte dtude

ISO 14443 (contactless) Le protocole de communication par APDU bas sur la norme ISO 7816-4 est aussi support. Au niveau logique, la mise en uvre de la plateforme Java Card 3 doit fournir aux applications une interface rseau logique qui prend en charge les protocoles rseau suivants : Internet Protocol (IP) Transmission Control Protocol (TCP) Universal Datagram Protocol (UDP) Transport Layer Security (TLS) HyperText Transfer Protocol (HTTP) Secure HyperText Transfer Protocol (HTTP sur TLS)

La bibliothque Java Card 3 En plus du nouvel environnement dexcution, la plateforme Java Card se caractrise par une bibliothque beaucoup plus riche qui rduit nettement lcart entre les langages Java Card et Java. Parmi les lments Java qui sont dsormais supports nous pouvons citer : tous les types Java de base excepts les nombres virgule ottante (oat et double) ; les structures de donnes de base, savoir les tableaux multidimensionnel et les objets de type String et StringBuer les supports natifs des chiers classes avec ldition des liens dans la carte ; les classes utilitaires : un sous ensemble important du paquet java.util (Stack, Vector, Hashtable, Enumeration, Iterator, Date, Calendar, TimeZone, EventObject, EventListener, ResourceBundle, ListResourceBundle, Random, StringTokenizer, etc) ; la bibliothque GCF (Generic Connection Framework ) permettant douvrir des connexions rseau et le paquetage microedition.io, compos de classes qui grent des connections gnriques. Le paquetage java.io est en partie support incluant un ensemble de classes ncessaires la cration, la lecture, lcriture et le traitement des ux ; la persistance dans Java Card 3 est dirente des prcdentes versions. Un objet est dit persistant sil est dni dans un champ de type Static, instance de javacard.framwork.applet ou instance de javax.Servlet.ServletContext ou par accessibilit (si un champ persistant est aect un champ volatile, ce dernier devient automatiquement persistant) ; les transactions ont t amliores, les transactions Java bases sur les annotations sont supportes ; le Multi-tches, permettant un ensemble dapplications de sexcuter simultanment. Cependant les groupes de threads ou les threads fonctionnant comme des dmons, ne sont pas supports. la destruction automatique des objets non utiliss ; etc.

Les applications Web Java Card Une application Web dans Java Card est une archive possdant lextension .war qui est ensuite dploye et instancie dans le conteneur Web. Elle est identie par le chemin spcique (root path) par lequel elle est adresse dans ce conteneur Web. Ce chemin est utilis :

1.4. Les cartes puce serveur Web embarqu

19

comme identicateur unique (URI application) de lapplication sur la partie interne de la plateforme pour la communication inter-application ; comme identicateur externe (URL) pour lenvoi de requtes HTTP par un client Web (navigateur Web).

Fig. 1.7 Composents dune application Web Java Card

Structure de chiers contenus dans une archive .war Une application Web Java Card a la mme structure (rpertoires, chiers de conguration, etc) que les applications Web JEE (gure : 1.7. La seule restriction est quil nexiste pas de bibliothque spcique chaque application Web (le rpertoire WEB-INF/lib nexiste pas). De plus, la plateforme Java Card 3 dnit un descripteur dapplication spcique nomm javacard.xml [JC309c]. Le rpertoire WEB-INF contient les classes de lapplication Web et un descripteur de dploiement (web.xml). Les chiers .class et les servlets sont stocks dans des paquetages. Ils sont accessibles via un chemin daccs relatif au nom du paquetage (package ) qui les hberge. Une servlet est une classe Java permettant la gnration dynamique de contenu. Elle reoit des requtes HTTP (sous forme dobjets Java). La spcication des servlets pour la plateforme Java Card est un sous ensemble de la spcication des servlets Java v 2.4. Des fonctionnalits non supportes par la JCVM ont t supprimes telles que les pages JSP (Java Server Pages). Le chier META-INF/MANIFEST.MF dnit des informations supplmentaires du descripteur. Le rpertoire META-INF contient galement le descripteur dapplication javacard.xml spcique la plateforme Java Card. Tous les autres chiers inclus dans le chier .war, en dehors de la hirarchie des rpertoires META-INF et WEB-INF, ne sont pas directement utiliss par la plateforme. Ils sont simplement mmoriss sous forme de chiers ressources de lapplication et correspondent des ressources Web statiques desservies par le Web conteneur pour un client o-card.

20

1. Contexte dtude

La scurit de la plateforme Java Card 3 Comme ses prcdentes versions, la Java Card 3 dition connecte permet de bncier des avantages du langage Java, principalement : le typage : Java est un langage fortement typ permettant dviter les codes frauduleux ; les pointeurs ou rfrences : les oprations arithmtiques sont interdites sur les pointeurs ; la conversion de type : les conversions de type sont encadres avec des concepts de polymorphisme, dencapsulation et dhritage. Outre ces avantages, la plateforme ore des mcanismes de scurit dont certains taient dj prsents dans les prcdentes versions et dautres ont t renforcs. Parmi ces dirents mcanismes, nous citons : La rcupration de mmoire : un mcanisme automatique appel ramasse-miettes (Garbage Collector ) permet de librer les zones mmoires des objets volatiles (objets dure de vie limite stocks dans une mmoire volatile) non rfrencs depuis une longue dure. Pour des objets persistants (stocks dans une mmoire non-volatile) ce mcanisme peut tre appel la demande. Lisolation des objets des applications grce un pare-feu (rewall) : le pare-feu est un mcanisme permettant de partitionner le systme en espaces protgs o chaque partie appartient un contexte de groupe dirent. Un contexte de groupe est un paquetage Java compos dun ensemble dapplets instances de classes de mme paquetage. Un objet ne peut tre accessible que par des mthodes de mme contexte de groupe. Toutefois, la plateforme ore un mcanisme SIO (Shareable Interface Object ) permettant une application de disposer dune interface de partage, pour rendre accessibles certains services des applications autorises de contextes de groupe dirents. Il existe aussi un contexte propre la plateforme appel le contexte JCRE (Java Card Runtime Environnement ). Une application ne peut accder quaux services (APIs) de la plateforme pour lesquelles elle a les permissions requises. Cependant les applets appartenant au contexte JCRE peuvent accder tout objet de nimporte quel autre contexte de la plateforme. La vrication obligatoire de bytecode : le vricateur de bytecode tait optionnel dans les prcdentes versions. Il est maintenant obligatoire lors du chargement des applets sur la plateforme. Il consiste faire une interprtation abstraite du bytecode qui implique entre autre de verier le type des objets manipuls, et la consistance de la pile. La gestion de donnes volatiles : certains objets peuvent tre conservs en RAM, ce qui peut rendre certaines attaques plus complexes. Un contrle daccs n (Access Controller ) : permet de protger laccs aux services de la plateforme et aux ressources dune application par dautres applications. Lors du chargement dune application un chier policy est joint : il comporte toutes les permissions associes lapplication. Quand une application tente daccder un service, le systme rcupre le contexte dexcution de lapplication et les permissions qui lui sont associes pour vrier si oui ou non cette application est autorise accder ce service. Une communication scurise base sur TLS : la communication sur le rseau est sujette de nombreuses attaques telles que lcoute de la transmission ou linjection de paquets, etc. TLS (Transport Layer Security ) [HTT] permet de scuriser cette communication en crant un tunnel scuris entre le client et le serveur bas sur des algorithmes cryptographiques. Une authentication des utilisateurs pour une gestion ne de laccs aux res-

1.5. Cas dutilisation des cartes puce serveur Web embarqu

21

sources : en eet la plateforme ore un mcanisme permettant de vrier lidentit de lutilisateur et ses droits daccs : les rles. Un rle dtermine les droits daccs dun utilisateur authenti des ressources protges, telles que les services bass sur les SIO et les ressources Web. Dans la Java Card, deux types dutilisateurs sont dnis : le propritaire de la carte et dautres utilisateurs (comme ladministrateur). Chaque utilisateur a une identit et des droits dirents sur la carte. Lauthentication se fait via des identicateurs appels authenticators. Un identicateur est le service spcialis dans lauthentication qui peut utiliser dirents schmas dauthentication tels quun mot de passe, un code PIN ou une information biomtrique. Ce service peut tre utilis par une application ou un conteneur Web. Les annotations de scurit : elles sont supportes dans Java Card 3 ; il sagit dun mcanisme permettant de scuriser tout ou une partie de lapplication en dnissant une politique dexcution. Les annotations peuvent tre utilises pour protger les applications contre des comportements inattendus de la plateforme. Elles peuvent tre associes des classes ou des mthodes. La plateforme fournit un ensemble dannotations telle que @Sensitive.Confidentiel qui signie que la mthode ou la classe ne doit tre excute que dans un contexte authenti. Cependant, les fournisseurs de la carte ou les dveloppeurs du systme ont la possibilit dimplmenter des annotations additionnelles.

1.5

Cas dutilisation des cartes puce serveur Web embarqu

Lintgration dun serveur Web embarqu introduit de nouvelles problmatiques au domaine des cartes puce. Vis--vis des volutions des tlphones mobiles qui permettent daccder Internet et tous les services oerts sur ce rseau, nous pouvons nous demander lutilit mme dembarquer un serveur Web dans la carte puce. Dans ce paragraphe. Nous rpondons cette interrogation par un ensemble de cas dutilisation [KICLB10, KMM10].

1.5.1

Accs rapide et simple aux services oerts par la carte

Lutilisation des protocoles standards dInternet orent une plus grande exibilit dutilisation et dintgration de la carte puce aux quipements existants et aussi une plus grande aisance dadministration pour les metteurs de carte (industriels et oprateurs). Il est dsormais possible de lire le contenu de sa carte, ou de faire des transactions bancaires ou commerciales en toute scurit partir de nimporte quel terminal contenant un navigateur Web. Les applications sont hberges dans un environnement scuris (la carte puce) et sont donc mieux protges que sur un terminal qui peut facilement tre compromis par un virus ou un programme malicieux. Lmetteur de la carte peut installer plusieurs services accessibles localement sur la carte via un navigateur Web comme tout autre service dInternet. Laccs Internet ou un service disponible sur la carte est donc transparent pour lutilisateur. Il peut tlcharger les applications quil souhaite en accdant une page daccueil qui lui propose une liste de services et des contenus sur Internet. Ces applications peuvent galement tre congures selon ses besoins. En demandant dinstaller une

22

1. Contexte dtude

application, le propritaire de la carte remplit un formulaire et lapplication installe sera congure selon ses besoins indiqus dans le formulaire. Du ct de lmetteur de la carte, lutilisation dun serveur Web embarqu et du protocole HTTP(S) standard permet une administration distance des applications installes sur la carte. En eet, un administrateur peut eectuer un suivi des applications, faire des mises jour ou des installations, condition que la carte soit connecte lInternet. Le serveur Web embarqu est une solution lamlioration de la portabilit des applications et des services en cas de renouvellement de lquipement mobile. En eet, en cas de changement de tlphone, il ne serait plus ncessaire de recharger les applications utilisateur, tandis quil faudrait probablement adapter le contenu la taille de lcran du nouvel appareil.

1.5.2

Amlioration de linterface daccs aux services oerts par lmetteur

Lutilisateur souhaite avoir une interface daccs aux services oerts par la carte et qui soit conviviale et facilement personnalisable. Les standards du Web permettent davoir une exprience utilisateur continue et quivalente celle disponible sur Internet. En utilisant des cartes standards, ces interfaces sont oertes par les lecteurs de carte tels que les tlphones mobiles et elles dirent dun appareil lautre. Lintroduction dun nouveau modle dapplication compltement ddi au mode Web (servlet) ore aux oprateurs ou metteurs de cartes la possibilit de concevoir des interfaces conviviales et standardises pour tous les lecteurs condition que celui-ci dispose dun navigateur Internet. Dans le cas dune carte SIM, par exemple, une gestion locale (dans la carte puce) du carnet dadresses via une interface est facilement ralisable. De plus la forte connectivit de la carte permet denvisager un enrichissement de ce genre dapplications.

1.5.3

Scurit de connexion dun terminal distant une application

Une carte puce serveur Web embarqu est une carte forte connectivit avec une possibilit daccder Internet via un rseau intermdiaire (par exemple, les rseaux 2G/3G pour les cartes SIM). Elle permet galement de renforcer laccs distance des applications critiques. En eet, sa proprit de tamper-resistance permet de garantir lidentit de lutilisateur qui tente daccder distance des donnes critiques (exemple : application bancaire). Dautre part, laspect Web apporte lutilisation du protocole TLS pour la scurisation de bouten-bout entre la carte et son correspondant, ainsi quune gestion ne des utilisateurs (dnition des rles et des permissions), de leur authentication et de laccs aux direntes ressources de la carte. Sajoute cela dautres aspects scuritaires qui ont t renforcs et rajouts dans la Java Card 3 (vricateur de bytecode, gestion de donnes volatiles, rcupration de mmoire). La carte puce serveur Web permet galement de rsoudre le problme de dploiement dapplications dans un environnement non contrl comme un tlphone portable, o des problmes tels que la suppression accidentelle dune application critique par un utilisateur nal peut se produire. Toutefois, des failles dans le dveloppement des applications Web peuvent ouvrir des portes dirents types dattaques Web, tel que linjection de donnes malicieuses dans une page Web, le vol didentiants de session ou laccs non autoris des ressources [OWA07]. Un attaquant peut

1.5. Cas dutilisation des cartes puce serveur Web embarqu

23

Fig. 1.8 Exemple dapplication Java Card 3 : le Disque Virtuel alors russir eectuer du vol dinformations, troubler le bon fonctionnement dun service, accder des ressources non autorises, modier des donnes, etc. Les mcanismes de scurit (rewall, SSL, ..) ne susent pas pour protger les applications Web. En eet, un attaquant peut sattaquer la logique mme des applications, tout en respectant les contrles eectus lextrieur du serveur Web. Les failles dans le dveloppement des applications Web seront les premires vulnrabilits vises par lattaquant. Ainsi, une bonne conception et de bonnes pratiques de dveloppement de lapplication Web simposent.

1.5.4

Exemple dapplication : le Disque Virtuel

Lapplication Disque Virtuel, dveloppe au sein de notre quipe, est un gestionnaire de chiers sur carte puce Java Card 3. Il permet de rcuprer et denvoyer des chiers sur des serveurs FTP distants. Ces chiers peuvent tre chirs la vole par la carte ce qui garantit une scurit maximale en cas de compromission du serveur Web. La carte contient les cls de dchirement des chiers ainsi que ladresse o se trouvent ces chiers. La gure 1.8 illustre le mcanisme de transfert de chiers via notre application. Avant dtre charge dans une carte puce, notre application doit tre signe avec une cl lui permettant davoir des permissions spciques : par exemple, accepter les connexions extrieures. La signature permet donc dappartenir un domaine de protection spcique. Le mcanisme de transfert de chiers est trs simple. Lutilisateur doit possder un serveur FTP sur sa machine pour pouvoir envoyer ou rcuprer des chiers. Par exemple (gure 1.8), pour le tlchargement dun chier, la carte rcupre le chier sur un serveur FTP distant, le dchire la vole puis lenvoie sur le serveur FTP local. Le mcanisme de sauvegarde est simplement linverse du tlchargement : la carte rcupre le chier sur le serveur FTP local, le chire la vole puis lenvoie sur un serveur FTP distant. Lavantage de cette application est davoir un outil permettant de manipuler un grand nombre

24

1. Contexte dtude

de chiers stocks distance tout en garantissant leur intgrit. En cas de compromission du serveur Web o sont stocks les chiers, un attaquant ne pourra pas les utiliser sans la cl de dchirement associe pour chaque chier. On peut ainsi voir ce Disque Virtuel comme un espace de stockage o les donnes ne seraient visibles que par le propritaire de la cl. Lutilisateur peut rcuprer ses donnes partir de nimporte quel terminal distant condition que celui-ci dispose dun serveur FTP local. Notre application utilise des mcanismes de scurit, comme une authentication par code PIN ou encore les annotations. Nous avons rendu cette application intuitive an de montrer les capacits des cartes puce Java Card 3 par rapport aux anciennes. A travers cette application nous avons pu constater la facilit de dveloppement en Java Card 3, compar sa prcdente version Java Card 2.2. Java Card 3 se rapproche beaucoup de Java ME ce qui en fait un outil de dveloppement plus simple adapter pour les dveloppeurs Java (contrairement au dveloppement dapplications Java Card 2.2 o il est ncessaire davoir des connaissances spciques). Les transactions laborieuses mettre en place en Java Card 2.2 ont grandement t simplies en Java Card 3 avec lutilisation des annotations. De plus, contrairement la Java Card 2.2, nous disposons dun ramasse miette automatique pour supprimer les objets inutiliss en mmoire volatile. Le dveloppement a aussi t simpli par le support de nouveau type de donnes comme les types Integer et String.

1.6

Conclusion

La carte puce serveur Web embarqu constitue une grande volution. Louverture de la carte aux standards du Web HTTP/HTTPS ore un accs plus simple et plus rapide aux services quelle ore, et une communication plus scurise grce lutilisation du protocole TLS. Dans la plateforme Java Card 3, les mcanismes de scurit ont t renforcs par une gestion plus ne des utilisateurs et une vrication des applications avant leur chargement (vricateur de bytecode obligatoire) et pendant leur excution (pare-feu, isolation de contexte dexcution, ramasse miette, etc.). Dautre part, cette plateforme ore aux dveloppeurs un moyen de programmation plus simple adopter, qui se rapproche beaucoup de Java ME. Cependant, le dveloppement dapplications Web ncessite dadopter des mesures an de garantir leur scurit et de prvenir certaines attaques. En eet, les attaques sur les applications Web sont trs rpandues (XSS, CSRF, etc.) et leurs consquences peuvent tre trs graves. La carte manipule des donnes trs sensibles. Une mthodologie de dveloppement dapplications Web est ncessaire an dviter quelles soient vulnrables aux attaques Web. De plus une mauvaise implmentation du protocole HTTP, qui ne respecterait pas la spcication, pourrait conduire des comportements inattendus et causer des failles et des vulnrabilits. Dans les deux parties qui suivent nous allons respectivement aborder la scurit au niveau applicatif et au niveau du protocole HTTP implment.

25

Chapitre 2

Les attaques sur carte puce

Sommaire
2.1 Attaques sur cartes puce standards . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 2.2 Attaques physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attaques logicielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attaques combines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 26 27 30 31 32 36

Les attaques Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Exemples dattaques Web les plus rpandues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3

Conclusion

La carte puce ore un environnement scuris pour lexcution de plusieurs programmes et la manipulation de donnes. De plus, elle propose des mcanismes dauthentication trs robustes. La scurit de la carte puce rside dans le fait quelle enferme des donnes scurises que le microprocesseur embarqu est en mesure de traiter en fonction des instructions fournies par le lecteur de carte. An de garantir la scurit de ces oprations, plusieurs dispositifs de protection ont t apports la carte puce. Au niveau matriel, les matriaux constituant le corps de la carte visent faire chouer les attaques chimiques dextraction du micromodule. De plus, tous les composants sont sur le mme silicium ; le microprocesseur et ses capteurs sont enrobs dans une rsine, ce qui rend dicile la pose de sonde pour espionner les bus internes. Au niveau logiciel, lutilisation de la plateforme Java Card apporte une couche supplmentaire de scurit. En eet, lutilisation dune machine virtuelle apporte un contrle supplmentaire en empchant laccs direct aux registres du processeur. De plus, des mcanismes de scurit des applications ont t mis en place, tels que le pare-feu (rewall ), la vrication de type et limpossibilit de construire des pointeurs qui pourraient tre utiliss dans des programmes malicieux an dextraire le contenu de la mmoire. Ces mcanismes empchent quune application hostile cre des dommages dautres applications et au systme. Malgr tous ces mcanismes de scurit, des attaquants peuvent passer outre ces dispositifs de protection et avoir un accs direct la carte. De plus, une carte Java est dite ouverte, c..d des applications peuvent y tre charges et excutes aprs dlivrance (post-usurance). Des attaquants

26

2. Les attaques sur carte puce

peuvent donc exploiter des failles dimplmentation algorithmiques pour introduire des applications qui comportent du code malicieux.

2.1

Attaques sur cartes puce standards

Il existe deux types principaux dattaques sur les cartes puce, les attaques physiques ou matrielles qui se font sur la carte en tant que composant matriel lectronique, et les attaques logiques qui exploitent des failles algorithmiques ou des dfauts dans les mcanismes disolation (dans la Java Card).

2.1.1

Attaques physiques

Ce premier type dattaque suppose une connaissance approfondie dans le domaine de llectronique et de larchitecture des cartes puce. Elle se divise en deux catgories : les attaques invasives et les attaques non invasives.

Attaques invasives : elles ncessitent de retirer physiquement ou chimiquement le circuit lectronique de la carte en plastique, ce qui entrane la destruction de la carte, contrairement aux attaques non-invasives qui naltrent pas son utilisation. Ces attaques sont en gnral menes par des experts et requirent du matriel trs couteux (par exemple une sonde ionique focalise). Elles visent rcuprer le maximum dinformations sur le circuit pour en dduire les mcanismes de scurit mis en place.

Les attaques non-invasives :

contrairement aux attaques vues prcdemment, ce type dat-

taques vise observer ou perturber certaines fonctionnalits physiques de la carte puce sans altrer son fonctionnement. La carte est alors rutilisable aprs lattaque. Nous prsentons dans ce qui suit des exemples dattaques non-invasives. Attaques par conditions anormales : ces attaques consistent perturber le fonctionnement normal de la carte dans le but de modier son comportement. Elles peuvent seectuer en perturbant les entres de la carte comme la tension ou la frquence dalimentation. Ces perturbations peuvent aussi tre externes, en altrant par exemple la temprature. Toutefois, les cartes puce sont gnralement dotes de dtecteurs de conditions anormales qui rendent ce type dattaque dicile raliser. Attaque par canaux cachs : ce type dattaque consiste mesurer un paramtre physique extrieur pendant lactivit de la puce. Ce paramtre peut tre le temps de calcul (Timing Analysis ), le courant (DPA : Dierential Power Analysis, SPA : Simple Power Analysis ) [SCDC+ 11, RO04] ou le champ magntique mis par la puce (SEMA : Simple ElectroMagnetic Analysis, DEMA : Dierentiel Electro-Magnetic Analysis )[Qui11]. Lattaquant mesure alors les variations des paramtres physiques. Aprs analyse des donnes releves, il pourra dduire des informations sur lexcution du logiciel sur la carte, pouvant aller jusqu la divulgation des donnes de scurit (cls cryptographiques ou donnes dauthentication). En eet, les consommations de courant ou de radiation de chaque instruction sont direntes par donne manipule.

2.1. Attaques sur cartes puce standards

27

Attaque par injection de fautes : cest lune des attaques physiques les plus rpandues. Elle sappuie sur une proprit du silicium, qui dans certaines conditions, change de comportement lectrique. Lattaque consiste donc exploiter cette proprit pour perturber lexcution des programmes embarqus dans la puce, tels que les algorithmes cryptographiques, dans le but de les pousser avoir un comportement inhabituel qui pourra tre exploit [Gir07]. Il est possible de perturber le fonctionnement dun circuit lectronique avec des rayonnements tels que les ultraviolets, rayons EM, rayons X, lumire blanche, etc. Le but est de modier le contexte dexcution des applications embarques ou daltrer une partie du contenu de la mmoire. Lattaque en faute peut avoir deux consquences direntes : elle peut tre soit permanente de telle sorte que la valeur dune cellule mmoire soit dnitivement change ; soit transitoire modiant temporairement une opration et/ou la valeur dune variable lors de son transit sur le bus de donnes. Toutefois, la prsence de dtecteurs embarqus dans la puce permet de limiter ces attaques. Les cartes puce sont souvent dotes de contre-mesures adaptes ces attaques, consistant en particulier insrer des dlais alatoires dans lexcution des programmes, de manire les rendre moins facilement observables. Certaines cartes bancaires possdent des dtecteurs dilluminations laser. La spcication Java Card 3 est considrablement plus complexe que les prcdentes, et lobservation des programmes pourrait sen trouver complique, en particulier, en raison de la prsence de multiples ls dexcution (multi-tches).

2.1.2

Attaques logicielles

Elles consistent sattaquer la partie logicielle de la plateforme par injection de donnes ou chargement dapplications malicieuses dans le but de contourner lexcution des applications installes dans la carte puce ou de dvoiler ses secrets (cls, code Pin, etc.). Elles englobent deux types dattaque : les attaques qui exploitent les failles algorithmiques dues soit au non-respect de la spcication ou des failles non abordes dans les spcications elles mmes, et les attaques par chargement dapplications malicieuses dans la carte puce. Direct protocol attaks et le Fuzzing sont deux techniques dattaques prsentes dans [joi09] bases sur la manipulation des commandes de communication entre terminal et carte puce. Le fuzzing consiste envoyer une suite de tests dans le but dobtenir des rponses inattendues retournes par la carte. Le fuzzing permet lattaquant de dtecter des vulnrabilits ou des bogues qui peuvent tre exploits par la suite. Lattaque Direct protocol attacks : consiste envoyer des commandes auxquelles la carte puce ne sattend pas dans son tat courant. Toutefois, de telles attaques ne sont possibles que si le protocole dchanges entre la carte et le terminal est connu. Avec Java Card 3.0, ces attaques demeurent possibles au niveau des changes de commandes cartes. Avec ldition connecte, elles le sont galement au niveau des protocoles rseau, bass sur TCP/IP et HTTP, qui ouvrent de nouvelles voies dattaques (attaques Web), dtailles plus loin. Pour garantir les rgles de scurit (cest--dire intgrit, condentialit et disponibilit), des mcanismes ont t dnis dans les spcications Java Card. En eet, le vricateur de bytecode (bytecode verier ou BCV) vrie quune applet est smantiquement correcte et le pare-feu empche quune applet accde ou modie une autre applet ou une autre ressource qui nappartient pas

28

2. Les attaques sur carte puce

son contexte. Corependant,il existe un mcanisme permettant laccs partir dune applet une rfrence dune instance dnie comme partageable (shareable) appartenant une autre applet. Dautre part les cartes Java Card tant des cartes ouvertes, elles permettent de charger et dajouter de nouvelles applications aprs leur mission. Elles sont donc sensibles des attaques logicielles qui tentent dintroduire des applications qui contournent les mcanismes de scurit mis en place. Dans les versions de Java Card prcdant la version 3.0, le vricateur de bytecode nest pas obligatoire dans la carte ; il est donc possible de charger une application smantiquement incorrecte dans le but de raliser des attaques. Cependant, des travaux [BDH11a, BICL11, BL12] ont montr quil est possible outrepasser la vrication de bytecode en utilisant une combinaison dattaques physique et logique. Dans la suite, nous prsentons quelques exemples dattaques logicielles pures.

Attaque par confusion de type.

Une des briques de scurit de la Java Card repose sur la

sret du typage [ICL10], normalement assure par le vricateur du bytecode avant la transformation dune applet en chier CAP. Cependant, dans le cas o le chargement des applications sur la carte ne se fait pas uniquement par ses fabricants (exemple : un tiece de conance), le chier CAP peut tre altr avant son chargement dans la carte. Dans une attaque par confusion de type, prsente par Mostowski et al. [MP], un tableau doctets est transform en un tableau dentiers courts permettant ainsi laccs une zone de mmoire plus grande (pouvant appartenir dautres applets par exemple). Pour cela, lattaque abuse de mcanisme de partage dinterface. Pour mieux comprendre cette attaque, supposons deux applets : une applet serveur qui expose une interface de partage, et une applet client qui accde cette interface. Le serveur envoie la rfrence de son tableau doctets lapplet client via la mthode giveArray(), lapplet client la renvoie ensuite via linterface mal type (accessArray()) retournant ainsi un tableau dentiers courts pour un tableau doctets.

Listing 2.1 Interface de lapplet client

1 2 3 4

public interface Interface extends Shareable { public byte [ ] giveArray ( ) ; public short accessArray ( byte [ ] MyArray ) ; }

Listing 2.2 Interface de lapplet serveur

1 2 3 4 }

public interface Interface extends Shareable { public byte [ ] giveArray ( ) ; public short accessArray ( short [ ] MyArray ) ;

Cette mme attaque peut t ralise dune autre faon en exploitant linstruction NOP dnie dans la spcication Java Card comme neectuant aucune action. Elle consiste charger un programme auto modiable dans la carte permettant de lire ou dcrire nimporte o dans la mmoire de la carte. Il est ainsi possible de changer certaines instructions par linstruction NOP. Dans

2.1. Attaques sur cartes puce standards

29

lexemple prsent dans listing 2.3, les instructions des lignes 7 10 du code binaire (listing 2.4) sont remplaces par des instructions NOP. Ainsi, la dernire valeur empile devient la rfrence vers le tableau array (instruction aload_1). La mthode retournera donc une rference vers un tableau dentiers courts.

Listing 2.3 Exemple dattaque par instruction NOP

1 2 3 4 5

public short g et M y Ad d r ess t ab B y te ( byte [ ] array ) { short foo =( byte ) 0 x55AA ; array [ 0 ] = ( byte ) 0 xFF ; return foo ; }

Listing 2.4 Code binaire

1 2 3 4 5 6 7 8 9 10 11 12

public short g et M y Ad d r es sT ab B y t e ( byte [ ] array ) { 03 // flags : 0 max_stack : 3 21 // nargs : 2 max_locals : 1 10 AAbspush 0 xAA 31 sstore_2 19 aload_1 03 sconst_0 02 sconst_m1 39 sastore 1 E sload_2 78 sreturn }

Attaque par abus des instructions manipulant des membres statiques.

An doptimiser

la phase ddition des liens, des symboles sont utiliss dans le chier CAP pour le rfrencement des mthodes ou des champs. Ces symboles sont lists dans le composant Constant Pool et les adresses relatives chaque symbole rsoudre sont contenues dans le composant Reference Location. Ldition des liens consiste vrier que chaque oprande avec un symbole dni dans le composant Constant Pool pointe vers un lment existant avec un type attendu par loprande. Pour des raisons de capacit mmoire et de gain de performance, il est possible que le parefeu ne contrle pas les accs aux lments statiques (getStatic, putStatic et invokeStatic). Cette exception au principe disolation du pare-feu provient du fait que certains objets statiques du systme (tampon APDU, mcanisme dexception, etc.) doivent tre accessibles dans tous les contextes. En absence du vricateur bytecode, cette proprit peut tre exploite par un attaquant pour modier des rfrences sur des lments statiques an daccder des ressources appartenant un contexte de scurit dirent de celui de lapplet courante. Tiana et al. proposent une librairie Java, le CapMap [RBL12], permettant de drfrencer dans le composant Reference Location, le

30

2. Les attaques sur carte puce

paramtre dune instruction getStatic ; ce paramtre est ensuite utilis pour lire des parties de la mmoire non accessible dans un usage normal. Ralisation dun cheval de Troie dans une carte (EMAN). EMAN est un ensemble dattaques ralises dans lquipe SSD de luniversit de Limoges. Elle exploite lattaque prcdente an dutiliser les instructions getStatic et putStatic pour parcourir la mmoire et modier des applets installes. Lattaque EMAN1 [ICL10] consiste raliser un cheval de Troie en utilisant des applets malicieuses qui peuvent inclure des instructions ne respectant pas les rgles de typage de Java. Cette attaque a pour but de modier le ux dexcution dune applet prsente dans la carte, en recherchant un motif dans la mmoire de la carte et de le modier. Grce cette attaque, il est, par exemple, possible de supprimer la vrication du code PIN dans une applet, en remplaant dans la mmoire, le code associ linstruction qui gnre une exception en cas de code PIN non-valide par le code de linstruction NOP. Lattaque EMAN2 [BICL11] est base sur le mme principe que lattaque prcdente. Son objectif est de renvoyer le pointeur dexcution une adresse bien dnie, et de modier le registre contenant les adresses de retour des mthodes par ladresse dun tableau contenant un code malicieux.

2.1.3

Attaques combines

Sur la catgorie des attaques prcdentes, la spcication Java Card 3.0 change considrablement la donne. Grce aux nouveaux mcanismes de scurit disponibles sur ldition connecte, en particulier la vrication de bytecode qui est pratique systmatiquement lors du chargement des programmes sur la plateforme et le ramasse-miette qui est automatique. Les attaques logiques visant spciquement Java Card deviennent plus diciles mettre en uvre. Cependant pour russir contourner le vricateur de bytecode, un attaquant peut faire une combinaison dattaques matrielle et logicielle. Cette combinaison consiste charger dans la carte des applications smantiquement correctes qui sont par la suite modies par une attaque physique pour gnrer un code malicieux permettant de raliser des attaques logiques. Lapplication modie est appele mutant. La gnration de mutants est un nouvel axe de recherche [BDH11a, BICL11, BL12]. Nous prsentons quelques exemples de cette catgorie dattaques dans ce qui suit. Perturbation de linstruction checkcast. Barbu et al. proposent [BDH11a] une attaque par perturbation de linstruction checkcast permettant dutiliser une arithmtique de pointeur sur une plateforme Java Card. Lattaque commence par crer une confusion de type. Linstruction checkcast de la JCVM est utilise dans le but de vrier la validit dune conversion de type. Les auteurs appliquent une attaque par injection de faute (attaque physique) sur cette instruction dans le but de gnrer une conversion incorrecte qui lancerait une exception chaque excution. Grce cette exception les auteurs sont parvenus synchroniser lactivation du faisceau laser et le fetch du code natif conditionnant le succs ou lchec de la conversion de type. Une fois la perturbation russie, lattaquant peut donc accder un mme objet x de type X par un champs instance dune classe dirente X ou Y. Il est ainsi possible dutiliser une arithmtique de pointeur comme dans le langage C ce que le langage Java proscrit formellement.

2.2. Les attaques Web

31

Perturbation des donnes contenues dans la pile doprandes.

La machine virtuelle Java

dnit une pile doprandes o sont sauvegards les paramtres et les retours des instructions composant un bytecode. Par exemple, lexcution de linstruction iadd oprant laddition de deux entiers de type int, consiste retirer deux lments au sommet de la pile des oprandes, puis eectuer une addition sur ces deux valeurs dont le rsultat de laddition est ajout au sommet de la pile des oprandes. Contrairement lattaque prcdente qui utilise lattaque en faute pour perturber une instruction, les auteurs dans [BDH11b] sintressent la perturbation des donnes manipules. Ces donnes sont perturbes par une attaque physique lors de lempilement des oprandes dans la pile. Les auteurs proposent principalement trois attaques. La premire consiste injecter une faute lors de lempilement dune variable boolenne prcdant lexcution dun saut conditionnel (cest dire un bloc if en langage Java) an dinuencer la prochaine instruction excuter. La seconde attaque permet de raliser une confusion de type avec une forte probabilit en combinant cette attaque physique avec une application malicieuse crant une multitude dinstances dune classe donne. Enn, la dernire attaque montre dune manire similaire comment crer une confusion entre deux instances dune mme classe, ou plus prcisment entre deux instances de deux classes implmentant une mme interface.

2.2

Les attaques Web

Les dbuts du World Wide Web (ou WWW) furent relativement statiques. Le serveur Web avait pour seule fonction de fournir des chiers statiques comme des pages Web, crites en HTML. Au l du temps, les dveloppeurs ont intgr laccs un contenu dynamique (JavaScript, AJAX, etc.). Depuis, les applications Web sont devenues un moyen dominant daccs des services en ligne. Le nombre et limportance des applications Web augmentent rapidement, mais au mme temps, limpact des vulnrabilits devient de plus en plus important. Il existe de nombreuses attaques sur les services Web ; des organisations [OWAa, Mit, WAS] tentent deectuer un classement de ses attaques selon les plus rpandues et les plus dangereuses, mais cette tache reste dicile raliser vu que beaucoup de sites vitent de dvoiler quils en ont t victimes. Lintgration du Web au monde de la carte ouvre de nouvelles portes des attaques dj existantes sur le Web standard [KICL10]. Ces direntes attaques sont gnralement lies des vulnrabilits des applications. Elles peuvent provoquer des comportements indsirables tels que lindisponibilit partielle des services, la mise en pril des donnes condentielles, voir mme la perte de contrle au prot dun utilisateur malveillant. Les applications Web pour carte puce ne sont pas concernes par toutes les vulnrabilits Web standards. Par exemple : lattaque par injection de code SQL peut tre carte, vu que les bases de donnes et le langage SQL ne sont pas supports dans les cartes puce. Cependant, dautres attaques restent possibles, notamment les attaques par injection de code (XSS) qui sont trs puissantes et trs rpandues. La meilleure faon de se prmunir des attaques Web est de tenir compte de la scurit depuis les phases de conception et de dveloppement des applications Web en appliquant quelques bonnes pratiques.

32

2. Les attaques sur carte puce

2.2.1

Exemples dattaques Web les plus rpandues

Dans cette section nous citons quelques exemples dattaques les plus rpandues, identies par lorganisation OWASP [OWAa] qui a slectionn les 10 attaques les plus rpandues, recenses en 2010 (tableau 2.1). Nous prcisons galement dans quelle mesure certaines dentre elles ne peuvent pas se produire sur les cartes puce et nous proposons quelques recommandations de dveloppement pour se prmunir de chaque attaque. Classement A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 Risques Injection de commandes Failles Cross Site Scripting (XSS) Violation de gestion dauthentication et de session Rfrence directe un objet non scurise Cross Site Request Forgery (CSRF) Conguration non scurise Stockage non scuris Manque de restriction daccs URL Communications non scurises Redirection et renvoi non valids

Table 2.1 Slection dOWASP des dix vulnrabilits les plus rpandues en 2010

1. Injection de commandes Lattaque par injection consiste injecter du code malicieux dans des entres prsentes lutilisateur [KGJE09]. Ce code malicieux est ensuite interprt par le serveur comme des instructions qui peuvent consister en des requtes dinterrogation de base de donnes (SQL), des commandes systme, ou des commandes daccs des chiers. Cette attaque concerne moins la carte puce dont laccs est beaucoup plus rduit quun dispositif standard (ordinateur) ; de plus, pour des contraintes de ressources, le stockage des chiers, les bases de donnes et le langage dinterrogation de base de donnes ne sont pas prvus dans la carte puce. Cependant pour se prmunir de cette attaque, le dveloppeur doit ltrer toutes les donnes entres par lutilisateur pour empcher que certains caractres qui peuvent avoir un autre sens que celui attendu puissent tre interprts dans le serveur ou le systme. 2. Cross Site Scripting (XSS) XSS est lune des attaques les plus rpandues sur le Web. Elle peut tre considre comme une attaque par injection [HTL+ 05], sauf que dans ce cas le code malicieux est interprt au niveau du client (navigateur Web). Elle exploite des failles dans des applications Web qui manipulent des donnes externes lapplication sans les ltrer au pralable. Elle consiste injecter du code malicieux (des scripts souvent crits en JavaScript) dans la page Web dune application vulnrable. Si lapplication retourne une ressource contenant ce code malicieux alors ce dernier sera excut au niveau du client (navigateur Web). Le but de cette attaque est gnralement de rcuprer les identiants de session, [Gar09], rediriger lutilisateur vers un domaine qui est sous le contrle de lattaquant, causer un dnis de service ou modier les pages Web de lapplication.

2.2. Les attaques Web

33

La meilleure prvention contre ce type dattaque consiste principalement prvoir un encodage des donnes en sortie qui doivent tre converties en leur encodage HTML quivalent an de garantir que le navigateur Web ne traite pas certains caractres, potentiellement malicieux, comme une partie de la structure du document HTML mais plutt comme une partie de son contenu [OWAa]. Nous nous intressons particulirement cette attaque qui fera lobjet du chapitre suivant. 3. Violation de gestion dauthentication et de session Lauthentication joue un rle important dans la scurit des applications Web. Elle consiste allouer des privilges particuliers daccs des services Web, selon lidentit de lutilisateur. La gestion des sessions des utilisateurs authentis une application consiste garder en mmoire des informations relatives lutilisateur connect (par le biais des cookies). Les attaques sur la violation de session consistent : utiliser la force brute en testant un ensemble didentiants et mots de passe jusqu arriver aux valeurs acceptes [SWS02], intercepter les donnes de session enregistres en mmoire (les cookies) en utilisant une attaque XSS par exemple ou encore en forgeant un jeton de session valide. Ces attaques exploitent des faiblesses dans les mcanismes dauthentication, souvent introduites par des fonctions auxiliaires dauthentication, telles que la dconnexion, la gestion de mots de passe, les questions secrtes, les mises jour des informations relatives aux comptes, les messages derreurs. Pour viter le risque de violation de sessions il est ncessaire de refuser tout identiant de session reu partir dune URL an de se prmunir des attaques par xation de session 4 [JBSP11]. Il faut galement commencer le processus douverture de session par une page chiffre et un nouveau jeton de session. Le jeton de session doit tre regnr chaque nouvelle authentication. Il est galement recommand de mettre une limite la dure de validit dune session au-del de laquelle une dconnexion automatique est eectue si lutilisateur est inactif.

4. Rfrence non scurise un objet Il est dangereux dacher aux utilisateurs, via une URL ou un paramtre dans un formulaire, des rfrences des objets internes tels quun chier, un rpertoire, une cl, etc. Un attaquant peut manipuler le paramtre dans le but de violer la politique de contrle daccs mise en place et daccder des ressources non autorises. Dans lexemple suivant si le paramtre UserID est pass en paramtre dune URL alors il sut de le changer pour rcuprer le numro de compte cartID de nimporte quel utilisateur.

Listing 2.5 rfrence non scurise cartID

1 2 3

int cartID = Integer . parseInt ( request . getParameter ( " UserID " ) ) ; String query = getcartID ( UserID ) ; out . println ( " your cartID is " + cartID ) ;

4. Lattaque par xation de session exploite des vulnrabilits dapplications permettant un utilisateur de xer lidentiant de session dun autre utilisateur

34

2. Les attaques sur carte puce

La meilleure protection contre cette attaque est de ne jamais exposer de rfrences directes aux utilisateurs vers des implmentations internes dobjets. Il faut utiliser des index ou des quivalences par rfrence indirecte. Pour plus de scurit, la mthode dacceptation des bonnes valeurs Accept known good permet de vrier que les donnes appartiennent un ensemble de valeurs valides qui peuvent tre dnies par des critres comme : le type, la longueur, la syntaxe, etc. Toutes les donnes qui ne correspondent pas ces critres devraient tre rejetes. Cependant, si une rfrence directe un objet doit absolument tre utilise, il faut demander lutilisateur de ressaisir son identiant et mot de passe avant de pouvoir y accder.

5. Cross Site Request Forgeries (CSRF) Cross-Site Request Forgery (CSRF) est une attaque trs proche de lattaque XSS [Gol08] car elle consiste galement inciter une victime charger une page qui contient une requte malicieuse. Son objectif est dutiliser lidentit et les privilges dune victime pour eectuer une fonction indsirable au nom de cette victime [BGH+ 12]. Autrement dit ce type de vulnrabilit peut potentiellement permettre de raliser une action non autorise dans une application Web avec le droit dun utilisateur lgitime et ce, sans son consentement. Lattaque est ralise quand un utilisateur authenti un site (site dune banque par exemple) clique sur un lien malicieux envoy par lattaquant, qui masque dans ce lien une requte vers lapplication laquelle lutilisateur est authenti (transfert dargent vers le compte de lattaquant par exemple). Le lien malicieux peut tre marqu dans des balises dimages, et lattaquant doit inciter lutilisateur authenti sur le site bank.com consulter ce lien, en lui faisant croire quil sagit dune image. <img src="http://bank.com/transfer.do?acct=pirate&amount=100000" width="1" height="1" border="0"> Quand lutilisateur clique sur ce lien, une petite fentre sache indiquant que limage na pas pu tre ache et la requte de transfert dargent est envoye au serveur sans que lutilisateur ne sen aperoive. Cette attaque peut avoir plusieurs consquences, telles que : le changement de mot de passe, lachat en ligne, lachat daction sur un site boursier, lenvoi de-mails, etc. Les sites qui implmentent des requtes POST sont moins exposs. En eet, les requtes GET sont facilement prdictibles car les informations transitent dans lURL ; il sut donc de forger une URL an denvoyer une requte valide au serveur Web [OWAa]. Lutilisation dun jeton (token) est un moyen de protger la session de lutilisateur. Le jeton permet de vrier la validit de lorigine dune requte. Le jeton doit tre gnr alatoirement pour viter quil soit prdictible par un attaquant et plac de faon cache dans le formulaire pour que lutilisateur ne dtermine pas son existence. Il est rgnr chaque requte et si le jeton envoy par le navigateur est dirent de celui stock dans lapplication alors la requte est rejete. Pour plus de scurit, une dure de vie peut tre ajoute au jeton de session, pour dterminer un temps au-del duquel il sera expir. Une dure minimale aussi, suppose que la saisie a t faite par un attaquant automatique (robot).

6. Conguration non scurise

2.2. Les attaques Web

35

Cette faille regroupe lensemble des vulnrabilits qui peuvent tre dvoiles par larchitecture des serveurs ou des applications. Le moyen le plus rpandu est les messages derreur. Les messages derreurs peuvent dvoiler dimportants dtails sur limplmentation de lapplication ou du systme qui permettraient un attaquant de dtecter et dexploiter des vulnrabilits. Un exemple simple est celui de lauthentication. Si une application gnre des messages derreur qui spcient si cest le mot de passe ou lidentiant qui est incorrect alors une attaque par force brute pour dtecter lidentiant et le mot de passe est simplie. Si le message derreur indique que le mot de passe est incorrect, alors lattaquant en dduit que lidentiant quil a forg est correcte et il va donc le xer et continuer son attaque sur uniquement le champ associ au mot de passe. Pour prvenir cette faille, une discipline dans la gnration des erreurs est indispensable. Il ne faut jamais acher lutilisateur des messages derreur dtaills contenant des informations de dbogage ou des informations relatives aux chemins. Il est important de crer un gestionnaire derreurs par dfaut qui retourne lutilisateur des messages derreur correctement nettoys. Et pour viter quun attaquant dduise des informations partir dune estimation du temps de rponse de chaque opration, il serait utile dappliquer un temps de rponse alatoire pour toutes les transactions. 7. Stockage de donnes non scuris Une faille de stockage de donnes non scurises existe si une application Web ne protge pas correctement les donnes sensibles, telles que les numros de cartes de crdit, de scurit sociale, les informations dauthentication, avec un algorithme de chirement ou de hash appropri. Dans ce cas, un attaquant peut les rcuprer ou les modier. Cette attaque concerne moins les cartes puce qui utilisent des algorithmes de chirement avec des cls de chirement bien protges (aspect "tamper-resistent" de la carte). La recommandation que nous pourrions faire dans ce cas est dutiliser uniquement les algorithmes de chirement prsents dans la carte. 8. Dfaillance dans la restriction des accs URL Un attaquant peut tenter daccder par une URL des ressources caches non accessibles au public ou des rpertoires contenant des informations sensibles. Un pirate peut sy prendre par force brute en utilisant en gnral des conventions de nommage communes et des emplacements standards pour la plupart des applications. Laccs ces chiers permet lattaquant daccder des informations sensibles pour une application Web, et dapporter des modications dans le but davoir des droits daccs ou des autorisations pour certaines transactions sensibles, etc. Il arrive que les dveloppeurs limitent leur protection la couche prsentation, en cachant aux utilisateurs non autoriss, des URL et des liens associs certaines pages rserves des utilisateurs particuliers. Cette protection ne sut pas. Si un attaquant intercepte ou dcouvre lexistence de cette URL, il pourra accder des donnes ou fonctions auxquelles il nest pas autoris. Les applications Web doivent renforcer le contrle daccs chaque URL et chaque fonction mtier et bloquer les accs tous les chiers que lapplication nutilise pas. Il est ncessaire dappliquer un ltre autorisant uniquement les types de chiers qui peuvent tre utiliss, par exemple chiers HTML, et bloquer les dirents essais daccs des chiers dvnements (logs), aux chiers XML, etc.

36

2. Les attaques sur carte puce

Lapplication du mcanisme de contrle daccs aux URL et aux fonctions mtiers consiste vrier chaque tape, les rles et les droits associs aux utilisateurs chaque traitement. Cette attaque sapplique aux cartes puce serveur Web embarqu uniquement dans certaines mesures. En eet, les serveurs embarqus sont simples et ne peuvent pas contenir autant de donnes quun serveur standard. De plus, il nexiste pas de console dans la carte puce, il nexiste donc pas un moyen daccder au systme. Par consquent, des URLs caches seraient peu probables. Cependant, une administration distance des applications tant possible, alors des failles pourraient tre exploites ce niveau.

9. Communication non scurise Un attaquant peut couter le trac dun rseau dans lobjectif dintercepter les informations qui y transitent [SWS02], notamment : les lments dauthentication et les donnes sensibles changes. Cette attaque est gnralement utilise pour pouvoir collecter des informations permettant deectuer dautres attaques plus nfastes. Pour viter ce genre de vulnrabilits, lapplication doit chirer correctement les communications authenties et sensibles. Il est ncessaire dutiliser TLS sur toutes les connexions authenties et durant la transmission des donnes sensibles, telles que les donnes dauthentication, numro de carte bancaire, etc.

10. Redirection et renvoi non valids Une application Web peut contenir des redirections vers les pages Web qui la composent. Souvent ces redirections incluent des paramtres fournis par lutilisateur dans lURL de destination. Si ces paramtres ne sont pas valids, alors lapplication est vulnrable une attaque pouvant rediriger la victime vers un autre site Web. Cette attaque est utilise gnralement dans le but de rediriger la victime vers un site malveillant sous le contrle de lattaquant ou passer outre les contrles de scurit et accder des donnes ou des fonctions non autorises. Pour se prmunir de cette attaque, il faut congurer la redirection de telle sorte quelle se limite uniquement des pages locales lapplication. Il faut galement viter dutiliser les paramtres parvenant dun utilisateur dans la dnition des URLs cibles. Si utiliser des paramtres utilisateurs est ncessaire alors il est recommand de valider chaque paramtre pour vrier quil est autoris en utilisant une table de correspondance entre les paramtres utilisateurs et les pages autoriser.

2.3

Conclusion

Dans ce chapitre nous avons prsent les dirents types dattaques possibles sur la carte puce. Avec lintgration dun serveur Web, la carte puce souvre un nouveau volet dattaques : les attaques Web. La plupart des attaques Web que nous avons prsentes sont causes par des donnes malicieuses introduites dans des champs ou des paramtres accessibles lutilisateur. Les attaques par injection de code et particulirement les XSS, sont les plus rpandues sur le Web, elles exploitent des failles dans des applications qui ne vrient pas les entres provenant dun utilisateur et ne ltrent pas les sorties de lapplication qui sont retournes vers le client (navigateur). Lapplication

2.3. Conclusion

37

devient dans ce cas un point de relais dattaques, ce qui peut mettre en doute la conance de lutilisateur en sa carte puce. Les XSS sont relativement faciles raliser mais leurs consquences peuvent tre trs graves (rcupration dinformations, modication de la logique de lapplication, dnis de service). Nous nous sommes particulirement intresss ce type dattaque que nous prsentons plus en dtail dans le chapitre suivant.

38

2. Les attaques sur carte puce

39

Deuxime partie

Scurit des applications Web Java Card 3

41

Chapitre 3

Les attaques Cross Site Scripting

Sommaire
3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.2 3.3 Injection volatile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Injection persistante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 41 43 44 45 46 47 52

Porte et exploitation des attaques XSS . . . . . . . . . . . . . . . . . Solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 3.3.2 Solutions ct client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Solutions ct serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4

Conclusion

3.1

Description

La Cross Site Scripting (appel aussi XSS) consiste injecter du code malicieux dans une entre dune application Web et faire interprter cette entre dans le navigateur Internet dune victime [Kle]. Le but de cette attaque est gnralement de transfrer des donnes une tierce personne (un attaquant), de provoquer un comportement inattendu de lapplication Web ou de causer une indisponibilit de service. Une XSS peut cibler nimporte quelle application Web indpendamment du langage de programmation utilis (Java, PHP, . . . ). Elle exploite des sites Web vulnrables qui manipulent ou achent dynamiquement du contenu utilisateur (du code HTML ou des scripts) sans eectuer de contrle et dencodage de ce contenu au pralable. Il existe en gnral deux faons dinjecter du code malveillant dans une page Web ache lutilisateur [KGJE09]. Dune manire persistante (XSS persistante) ou non persistante (XSS volatile).

3.1.1

Injection volatile

Elle consiste injecter des donnes malicieuses dans un lien qui sera envoy la victime. Quand la victime clique sur ce lien, le code inject sexcute sur son navigateur Web. Pour illustrer cette attaque, supposons une application Web vulnerableSite.net qui fournit une page Web contenant

42

3. Les attaques Cross Site Scripting

un champ nom o lutilisateur pourra introduire son nom dutilisateur : nom_de_la_victime. Lenvoi de cette donne au serveur correspond lURL suivante :

http://www.vulnerableSite.net/?nom=nom_de_la_victime Si lapplication retourne dynamiquement un message qui contient les donnes entres par lutilisateur, par exemple : Bonjour nom_de_la_victime, sans les avoir vries et ltres au pralable, alors lapplication est vulnrable une XSS volatile. Pour vrier la prsence de cette vulnrabilit il sut de remplacer dans lURL, nom_de_la_victime par le script <script>alert(XSS)</script>. La gure 3.1 montre que ce script a bien t interprt et une fentre de dialogue sache.

Fig. 3.1 Achage dune fentre de dialogue par un script

Maintenant que nous avons dtect une vulnrabilit dans lapplication, nous pouvons lexploiter en injectant un code plus malicieux pour rcuprer des informations sensibles. Linterprtation du code JavaScript inject dans le lien ci-dessous permet de rcuprer les cookies de la victime.

http://www.vulnerableSite.net/?nom= <SCRIPT> document.location=http://site.pirate/cgibin/ script.cgi?+document.cookie </SCRIPT> Pour faire excuter ce script, lattaquant doit convaincre lutilisateur de cliquer sur ce lien en utilisant nimporte quel moyen de phishing 5 ou dingnierie sociale 6 . Quand lutilisateur clique sur ce lien, le code JavaScript sexcute dans son navigateur Web et ses cookies de session sont envoys au site site.pirate. Lattaquant peut dsormais utiliser les cookies rcuprs pour eectuer dautres attaques ou rcuprer dautres donnes, en usurpant lidentit de la victime. Cependant, prsente de cette manire, lURL peut facilement tre dtecte comme douteuse. Pour cela, il existe dirents moyens permettant de masquer lattaque, telle que lencodage ou le raccourcissement de lURL.
5. Technique qui consiste faire croire une victime quelle sadresse un tierce de conance an de lui soutirer des renseignements personnels. 6. Pratique qui consiste exploiter les failles humaines et sociales de la victime pour obtenir des informations.

3.1. Description

43

3.1.2

Injection persistante

Elle ne reprsente que 25% des attaques XSS, mais elle est beaucoup plus puissante que les attaques XSS volatiles. Lattaquant enregistre de manire permanente le code malicieux dans une ressource gre par lapplication Web, telle quun chier ou une base de donnes. Lattaque se ralise ultrieurement, quand une victime demande laccs une page dynamique qui accde cette ressource. Nous avons ralis cette attaque sur notre application Java Card 3 : Disque virtuel. Nous prsentons dans ce qui suit comment cette attaque a russi rendre lapplication presque inutilisable. Exemple dattaque XSS sur lapplication Java Card 3 Disque Virtuel Lapplication Disque Virtuel prsente dans le chapitre prcdent permet daccder des chiers stocks sur des serveurs FTP distants. Ces chiers peuvent tre chirs la vole par la carte, ce qui garantit une scurit maximale en cas de compromission du serveur Web. La carte contient les cls de dchirement des chiers, ainsi que ladresse o se trouvent ces chiers. Lapplication ore une interface qui sache sur un navigateur Web install sur la machine locale laquelle la carte puce est connecte (gure 3.2). Via cette interface, un ensemble de services est oert. Par exemple lutilisateur peut accder la liste des noms de chiers stocks dans des serveurs distants, ajouter ou supprimer un chier. Elle ore aussi la possibilit daccder la liste des serveurs o sont stocks ces chiers, dajouter ou de supprimer des serveurs.

Fig. 3.2 Attaque XSS persistante

En supposant que cette application ne prvoit aucun ltrage des entres, nous avons russi causer un dni de service sur lapplication. Nous avons utilis une attaque XSS persistante qui a rendu lapplication pratiquement inutilisable. Dans le champ destin ajouter un nom de serveur, nous avons insr du code JavaScript dont linterprtation redirige lutilisateur vers un autre site google.com par exemple. Le script est le suivant :

44

3. Les attaques Cross Site Scripting

<SCRIPT>document.location=http://www.google.com?+document.cookie </SCRIPT> La liste des serveurs tant stocke en mmoire persistante et utilise dynamiquement par un ensemble de pages Web de notre application, il sut que lutilisateur tente de se rendre sur une de ces pages pour que le script soit excut et que lutilisateur soit redirig vers google.com. Ainsi, son application devient inutilisable. Pour la rutiliser correctement, il est ncessaire de recharger une nouvelle instance de lapplication dans la carte. Nous pouvons imaginer dautres scnarios plus complexes qui permettraient de rcuprer des informations sensibles.

3.2

Porte et exploitation des attaques XSS

Les dernires applications Web orent de larges possibilits daccs aux dirents lments dune page Web, notamment grce lutilisation du JavaScript. Souvent lattaquant tente dexploiter ces dirents points dentre an davoir des privilges (ou dlever ses privilges) ou de prendre le contrle du navigateur Web dune victime. Linjection de codes malicieux dans une application Web peut avoir des consquences plus ou moins graves, telle quune simple dguration du site, une redirection de lutilisateur vers un site sous le contrle de lattaquant, le vol dinformations sensibles ou laccs des privilges. Plusieurs sites Web, dont certains sont trs populaires, ont t victimes dattaques XSS. Souvent les victimes vitent de dvoiler quelles ont subi des attaques, notamment quand il sagit de site Web commerciaux. En 2005, des pirates ont exploit une vulnrabilit dans gmail.com pour usurper lidentit dabonns lgitimes et compromettre leur domaine. En 2006, le site CBS News a t victime de la publication dune fausse information. En 2008, Sarah Palin, en pleine campagne prsidentielle aux tats Unis, a t victime dune attaque XSS sur sa boite e-mail Yahoo, et des informations slectionnes partir de son compte ont t postes sur Wikileaks. Le site de la compagne prsidentielle 2008 de Obama a aussi t victime dune redirection vers le site Web de son adversaire Hillary Clinton [XSSa]. Un grand classique des XSS, qui a aect plusieurs sites Web de grande notorit comme paypal.com [XSSc] et quelques sites relevant du domaine defense.gouv.fr [XSSb], consiste rediriger les utilisateurs vers un faux site (une copie de loriginal) qui est sous le contrle de lattaquant. Souvent lutilisateur ne fait pas attention lURL de la page Web quil consulte, il risque alors dentrer des informations condentielles (coordonnes bancaires par exemple) dans ce faux site, qui vont tre ensuite envoyes lattaquant. Des rseaux sociaux comme FaceBook, MySpace, etc. ont galement rvl des vulnrabilits dans le pass. Ces vulnrabilits sont lies une faiblesse ou une absence de ltrage des donnes. Dans FaceBook par exemple la vulnrabilit se situait au niveau des commentaires associes aux photos. XSSF [Lud11] est un logiciel dattaques XSS. Il permet de dtecter des failles XSS et de dmontrer leur dangerosit. XSSF commence par crer un lien avec les victimes an denvoyer des attaques par la suite. Un ensemble dattaques (alerte, vol de cookie, keylogger 7 , tabnapping 8 ,
7. dispositif qui charge les frappes de touches du clavier et les enregistre, linsu de lutilisateur 8. modier, linsu de lutilisateur et sans aucune intervention de sa part, le contenu ach dans un onglet

3.3. Solutions existantes

45

etc.) est stock sous forme dun module MSF (chier structur contenant le code excuter). Ces travaux ont dmontr travers de simples injections, les possibilits normes des attaques XSS, qui peuvent aller jusqu lexploitation distance des failles du systme dexploitation et la prise de contrle (totale) dune machine distante. Cette prise de contrle est possible ds lors que le navigateur ou lun de ses plugins est vulnrable une faille de scurit. Le systme dexploitation Android (utilis sur les smartphones) a galement t victime dune vulnrabilit XSS. Thomas Cannon [Tho10] a dtect une vulnrabilit qui permet de rcuprer depuis un site Web malicieux (ou vulnrable aux XSS) nimporte quelle information stocke sur la carte SD du tlphone. Dans [MSP11] est prsente une attaque XSS permettant linstallation non assiste des applications arbitraires de Android Market. Souvent les attaques XSS, notamment les volatiles, ncessitent dutiliser des mthodes permettant dinciter lutilisateur cliquer sur un lien hostile. Parmi ces mthodes, les techniques dingnierie sociale (lenvoi dun e-mail semblant provenir dun contact sr, ou faire croire une situation durgence, etc), le clickjacking 9 , qui consiste utiliser des liens invisibles ou cachs sous des liens lgitimes, ou le DNS rebinding 10 susceptible de permettre de transformer le navigateur de la victime en un simple relai entre le rseau local et une machine contrle par lattaquant. An de masquer la prsence dun code qui pourrait faire douter lutilisateur, les pirates utilisent des techniques dencodage des URL [Gar09]. Par exemple, plutt que dinviter la victime visiter la page suivante o nous pouvons apercevoir le code JavaScript : index.php?query=enter+your+search+terms+here&type=advanced&results= 10&searchType=3&action=search&page=33"><script>alert(document.cookie) </script> un attaquant va utiliser un encodage comme suit : index.php?query=enter+your+search+terms+here&type=advanced&results= 10&searchType=3&action=search&page=%33%33%5c%22%3e%3c%73%63%72%69%70% 74%3e%61%6c%65%72%74%28%64%6f%63%75%6d%65%e%74%2egetElementById(\OT1\ textquoterightmyScript%63%6f%6f%6b%69%65%29%3c%2f%73%63%72%69%70%74%3e

3.3

Solutions existantes

Les vulnrabilits XSS sont connues depuis plusieurs annes, mais elles sont sous estimes par beaucoup de dveloppeurs et dutilisateurs qui pensent quelles permettent simplement dacher une boite de dialogue, alors quil ne sagit que dune preuve de concept. Nous avons vu dans la section prcdente le potentiel des attaques XSS et que beaucoup de sites Web en ont t victimes dattaques dues une vulnrabilit XSS. Pendant que les attaques se multiplient sur le Web, de nombreuses recherches tentent de trouver des solutions pour dtecter ou prvenir ce type de vulnrabilit. Parmi les solutions proposes, nous avons celles bases du ct client (navigateur Web), et dautres du ct serveur (serveur o lapplication Web est installe).
9. technique cherchant inciter un utilisateur cliquer sur un lien malicieux prsent comme sre. 10. manipulation des informations DNS an de prendre distance le contrle dun routeur Internet.

46

3. Les attaques Cross Site Scripting

3.3.1

Solutions ct client

Un ltrage XSS eectu entirement du ct client permet des navigateurs Web de vrier des entres utilisateur au pralable, avant leur envoi au serveur, ou de vrier les rponses du serveur avant quelles soient ne interprtes par le client. Les solutions ct client peuvent consister en modules additionnels intgrs aux navigateurs Web ou des mcanismes externes de dtection dintrusion installs sur le mme quipement que le navigateur Web, jouant le rle dun proxy qui contrle le trac au niveau applicatif (requtes/rponse HTTP) entre lapplication Web et le navigateur Web. 1. Renforcement des navigateurs Web Lapproche la plus simple et la plus utilise pour se prmunir des attaques XSS consiste renforcer le navigateur Web. Plusieurs navigateurs Web (IE8, Mozila Firefox, Google Chrome, etc) sont dots dune couche additionnelle de protection ou proposent des modules additionnels pour se prmunir de ces attaques. Microsoft a ajout en 2008 un module anti-XSS dans le navigateur IE 8 ; il consiste scanner les paramtres dune requte qui peuvent tre malveillants. Quand de tels paramtres sont slectionns, IE8 gnre dynamiquement une expression rgulire (une ventuelle rponse du serveur). Il contrle ensuite la rponse du serveur. Si une correspondance complte entre la rponse du serveur et une expression rgulire est vrie alors une attaque XSS rchie est en cours. Le ltre modiera donc automatiquement cette rponse de telle sorte faire chouer lattaque. Cependant, si lattaque nest pas correctement neutralise, un script malveillant peut tre excut. Ce ltrage peut non seulement tre facilement outrepass, mais il peut galement rendre lapplication vulnrable. En eet, des recherches [ED] ont dmontr que loutil pouvait rendre des applications vulnrables XSS, en manipulant les rponses modies par IE8 pour eectuer de simples abus. Un autre type de protection conu pour Mozila Firefox est un module complmentaire : NoScript [MOZ]. Ce module est bas sur une liste blanche. Il permet de limiter lexcution de scripts JavaScript des domaines de conance slectionns par lutilisateur. Le systme eectue un blocage prventif des scripts dont le domaine nappartient pas la liste blanche. Cependant, cette solution est trs restrictive. Les sites Web de nos jours utilisent beaucoup de code JavaScript. NoScript oblige donc des interventions rptes de lutilisateur qui doit chaque fois choisir de bloquer ou dautoriser les scripts dun domaine. De plus, des scripts malicieux dans un site de conance ne peuvent pas tre dtects [Won]. Une autre approche utilise dans Netscape et prsente par Vogt et al [FNE+ 07] consiste utiliser la technique dtiquetage des donnes en entre du navigateur Web. Lobjectif est de veiller ce que les donnes sensibles (cookies, identiants de session), relatives un domaine ne soient pas transfres un domaine tiece. Par exemple, quand une page Web contient un formulaire HTML, les valeurs entres par lutilisateur sont tiquetes indiquant leur serveur dorigine. Ltiquette est propage toute donne gnre partir de la manipulation dune donne tiquete. Ainsi, si un script malveillant sexcutant dans une autre fentre tente despionner ce formulaire HTML et de faire des copies des entres de lutilisateur, les valeurs copies vont galement tre tiquetes et ne pourront pas tre envoyes un autre serveur que celui dorigine. Comme pour le module NoScript de Mozila Firefox, cest lutilisateur

3.3. Solutions existantes

47

de choisir dautoriser ou de bloquer un transfert de donnes. 2. Systmes de dtection dintrusion ct client Des solutions bases sur un mcanisme de dtection dintrusion appeles pare-feu ou proxy applicatifs se placent entre le client et le serveur. Ils permettent danalyser les requtes et rponses changes entre les deux parties en vriant que les rponses ne contiennent pas de scripts non-autoriss ou que des informations sensibles ne sont pas envoyes un domaine malicieux. Dans [ECGN06], une mthode de ltrage ct client est propose pour empcher que le navigateur Web de la victime contacte des URLs malveillantes. Leur outil appel Noxes est un proxy qui utilise une "liste noire" contenant un ensemble de liens qui ne sont pas de conance. Ainsi, le proxy contrle les requtes et les rponses, et bloque toute redirection ou envoi de donnes sensibles vers des liens appartenant cette "liste noire". Nous considrons que cette mthode nest pas susante pour dtecter ni empcher les attaques XSS complexes. Seules les XSS volatiles fondes sur la violation de la politique de mme origine [Fou06] pourraient tre dtectes. Des techniques alternatives dattaques XSS, comme celle propose dans [Lud11], peuvent tre utilises an de contourner un tel mcanisme de prvention. De plus Noxes ncessite une conguration par son utilisateur qui doit spcier les rgles de ltrage (liens malicieux). Les auteurs dans [OMYS04], prsentent un autre proxy ct client qui contrle et analyse des donnes changes entre le navigateur et le serveur. Leur processus danalyse consiste vrier les caractres composant les paramtres des requtes et rponses envoyes et mises par le serveur, et dtecter les caractres malicieux qui pourraient tre interprts par le navigateur Web. Pour cela, le proxy vrie si des caractres malicieux prsents dans une requte se retrouvent dans la rponse du serveur. Si cest le cas, deux modes de fonctionnement sont possibles. Dans le premier, la rponse est encode et transmise au client avec un message dalerte. Dans le deuxime, la requte est encode puis envoye nouveau au serveur. La rponse du serveur est ensuite retransmise au client avec un message dalerte. De toute vidence, la principale limitation dune telle approche est quelle ne peut tre utilise que pour empcher les attaques XSS non persistantes. De plus, elle engendre un temps de rponse supplmentaire.

3.3.2

Solutions ct serveur

Les solutions ct serveur, peuvent tre divises en deux approches : la programmation prventive qui intervient la phase de dveloppement de lapplication, et les mcanismes de dtection dintrusion (proxy ou pare-feu applicatif) installs sur le serveur et qui contrlent les ux changs entre le serveur et le client. Il existe galement dautres outils permettant de vrier la bonne implmentation des applications Web, appliquant une approche base sur la programmation prventive. 1. Programmation prventive La programmation scurise (programmation prventive) est une forme de conception dfensive qui vise assurer la fonction permanente de logiciels en dpit des utilisations imprvisibles. Lapproche de programmation prventive fournit un soutien sous forme dAPI

48

3. Les attaques Cross Site Scripting

(Application Programming Interfaces ) ou de bibliothques qui peuvent tre utilises par les dveloppeurs. Deux API bien connues pour la protection contre les attaques XSS sont htmLawed [htm] et Kses [Kse]. Elles sont destines des applications crites en langage PHP. Kses est un script de ltrage HTML/XHTML crit en PHP. Ce ltre est utilis par lapplication de blogs WordPress. Le but de cette API est de supprimer tous les lments et attributs HTML indsirables an dattnuer les attaques XSS, buer overows, etc. htmLawed est un autre ltre, fournit en logiciel libre, qui nettoie du code HTML pour viter les failles de scurit. Il rcrit essentiellement le code HTML pour supprimer les balises et les donnes qui pourraient tre utilises pour eectuer des attaques XSS. Cependant, de nombreuses attaques XSS ne sont pas empches, comme linjection de code HTML par le biais des expressions de feuilles de style CSS. De plus, lapproche qui consiste supprimer les caractres malicieux peut tre facilement contourne. Si lAPI supprime le mot <script> dans un vecteur dentre, la chane suivante : <scr<script>ipt>alert(document.cookie)</scr</script>ipt> gnre une XSS qui ne va pas tre dtecte. Dautre part, une collection de logiciels et de mthodes de classes et qui pourraient galement inclure direntes API, forment gnralement une bibliothque. Deux des bibliothques antiXSS les plus populaires sont AntiSamy OWASP [Ant] et Microsoft Anti-Cross Site Scripting Library [Lam06]. AntiSamy est une bibliothque logicielle libre, qui analyse et nettoie les entres HTML/CSS en utilisant une technique de validation base sur une liste blanche. Elle utilise un chier XML (liste blanche) qui dnit les balises et les attributs autoriss dans une application. AntiSamy a de trs bonnes capacits de ltrage XSS et son API est propre. Cependant, elle prsente un inconvnient d la dicult de crer et de maintenir le chier XML pour chaque application. Un autre inconvnient dAntiSamy est quelle ne prend pas en charge la totalit des balises HTML/CSS, telles que les balise dimages. La bibliothque Microsoft Anti-XSS [Mica] fait partie de la bibliothque Microsoft Web Protection (WPL). Elle se base aussi sur lapproche de liste blanche pour encoder les entres utilisateur non able (HTML, lattribut HTML, XML, CSS et JavaScript). Lavantage de cette bibliothque par rapport son quivalente open-source, AntiSamy, est quelle est relativement plus facile utiliser, et peut tre applique toute application ASP.NET sans exiger beaucoup de modications du code existant. Toutefois, cette bibliothque ne peut tre utilise que pour des projets cods avec la technologie .NET. Au contraire, lAPI AntiSamy a t porte sur direntes plateformes telles que .NET et PHP. Lorganisation OWASP 11 propose une autre bibliothque appele Entreprise Security API (ESAPI). ESAPI aide les dveloppeurs se protger des dfauts de scurit lors de la conception et de la mise en uvre, en fournissant un ensemble commun dinterfaces pour les contrles de scurit dont : lauthentication, le contrle daccs, la validation des entres, lencodage des sorties, etc. Ces interfaces sont conues de manire tre simple comprendre et utiliser et prennent en charge, automatiquement, de nombreux aspects de scurit dapplications. La bibliothque est disponible pour dirents langages de programmation, ce qui permet davoir une interface unique entre les dirents langages. Un dveloppeur en Java ou .NET qui a dj utilis ESAPI passera rapidement la version PHP. Quel que soit lapproche de scurit de codage, les techniques qui devraient tre utilises
11. https ://www.owasp.org/index.php/Main_Page

3.3. Solutions existantes

49

pour attnuer les attaques XSS sont la validation (ltrage) et lencodage (chappement) des entres et sorties. Ces techniques et leurs variantes sont dcrites ci-dessous : Validation des entres / sorties La validation des entres est une technique utilise pour vrier si lentre utilisateur est un contenu non-valide ou dangereux. Dans une telle approche, les donnes entres par un utilisateur sont scannes et compares soit une liste blanche soit une liste noire. Une action approprie est ensuite applique. Lutilisation dune liste blanche garantit que toutes les requtes sont refuses, sauf si elles sont spciquement autorises. Dautre part, la liste noire contient lensemble des entres connues comme malveillantes. Cette approche est moins robuste que la prcdente car les modles dattaque XSS sont en constante volution. Cependant, comme mesure de protection supplmentaire, il peut tre intressant dutiliser les deux techniques la fois. Les ltres de liste noire sont insusants, mais cela ne signie pas quils sont inutiles. Une approche hybride lorsquelle est mise en uvre correctement peut entraner une dfense trs ecace contre les attaques XSS. La liste blanche sert sassurer quune entre correspond un format dsign, et la liste noire permet dexclure dautres problmes connus. La validation des sorties fonctionne de la mme manire que la validation des entres, mais seules les donnes destines tre aches dans une page Web sont scannes. En rgle gnrale, la validation des entres/sorties est applique dans le but dattnuer le risque dattaques XSS, et lapproche de la liste noire est la plus utilise. Encodage des entres / sorties Lencodage est une autre technique de ltrage de contenu. Elle consiste essentiellement rendre sans danger des caractres, des tags et des scripts indsirables, en les remplaant par une reprsentation alternative [20007], encode (par exemple <script> encod en HTML : &lt;script&gt;). Ce type de ltrage peut tre utile lorsque lespace de saisie autoris ne peut pas garantir que lentre est sre. Lencodage permet de traiter des entres potentiellement malicieuses comme du texte plutt quun script excutable. Tout comme la validation, il y a deux variantes dencodage : lencodage des entres et lencodage des sorties. Lencodage des entres oblige lutilisateur connatre le contexte dans lequel ces donnes vont tre utilises. Ceci est adapt pour de petites applications Web, mais il peut tre compromettant pour les applications Web mises en uvre par plusieurs dveloppeurs, surtout si lapplication est distribue. La prdiction du contexte dutilisation des donnes pourrait impliquer des hypothses qui pourraient introduire de nouvelles vulnrabilits. Dautre part, lencodage des sorties a tendance en gnral tre plus facile mettre en uvre. Le dveloppeur a besoin de dterminer le contexte dans lequel les donnes sont retournes. En rgle gnrale, seul lencodage des sorties est utilis comme un moyen de dfense XSS. Lencodage peut parfois tre dtourn par les pirates pour crer des vecteurs XSS brouills qui contournent la plupart des ltres de validation bass sur une liste noire. Le tableau 8.1, prsente les direntes faon dcrire la chane <SCRIPT>alert("XSS")</SCRIPT> en utilisant des codages dirents. Les chanes qui en rsultent dmontrent la dicult, voir limpossibilit, davoir une liste noire qui contiendrait toutes les combinaisons possibles

50

3. Les attaques Cross Site Scripting

dentres invalides. Cependant, linterprtation de ces dirents encodages dpend aussi du navigateur Web utilis [OWAc]. Encodage HTML Hex Chaine rsultante &lt;script&gt;alert(&apos;xss&apos;)&lt;/script&gt &#x3c;&#x73;&#x63;&#x72;&#x69;&#x70;&#x74; &#x3e;&#x61;&#x6c;&#x65;&#x72;&#x74;&#x28;&#x27; &#x78;&#x73;&#x73;&#x27;&#x29;&#x3c;&#x2f;&#x73; &#x63;&#x72;&#x69;&#x70;&#x74;&#x3e; &#x60;&#x115;&#x99;&#x114;&#x105;&#x112; &#x116;&#x62;&#x97;&#x108;&#x101;&#x114;&#x116; &#x40;&#x39;&#x120;&#x115;&#x115;&#x39;&#x41; &#x60;&#x47;&#x115;&#x99;&#x114;&#x105;&#x112; &#x116;&#x62; &#x74;&#x163;&#x143;&#x162;&#x151;&#x160;&#x164; &#x76;&#x141;&#x154;&#x145;&#x162;&#x164;&#x50; &#x47;&#x170;&#x163;&#x163;&#x47;&#x51;&#x74; &#x57;&#x163;&#x143;&#x162;&#x151;&#x160;&#x164; &#x76; +ADw-script+AD4-alert(XSS)+ADsAPA-/SCRIPT+AD4 PHNjcmlwdD5hbGVydCgnWFNTJyk7PC9TQ1JJUFQ+Cg==

Decimal

Octal

UTF-7 Base64

Table 3.1 Exemples dencodages pour outrepasser une liste noire Il est en gnral convenu, que le codage scuris est laction la plus naturelle et la plus souhaitable pour prvenir et corriger les vulnrabilits XSS. Cependant, les dveloppeurs ont besoin dtre forms ou habitus crire du code scuris. Ils sont gnralement tenus de dvelopper des applications fournissant un maximum de services et quelles soient conviviales et ergonomiques, le tout dans un dlai restreint, ce qui ne leur laisse pas le temps de se soucier de la scurit. Lutilisation dune bibliothque tierce pourrait tre dune grande aide ces dveloppeurs. En outre, lencodage scuris engendre linconvnient de lecacit rduite due au temps supplmentaire li la validation et/ou lencodage. Lapplication utilisant la fois la validation et lencodage des entres/sorties peut conduire une dgradation des performances au niveau du serveur. Les spcialistes en scurit considrent que pour des raisons de performance, le ltrage des entres peut tre facultatif mais les sorties doivent tre ncessairement ltres. 2. Systmes de dtection dintrusion et pare-feu applicatifs Tout comme les solutions ct client, il existe des proxys et des pare-feux applicatifs destins tre installs sur le serveur qui hberge lapplication protger. ModSecurity [Mod] est un pare-feu applicatif open-source qui agit comme un module pour le serveur Web Apache. Il intercepte les requtes envoyes et les rponses reues par le serveur web, les traite et les ltre base dune liste noire contenant des rgles de requtes non souhaites. Selon les auteurs, ModSecurity na pas dimpact sur les performances mme quand il est lanc en parallle avec dautres priphriques rseau. Il ore une bonne protection contre certaines des attaques les plus courantes en utilisant sa liste noire dnie par dfaut. Cependant, linconvnient majeur de ModSecuriy est quil ne supporte pas les dirents algorithmes de codage, les ltres peuvent donc tre contourns. Scott et Sharp [SS02] ont dvelopp un langage de description de politique de scurit (SDLP : Security Policy Description Langage ) qui spcie des contraintes de validation et des rgles

3.3. Solutions existantes

51

de transformation dnissant ce quil faut faire (raction) quand un certain motif (pattern) est dtect dans une entre utilisateur. Ce systme met en place un pare-feu applicatif qui utilise une base de donnes de signatures, relatives des entres malicieuses. Bien que ce systme donne lassurance immdiate de la scurit des applications Web, il prsente deux inconvnients principaux. Le premier est la dicult didentier et de crer des contraintes de validation pour chaque point dentre spcique une application Web. Le deuxime est laugmentation du temps de rponse du serveur qui ralentit la gnration dynamique de pages Web. PHPIDS [PHP] est un IDS open-source. Cette IDS permet de protger les applications PHP des injections XSS, SQL, et dautres attaques. PHPIDS est simple utiliser et ore une couche de scurit bien structure pour les applications Web PHP. Contrairement ModSecurity, cet outil prend en charge divers algorithmes de codage. En eet, PHPIDS peut dtecter des attaques brouilles, utilisant dirents ensembles de caractres comme UTF-7, JavaScript Unicode, les entits dcimales et hexadcimales. Toutefois, il prsente les inconvnients de : gnrer une quantit importante de faux positifs, dtre dpendant du langage PHP et de consommer beaucoup de cycles CPU. Bien que ces outils fournissent une assurance dynamique et donc immdiate de la scurit des applications Web, dans la plupart des cas et dans certaines mesures, la plupart des solutions bases sur les IDS et les pare-feux applicatifs peuvent tre contourns avec de simples astuces comme indiqu dans le tableau 8.1. Ce tableau montre quelques-unes des attaques XSS qui, selon Eduardo Alberto Vela Nava et al. [Nav10] ne sont pas dtectes par les IDS. La raison est que la plupart de ces outils se basent principalement sur un modle de scurit ngatif : la liste noire . Or, il existe direntes faons dcrire une attaque XSS qui ne peuvent pas toutes tre dnies dans une liste noire. Cette approche protge les applications Web uniquement la phase de dploiement au lieu dessayer de contribuer liminer les failles pendant la phase de dveloppement.

3. Stratgies dvaluation de la scurit Lvaluation de la scurit est un point de vue rigoureux dans le dveloppement dapplications. Elle consiste rechercher des vulnrabilits potentielles qui peuvent permettre des attaques sur lapplication. Gnralement, lanalyse statique et/ou lanalyse dynamique sont les mthodologies utilises pour eectuer lvaluation. Deux des outils les plus reprsentatifs qui utilisent cette approche pour les XSS sont WebSSARI [HYH+ 04] et Pixy [NCE06]. Lanalyse statique prsente linconvnient de gnrer un taux lev de faux positifs, qui engendre souvent une analyse manuelle par la suite. Lanalyse dynamique prsente linconvnient de gnrer des faux ngatifs et dtre couteuse, ncessitant gnralement linstrumentation du code analys. De plus, les outils danalyse et dvaluation de logiciels sont lis au langage de dveloppement. La plupart de ces outils sintressent des applications web crites en PHP et il nexiste aucun outil danalyse dapplications Web pour carte puce. Dans le chapitre suivant, nous prsentons cette approche plus en dtails.

52

3. Les attaques Cross Site Scripting

3.4

Conclusion

Dans ce chapitre, nous avons tudi un cas spcique dattaques sur les applications Web. Nous avons mis laccent sur les risques des vulnrabilits XSS et les direntes approches pour sen prmunir. Lapproche base au niveau client prsente lavantage dapporter une solution plus gnraliste, en protgeant laccs un ensemble dapplications consultes partir du navigateur Web qui limplmente. Cependant, la protection oerte est peu able et peut tre facilement contourne. Dautre part, les solutions ct serveur ne ncessitent pas dintervention de lutilisateur, et ont beaucoup moins de risque dtre contournes que les solutions ct client. Nous considrons que la meilleure prvention contre des attaques par injection de code, particulirement les XSS, consiste sensibiliser les dveloppeurs appliquer une mthodologie de dveloppement scurise en intgrant une vrication et un encodage des entres et sorties de lapplication. Les solutions de vrication et dvaluation des applications, permettent de certier que lapplication est correctement dveloppe, appliquant les rgles de scurit dnies par une mthodologie. Nous prsentons un tat de lart de ces solutions dans le chapitre suivant.

53

Chapitre 4

Dtection de vulnrabilits dans un programme

Sommaire
4.1 4.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 55 56 58 59 59 60 61 Analyse statique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 4.3 tat de lart des outils danalyse statique . . . . . . . . . . . . . . . . . Lanalyse statique dans Java Card . . . . . . . . . . . . . . . . . . . . .

La dpendance causale . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 4.3.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Travaux existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4

Conclusion

4.1

Introduction

Les consquences importantes lies aux vulnrabilits des programmes ont incit multiplier les eorts de recherche pour le dveloppement doutils de dtection derreurs de programmation et de failles de scurit. Il existe direntes techniques de vrication et de test de programmes, contribuant ainsi lamlioration de leur qualit. Nous distinguons trois approches : des outils bass sur un assistant de preuve, le test et lanalyse de programmes. Les outils bass sur un assistant de preuve orent lutilisateur un moyen de construire des preuves et vrient ensuite, de manire plus ou moins automatique quelles sont correctes dans le programme associ. ESC/Java est un outil bas sur cette approche qui a t largement utilis dans lanalyse des applications Java. Il a t dvelopp par Compaq SRC. Il permet de trouver des erreurs de programmation Java. Lutilisateur doit dnir une spcication des classes et mthodes de lapplication quil souhaite analyser. ESC/Java analyse et vrie si limplmentation satisfait cette spcication. Un prouveur de thormes [DJ04] est utilis pour prouver si la spcication cible est une consquence logique de la spcication source. Si la spcication nest pas respecte, loutil lance une alerte. La spcication est crite sous forme dannotations Java et reprsente

54

4. Dtection de vulnrabilits dans un programme

par des invariants de classe et des pr- et post-conditions dune mthode. La performance de ce type doutils est fortement lie la qualit de la spcication formelle qui est spcique une application et doit tre dnie par lutilisateur. La validation de logiciels base de tests consiste appliquer un jeu de tests sur un programme et de vrier quil fonctionne correctement. Le Fuzzing est une technique de test trs utilise dans lindustrie. Elle consiste injecter un ensemble de tests invalides, inattendus ou alatoires, en entre dune application dans le but de mettre dfaut son excution (gnrer : une exception, un crash, un rsultat inattendu). Le Fuzzing peut sappliquer en boite blanche ayant le code source, en boite grise se basant sur le code binaire ou boite noire sans avoir aucune connaissance de lapplication teste. Il existe dirents logiciels de Fuzzing pour la dtection de vulnrabilits par injection de code dont WAPITI [WAP] et WEBFUZZER [WEB]. Cependant, cette technique ne peut pas tre complte dans le sens o il est impossible davoir tous les cas de tests possibles, notamment dans des cas comme les attaques XSS o un mme caractre peut tre reprsent de direntes faons, en utilisant dirents encodages. Lanalyse dun programme est un processus de vrication automatique de son comportement dans le but de dtecter sil est correct : respectant les rgles et la syntaxe du langage de dveloppement utilis, optimis ou encore scuris en appliquant des mthodologies de dveloppement bien dnies. On distingue deux classes danalyses : lanalyse statique et lanalyse dynamique. 1. Lanalyse statique : permet la dtection et llimination derreurs de programmation ds les phases prliminaires de conception, et par consquent daner le programme test ou damliorer sa robustesse. Cette technique prsente lavantage dtre indpendante de la plate-forme dexcution, elle est donc universellement applicable. Cependant, il a t mathmatiquement dmontr base de rsultats fonds sur le thorme de Rice 12 que lanalyse statique dun programme est un problme indcidable. En eet, dans certains cas il est dicile de dsigner la suite dexcutions possibles du programme. Ds quil contient des boucles ou des branchements conditionnels (while, if, etc.), il devient dicile de dcrire le chemin dexcution ou de savoir si le programme se termine. Cependant, lapplication dun ensemble de principes (contrle des dpassements de tampon par exemple) lors de la phase de conception, permet de rduire le risque derreurs lexcution. En outre, lanalyse statique a lavantage de faciliter la maintenance du code. 2. Lanalyse dynamique : consiste analyser lexcution dun programme. Elle est souvent base sur linstrumentation des applications par lajout dinstructions permettant le suivi et le contrle des ux dinformations [FNE+ 07, CW09]. Linstrumentation peut tre ralise au niveau du code source, lors de la compilation, ou partir du code binaire ou du bytecode ; elle permet de suivre les ux dinformations internes des applications. Les mcanismes de dtection dintrusion peuvent tre vus comme des outils danalyse dynamiques. Leur objectif est de surveiller les ux manant et reus par une application pendant son excution, et de dtecter des cas de violation de politiques de scurits spcies. Les travaux proposs par Guillaume Hiet nous ont suscit un grand intrt. Loutil danalyse dynamique JBlare [Gui08, GVLB08] quil propose eectue une analyse dynamique des ux au niveaux applicatif et systme. Cet outil utilise un moniteur externe lapplication permettant le suivi de la propagation des ux entre les direntes applications et entre les applications et le systme. Le moniteur est
12. le thorme de Rice dit que toute proprit non triviale (cest--dire qui nest pas toujours vraie ou toujours fausse) sur la smantique dnotationnelle dun langage de programmation Turing-complet est indcidable.

4.2. Analyse statique

55

install au niveau de lenvironnement dexcution des programmes (Machine Virtuelle Java JVM, systme dexploitation,. . . ) ce qui ncessite souvent des modications ; une instrumentation des applications simpose aussi.

Synthse :

lapproche dynamique prsente lavantage dtre plus prcise que lapproche statique

en gnrant moins de faux positifs (fausses alertes), mais elle ne garantit pas la couverture totale du code. En eet, la validation de ce type doutils est base sur une suite de tests, or il est souvent dicile de prvoir tous les cas possibles de tests, ce qui engendre des faux ngatifs (cas non traits). Dautre part, linstrumentation du bytecode et la modication de la JVM prsentent un cot considrable en termes despace mmoire et de temps dexcution supplmentaires gnrs par lanalyse. Les travaux prsents dans JBLARE [Gui08, GVLB08] ont dmontr la grande ecacit de cette technique permettant de dtecter des violations de politiques de scurit par suivi des ux de contrle au niveau applicatif et au niveau du systme dexploitation. Toutefois, les rsultats exprimentaux dans un environnement PC montrent que cette analyse augmente le temps dexcution de plus 5%, ce qui ne convient pas dans un environnement faibles ressources tel quune carte puce. Pour ces direntes raisons et an de vrier la robustesse de limplmentation des applications Web Java Card 3, nous avons choisi de concevoir un outil danalyse statique. Cette approche est plus compatible pour un systme capacits restreintes (la carte puce par exemple). De plus, elle permet de rduire les risques derreurs et de vulnrabilits, et de dtecter des failles de scurit avant de charger les applications dans le systme.

4.2

Analyse statique

Lanalyse statique est un moyen de vrication automatique permettant de prdire les comportements dun programme lors de son excution sans rellement lexcuter. Elle est gnralement utilise dans le dbogage, en particulier pour la recherche derreurs pouvant apparatre lexcution. Il sagit de la technique la plus adquate pour analyser des applications ddies des plateformes ressources rduites telles que les cartes puce o une analyse dynamique serait trs coteuse. Lanalyse statique consiste gnralement explorer les dirents chemins dexcution possibles dun programme. Elle se base sur la construction dun graphe de ux de contrle (Control ow graph, CFG) qui est une reprsentation par un graphe de tous les chemins qui peuvent tre traverss dans un programme durant son excution. Les nuds du graphe reprsentent les blocs dinstructions de base qui sont toujours excutes sans interruption et les artes reprsentent les ux de contrle qui relient deux blocs dirents. Un graphe dappels reprsente potentiellement un ux de contrle inter-mthodes. Les nuds dun graphe dappels correspondent aux mthodes et une arte reprsente une mthode qui invoque une autre mthode. Une analyse plus labore inclut galement un contrle des ux de donnes changs entre des mthodes ou des applications. Elle permet davoir des informations sur lensemble des donnes pouvant apparaitre en un certain point du programme. Elle est gnralement utilise an de dtecter

56

4. Dtection de vulnrabilits dans un programme

des objets non rfrencs dans le programme ou de vrier que certains objets sensibles ne sont pas utiliss dans un contexte non-prvu ou non-scuris. Il existe direntes techniques danalyse statique, la plus rpandue consistant dnir des motifs correspondant une vulnrabilit ou des erreurs lies un langage de programmation et de rechercher ces motifs dans le code. Dautres analyses plus labores sont bases sur lanalyse des ux de donnes et des ux de contrle. Enn, il existe des outils qui ncessitent dajouter des annotations dans le code pour spcier une rgle vrier.

4.2.1

tat de lart des outils danalyse statique

Plusieurs recherches se sont intresses la vrication de programmes Java. Certaines se situent dans la catgorie des outils qui fournissent des informations syntaxiques concernant des rgles stylistiques dcriture de programmes [Che]. Dautres avertissent de lusage de constructions considres comme dangereuses ou interdites par des rgles visant une programmation plus sre. Nous nous intressons cette deuxime catgorie doutils. Wagner et al. [SJCP05] prsentent une comparaison entre un ensemble de ces outils, dont Findbugs [HP04], PMD [PMD], QJ PRO [QJP] et quelques projets industriels (non cits). Leur tude se base sur la quantication des faux positifs gnrs par chaque outil. Dans [RAF04], le nombre de faux ngatifs est aussi pris en compte. Ces deux comparaisons ont conclu que chaque outil est en mesure de dtecter des bogues que les autres ne dtectent pas, et par consquent la combinaison de ces dirents rsultats permettrait davoir une analyse plus complte. Cependant, certains de ces outils comme Findbugs sont volutifs. Ils utilisent des modules complmentaires, chacun tant en charge de vrier une proprit. Dans nos travaux nous avons slectionn loutil danalyse Findbugs, nos critres de slection tant bass sur : lanalyse de ux de donnes : an de suivre la propagation des donnes douteuses dans le code ; lextensibilit : permettant dajouter facilement des modules pour adapter loutil notre besoin de dtecter des attaques Web XSS ; le logiciel libre (Open source) qui permet dapporter des ajouts et modications. Dans la suite nous prsentons quelques exemples de logiciels danalyse statique, open source, notamment loutil Findbugs :

JLint. JLint [Kon] est un outil danalyse de bytecode Java qui eectue des contrles syntaxiques, une analyse de ux de donnes et une analyse inter-procdurale des programmes multi-tches. Il contient un composant appel AntiC, qui est un vricateur de syntaxe pour les langages de la famille du langage C, savoir : C/C++, objectiveC et le langage Java. Cependant, JLint ne permet pas lanalyser des servlets ce qui est contraignant dans notre cas dtude, puisque nous nous intressons la scurit des applications Web Java Card 3 (bases sur des servlets). De plus, cet outil nore pas de mcanisme dintgration de plugins (modules additionnels). Pour ajouter une nouvelle proprit danalyse, il est ncessaire de modier le code source et de dvelopper les mthodes de test supplmentaires en langage C.

4.2. Analyse statique

57

PMD. PMD [PMD] permet danalyser du code source Java. Il est bas sur la dnition dun ensemble de rgles rechercher dans un code. Un ensemble de rgles est fourni par dfaut dans loutil, savoir : absence dun des tats try / catch / nally ; les variables locales, les paramtres et les mthodes prives non utilises ; les objets qui ne sont pas ncessaires ; les expressions trop compliques - inutiles si les dclarations, les boucles for qui pourraient tre des boucles while ; la duplication de code. Loutil est extensible, permettant de dvelopper de nouvelles rgles inclure dans lanalyse. Toutefois le dveloppement de ces rgles ncessite des connaissances en Arbre syntaxique abstrait (Abstract Syntax Tree, AST) sur lequel PMD se base.

Findbugs : Findbugs [Fin] est un logiciel, distribu dans les termes dune licence LGPL et dvelopp luniversit du Maryland, Etats-Unis. Il permet de dtecter des bogues dans un programme Java, partir de lanalyse du bytecode la recherche de certains motifs. Findbugs inclut un ensemble important de dtecteurs permettant de dceler des bogues gnralement lis des dfauts de programmation. Cependant, loutil est extensible orant la possibilit de rajouter des plugins pour vrier des proprits supplmentaires. Lutilisateur peut limiter son analyse uniquement des proprits quil souhaite vrier en slectionnant les dtecteurs qui lintressent. Une synthse eectue dans [LL05] compare un ensemble doutils danalyse statique et classe lanalyseur Finbugs comme loutil le plus facilement extensible qui ore la possibilit dajouter un plugin pour vrier une proprit de scurit additionnelle. Dans [IBM], un dveloppeur dIBM dcrit en dtail comment dvelopper un nouveau plugin. Un plugin est une archive au format jar qui peut comporter un ou plusieurs dtecteurs. Les dtecteurs sont bass sur le patron Visitor. Ils implmentent linterface Detector qui inclut la mthode visitclassContext() qui invoque chaque classe de lapplication. Le logiciel utilise la librairie BCEL (Byte Code Engineering Library ) qui est une librairie Java permettant danalyser et de manipuler des chiers class Java et dobtenir des informations lmentaires sur tous les objets et mthodes contenus dans ces chiers (mthodes, attributs, instructions, etc). Findbugs propose un ensemble de classes et dinterfaces qui peuvent tre tendues pour le dveloppement dun nouveau plugin. Dans notre cas, nous avons exploit la classe OpcodeStack, qui permet de calculer une abstraction de la pile dexcution en fonction des direntes instructions bytecode (Opcode) possibles. Lanalyse des ux de donnes dans Findbugs tient compte de la dpendance causale entre les variables locales dune mthode (analyse intra-procdurale). Cependant, cette analyse de dpendance causale se limite une analyse mthode par mthode et ne tient pas compte des appels intermthodes dune mme classe ou de classes direntes. Dautre part, lanalyse intra-procdurale est incomplte car dirents cas dOpcode ne sont pas compltement traits, notamment dans le cas des tableaux et des vecteurs (aaload, aastore, ...).

58

4. Dtection de vulnrabilits dans un programme

4.2.2

Lanalyse statique dans Java Card

Les applets Java Card sont des applications destines tre utilises dans des domaines assez sensibles comme dans les cartes bancaires. De ce fait, direntes recherches se sont intresses la vrication de ce type dapplications. Compte tenu des ressources limites des plateformes (cartes puces, systme embarqus, . . . ) qui hbergent ces applets, la plupart des recherches se sont bases sur lanalyse et la vrication des applications avant dtre charges dans la carte (oCard ). Parmi ces outils, de nombreux travaux comme Jack [BRlLV03], Loop [JB01], ou encore les travaux de Gemplus prsents dans [CnH02], se basent sur la vrication formelle et utilisent le langage JML (Java Modeling Langage ) pour la dnition dune spcication de lensemble des classes et interfaces de lapplication. JML (Java Modeling Language ) est un langage de spcication dun comportement. Il permet de dnir lusage correct de lensemble des applications (interface syntaxique du code, signature des mthodes, types des attributs, etc.) se basant sur la dnition des pr et post-conditions ainsi que des invariants. Les spcications sont ajoutes dans une application Java ou Java Card sous forme dannotations Java. Cependant, ce type doutils demande un eort considrable de la part du dveloppeur qui doit lui-mme dnir la spcication correspondante lapplication quil souhaite analyser. Dans [PJM+ 00, JL00], les auteurs prsentent le projet PACap, dont lobjectif est de vrier les interactions entre des applets Java Card, et de certier quune nouvelle applet interagit de manire scurise avec des applets pralablement charges dans la carte. Loutil propos vrie les ux de donnes entre des objets de la carte puce par une analyse statique. Il contrle si une application est correctement implmente respectant une politique de scurit qui dnit les niveaux de partage autoriss. Cependant, loutil ne peut pas dtecter dautres violations que celles dnies dans la politique de scurit. Loizidis et al. [ALK+ 08] prsentent un outil danalyse statique automatique bas sur plusieurs dtecteurs qui tendent lanalyseur Findbugs, pour vrier trois types de violations. Le premier dtecteur est permet de verier le respect des restrictions relatives aux communications interapplets via une interface de partage. Il construit un CFG pour toutes les classes dune applet an de dtecter les violations de proprits inter-procdurales, telles que des appels rcursifs une mthode dclare dans les interfaces de partage. Le second dtecteur vrie que les appels des mthodes dAPI ne provoquent pas dexception non gre, qui pourrait conduire quitter lapplet dans un tat imprvisible. Le troisime permet deectuer une analyse de ux de donnes pour vrier les arguments dune mthode invoque et dtecter des failles tels que des paramtres nuls ou non valides (une valeur ngative pour un index dans un tableau).

Notre tude se base sur Findbugs, associ la technique de dpendance causale tainting . Lobjectif de notre analyse est de tracer la propagation des donnes dans une excution abstraite de bytecode et de vrier la prsence de vulnrabilits des attaques Web par injection de code dans des applications Web ddies des cartes puce, en particulier les Java Card 3. Nous verrons par la suite quun ensemble damliorations dans Findbugs a t ncessaire an de rendre notre analyse plus ecace.

4.3. La dpendance causale

59

4.3

La dpendance causale

Limpact de la non-validation des donnes en entre dun systme ou dune application peut tre inestimable. Les attaques par injection de donnes malicieuses sont trs rpandues mais elles deviennent diciles raliser quand le dveloppeur prvoit un ltrage et une validation des donnes avant de les utiliser dans des fonctions sensibles. Lanalyse de dpendance causale est une technique qui permet de vrier que ces fonctions sont prsentes dans un code.

4.3.1

Description

La dpendance causale est la technique qui permet de suivre la propagation de donnes potentiellement malicieuses an de vrier quelles ne sont pas utilises dans des contextes sensibles la scurit. Une dpendance causale entre deux objets est prsente, sil existe un ux dinformations direct ou indirect entre eux. Cette technique consiste dabord marquer par une tiquette les donnes en entre du logiciel et ensuite de propager cette tiquette dautres objets calculs en fonction dobjets tiquets. Une alerte est lance quand ltiquette est propage des objets (ou paramtres) inappropris o la scurit pourrait tre compromise. Livshits et al. [LL05] dnissent la dpendance causale par un ensemble dtats : source, drivation, puits, et neutralisation dcrits comme suit :

Source : correspond aux points dentre dun programme par lesquels un utilisateur peut introduire des donnes. Dans les dirents langages de programmation, il existe un ensemble de mthodes permettant de retourner les donnes entres par lutilisateur (exemple : la mthode getParametter() dans Java). Dans les applications Web nous avons des mthodes permettant de retourner des donnes HTML, de lire les cookies enregistrs au niveau du client ou danalyser des paramtres HTML. La dpendance causale commence par associer une tiquette toute donne issue dun tat source.

Drivation : les donnes issues dun tat source peuvent potentiellement tre manipules pour gnrer dautres donnes qui peuvent tre elles-mmes manipules pour gnrer dautres donnes. La manipulation peut consister en diverses oprations : une assignation, une concatnation, une soustraction, etc. Toute donne drive directement ou indirectement dune donne source appartient un tat drivation et tout objet dun tat drivation doit tre tiquete.

Puits : certaines mthodes critiques ncessitent que les arguments quelles manipulent soient sres , telle que la mthode connect() qui permet de se connecter une base de donnes. Si une telle mthode manipule une donne tiquete gnre directement ou indirectement (via un tat drivation) partir dun tat source, alors il existe une potentielle vulnrabilit. Ltat correspondant cette situation est appel puits.

Neutralisation : Des langages comme PHP prvoient des fonctions de validation permettant de vrier ou de valider des donnes issues dun tat source ou drivation. Ces fonctions pourraient tre galement dveloppes par le dveloppeur de lapplication ou par une tierce personne. Ltat

60

4. Dtection de vulnrabilits dans un programme

correspondant lappel une telle mthode est appel neutralisation. Une tiquette associe aux donnes gnres par un tat neutralisation doit tre retire.

4.3.2

Travaux existants

La plupart des travaux bass sur la dpendance causale est dynamique, la propagation des tiquettes se faisant pendant lexcution du code (programme). Cette technique est introduite dans Perl [Wal00]. Pour lappliquer, il faut utiliser le mode Taint. Les donnes extrieures (les entres utilisateur, les entres variables denvironnement et les chiers en entre du programme) sont explicitement marques par une tiquette (taint ). Ces donnes ne doivent pas tre utilises directement ou indirectement dans une commande qui invoque le shell ou une commande qui cre ou modie un chier, un rpertoire ou un processus. Perl ore aussi un mcanisme qui permet dannuler le marquage des donnes pralablement tiquetes en dnissant des expressions rgulires correspondant des donnes valides. Lutilisateur doit lui-mme dnir ces expressions rgulires, Perl rend ensuite valide tout objet tiquet (annulation de ltiquette) qui correspond des expressions rgulires. Cependant, lobjectif du mode Taint de Perl nest pas de dtecter des attaques mais des erreurs de programmation non-intentionnelles. Ruby [TCF05] propose une analyse granularit plus ne que Perl. La dpendance causale est applique au niveau des objets et non simplement au niveau des variables de type chane de caractres. Tout objet dont un attribut est tiquet au cours de lexcution du programme est galement tiquet. Toutefois dans ce cas lannulation de ltiquette devient plus complexe. En eet lannulation de ltiquette dun objet revient vrier que tous les attributs le constituant ne sont pas marqus par une tiquette. La dpendance causale a galement t utilise dans beaucoup de travaux danalyse dapplications Web, pour la dtection de vulnrabilits des attaques Web par injection de code telles que XSS et SQL injection. Ces outils sont gnralement appliqus des applications Web crites en langage PHP [NCE06, HYH+ 04]. Halfond et al. [WAP08] proposent un suivi au niveau des caractres. Leur systme ncessite une instrumentation (rcriture) du bytecode. Dans [CW09], Chin et al sinspirent de ces mmes travaux mais contrairement lapproche prsente dans [WAP08], les modications sont portes au niveau des bibliothques Java au lieu de la rcriture du bytecode de lapplication. Loutil propos est donc plus facile dployer et plus compatible par rapport au code existant. Sur le plan conceptuel, pour chaque chane String, une tiquette est associe chaque caractre la constituant, indiquant sil est driv de donnes vries ou pas. Les classes de la bibliothque Java relatives aux objets String (String, StringBuffer, et StringBuilder) sont instrumentes an denregistrer cette information dtiquette et de pouvoir la propager. Toutefois lanalyse au niveau caractre peut tre facile contourner. En eet, des attaques par injection de code sont souvent trs subtiles : un caractre crit dans un encodage particulier pourrait tre combin avec un autre caractre et gnrer une donne malicieuse. Livshits et al [LL05, MVBL05] proposent un outil danalyse hybride (statique et dynamique) destin des applications JEE (Java Entreprise Edition). Les vulnrabilits sont dnies dans un langage de requtes appel PQL(Program Query Language) dont la syntaxe est proche du langage Java. Une requte PQL est une suite dvnements incluant lapproche de propagation des tiquettes en fonction des dirents vnements. Une vulnrabilit est dtecte en cas de prsence dune correspondance entre le programme analys et une requte. Dans lanalyse statique le programme

4.4. Conclusion

61

est traduit en bddbddb 13 [JL04] et les requtes sont converties en langage Datalog 14 . Lanalyse dynamique permet de vrier les rsultats de lanalyse statique et de rduire le taux de faux positifs . Elle est base sur linstrumentation de bytecode. An de rduire les cots de cette instrumentation, seuls les cas dtects par lanalyse statique sont pris en compte. Les requtes doivent tre crites par lutilisateur pour reprsenter la vulnrabilit recherche. Dans le cas dune correspondance entre le programme et une requte, deux choix sont oerts, soit de se limiter lancer une alerte, soit de remplacer les mthodes critiques non scurises, par une autre plus scurise. Le code source de cet outil est disponible. Nous lavons test sur lapplication Java fournie en exemple et sur une application Web basique. Comme dans [SAP06], nous avons constat que loutil danalyse statique nest pas complet : aucun outil de conversion des requtes en Datalog nest fourni. Dautre part, lanalyse dynamique donne des rsultats sur les applications Java mais elle nest pas fonctionnelle pour des applications Web bases sur des servlets. Nous avons t particulirement intresss par lapproche de Livshits et al [LL05, MVBL05] ; notamment lanalyse dynamique qui permet de remplacer une mthode non scurise par une autre mthode plus scurise. Nous pourrions par exemple remplacer une mthode HTTPServletResponse.getWritter().println() par une mthode quon appellerait printAfterValidation() qui ltrerait les donnes avant de les envoyer au navigateur Web. Cependant, nous avons constat que les cots de cette analyse sont beaucoup trop importants pour tre supports par la carte puce. Les cots supplmentaires de cette approche incluent linstrumentation du bytecode, la taille de loutil danalyse qui doit tre charg dans la carte et aussi les fonctions scurises qui vont tre utilises pour remplacer des fonctions qui ne le sont pas. Vu ces direntes contraintes nous avons d abandonner cette solution pour nous consacrer une analyse statique base sur loutil Findbugs. Findbugs propose une analyse de ux de donnes intra-procdurale en calculant une abstraction de lexcution du bytecode. Loutil fait une simulation du processus dexcution mthode par mthode, sans tenir compte des dirents appels inter-mthodes ou interclasses. Lanalyse nest donc ni inter-procdurale ni interclasses. Au niveau dune mthode, lanalyse inclut des paramtres permettant dappliquer lapproche de dpendance causale. Nous avons utilis cet outil que nous avons amlior pour faire une analyse plus complte, interclasses et inter-procdurale, pour des applications Web Java Card 3. Nous prsentons notre contribution dans le chapitre suivant.

4.4

Conclusion

La scurit des applications Web contre des attaques par injection de code doit tre prise en compte depuis le dveloppement. Les donnes en entre doivent tre considres comme potentiellement malicieuses et lapplication doit inclure des ltrages de donnes pour vrier, ltrer, et valider ces donnes avant quelles ne soient utilises par des fonctions critiques. Lanalyse statique de bytecode permet de vrier la bonne implmentation de ces applications et cela, avant de les charger dans la carte puce. Associe la technique de dpendance causale, lanalyse statique de bytecode permet de vrier si les donnes douteuses sont ltres avant dtre utilises en paramtres de fonctions critique ou
13. Approche base sur les diagramme de dcision binaire dans la reprsentation des programmes Java 14. Datalog est un langage de requte et de rgles pour les bases de donnes dductives

62

4. Dtection de vulnrabilits dans un programme

pas. Cependant ce type danalyse est connu pour tre expos des faux positifs lis des cas indcidables o labstraction de lexcution du code peut ne pas tre prcise. A loppos, lanalyse dynamique est plus sre mais ncessite souvent une instrumentation du bytecode. Toutefois, cette instrumentation prsente deux inconvnients. En plus du risque de gnrer un disfonctionnement de lapplication en modiant le contexte dexcution du code original, linstrumentation gnre des cots despace mmoire et de temps dexcution trs important, sans compter le cot relatif lanalyse proprement dite. Les consquences de ces cots sont particulirement plus considrables dans un environnement contraint comme les cartes puce. Pour ces direntes contraintes, nous avons prfr opter pour une analyse statique que nous prsentons dans le chapitre suivant.

63

Chapitre 5

Analyse statique de bytecode Java Card 3

Sommaire
5.1 5.2 5.3 Prsentation gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reprsentation dune vulnrabilit XSS . . . . . . . . . . . . . . . . . Processus dexcution dun bytecode . . . . . . . . . . . . . . . . . . . 5.3.1 5.3.2 5.3.3 5.4 5.5 Zones de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 64 65 66 67 67 69 70 70 72 72 73 73 75 78 78 79 80 80 81 82 83 83

Les instructions de la JCVM . . . . . . . . . . . . . . . . . . . . . . . .

Findbugs et ses limites . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyse inter-procdurale et interclasses . . . . . . . . . . . . . . . . 5.5.1 5.5.2 5.5.3 Prsentation du concept de CFG . . . . . . . . . . . . . . . . . . . . . . Analyse inter-mthodes et inter-classes . . . . . . . . . . . . . . . . . . . Imprcision de lanalyse insensible au contexte . . . . . . . . . . . . . .

5.6

Analyse des ux de donnes . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 5.6.2 5.6.3 5.6.4 La dpendance causale . . . . . . . . . . . . . . . . . . . . . . . . . . . . tiquetage des conteneurs . . . . . . . . . . . . . . . . . . . . . . . . . . Dtection des champs persistants . . . . . . . . . . . . . . . . . . . . . . Dpendance causale inter-mthodes . . . . . . . . . . . . . . . . . . . .

5.7

API de ltrage XSS pour des applications cartes puces . . . . . . 5.7.1 5.7.2 5.7.3 5.7.4 5.7.5 Filtrage des donnes insres dans un lment HTML . . . . . . . . . . Filtrage des donnes insres dans des attributs HTML . . . . . . . . . Filtrage des donnes insres dans un code JavaScript . . . . . . . . . . Filtrage et validation des donnes insres dans les proprits de style HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Filtrage des donnes insres dans des valeurs de paramtres dURL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.8

Conclusion

64

5. Analyse statique de bytecode Java Card 3

5.1

Prsentation gnrale

Dans ce chapitre nous prsentons la premire partie de nos travaux (voir chapitre 8 pour la deuxime partie qui aborde le fuzzing sur le protocole HTTP). Notre approche se base sur une analyse statique du bytecode pour dtecter des vulnrabilits par injection de code dans des applications Web ddies des cartes puce. Nous nous intressons particulirement aux applications Java Card 3 [KLIC11]. Lapproche propose est base sur loutil danalyse Findbugs. Lanalyse eectue par Findbugs prsente plusieurs limites et un grand taux de faux positifs et de faux ngatifs. Nous avons amlior cette analyse par la construction dun graphe dappel complet, incluant les invocations de mthodes de mme ou de direntes classes, tout en tenant compte du contexte dexcution de chaque mthode. An de suivre la propagation des donnes dans une application, nous avons eectu une analyse intra et inter procdurale de ux de donnes. Notre analyse se base sur une reprsentation abstraite du fonctionnement de la JCVM (Java Card Virtual Machine) et une interprtation abstraite du processus dexcution dun programme. Nous utilisons la technique de dpendance causale dans le suivi des ux de donnes. Nous avons dvelopp un module (plugin ) XSSDetector additionnel au logiciel Findbugs qui permet de dtecter des failles dues au non ltrage des donnes non ables au niveau de tout point dinsertion ou elles pourraient tre interprtes. Une faille XSS est reprsente par un automate tats nis. Une vulnrabilit XSS est dtecte si une correspondance complte existe entre un chemin dexcution du programme et lautomate. Pour se prmunir des attaques XSS le dveloppeur doit prvoir des fonctions de ltrage. An de rduire la tche aux dveloppeurs et dviter les risques de failles dues un mauvais ltrage, nous mettons leur disposition une API JCXSSFilter. Cette API comporte un ensemble de fonctions permettant de neutraliser des donnes potentiellement malicieuses. Le dveloppement de JCXSSFilter, respecte les recommandations de lorganisation OWASP. Le module XSSDetector vrie que lAPI JCXSSFilter est utilise dans tous les points dinsertion dun programme o un ltrage est ncessaire.

5.2

Reprsentation dune vulnrabilit XSS

Les vulnrabilits XSS peuvent tre reprsentes sous forme dun automate tats nis (gure 5.1) compos principalement de quatre tats : I : tat Initial ; S : tat Source ; D : tat Drivation ; F : tat Final. Linvocation de mthodes retournant des donnes externes au programme fait passer lautomate de ltat I un tat S. Parmi ces mthodes, nous trouvons : HttpServletRequest.getParametter(), HttpServletRequest.getAttribute(), etc. La manipulation des donnes dun tat S par des mthodes autres que des fonctions de ltrage, telles que : _.append(x), new String(x), new StringBuffer(x), x.toString(), x.substring(_ ,_), x.toString(_), etc (x tant une donne gnre dun tat S ou D) fait passer lautomate ltat D.

5.3. Processus dexcution dun bytecode

65

Fig. 5.1 Automate dune vulnrabilit XSS La condition de passage ltat nal est dirente selon le type de la vulnrabilit XSS : Dans le cas dune XSS persistante : ltat nal est atteint si les donnes gnres dans un tat D sont stockes dans un champ persistant ; Dans le cas dune XSS volatile : ltat nal est atteint, en cas dinvocation de mthodes permettant dacher des donnes gnres par un tat D dans une page Web telles que : HttpServletResponse.println(), HttpServletResponse.sendError(), HttpServletResponse.setHeader(), etc. Atteindre un tat nal signie quune vulnrabilit XSS est prsente. Dans les deux cas, volatile ou persistante, une vulnrabilit XSS est dtecte sil existe dans le programme analys au moins une correspondance avec lautomate XSS.

5.3

Processus dexcution dun bytecode

Notre approche tant base sur une analyse statique, elle eectue une analyse du bytecode sans lexcuter rellement. Elle se base sur la simulation de toutes les structures de donnes que gnre la JCVM, dans lexcution dun programme. Une JCVM est une machine abstraite dnie par une spcication. Elle permet dexcuter des bytecode Java Card. Lors de son lancement, la JCVM initialise les espaces de donnes ncessaires lexcution du programme. Le tas (Heap) et lespace des mthodes sont les principaux espaces. Chaque thread du bytecode possde une pile prive o sont sauvegardes les frames. Une frame est cre chaque invocation dune mthode. Elle consiste en une pile doprandes, un tableau de variables locales et une rfrence au pool de constantes de la classe de la mthode courante.

Fig. 5.2 Reprsentation des structures de la JCVM

66

5. Analyse statique de bytecode Java Card 3

5.3.1

Zones de donnes

La mmoire de la machine virtuelle est organise en zones de donnes dont : le tas, la zone de mthodes et les piles Java (pile de threads ) permettant de stocker dirents types de donnes tels que les objets crs, les variables locales de mthodes, les oprandes des mthodes, les valeurs de retour de mthodes, etc. Il existe aussi des piles de mthodes natives pour les codes natifs appels par les applications Java. Certaines zones sont cres au dmarrage de la JCVM et sont dtruites seulement lorsque celleci est arrt. Dautres zones de donnes sont utilises pour chaque thread, et ont la mme dure de vie que le thread associ. Dans ce qui suit, nous prsentons brivement ces dirents espaces de stockage de donnes. 1. Le registre PC (program counter) La machine virtuelle peut excuter plusieurs threads la fois. Chaque thread possde son propre PC. Quand le thread excute une mthode, PC indique ladresse de la prochaine instruction du bytecode excuter. 2. La pile de la JCVM Chaque thread de la JCVM dispose dune pile prive, cre en mme temps que le thread. La pile est compose dun ensemble de frames [Apa06]. chaque invocation de mthode, une nouvelle frame est cre et empile au sommet de la pile Java du thread associ. Elle est dpile et dtruite la n de lexcution de la mthode. 3. Le tas Cest une zone mmoire commune tous les threads de la machine virtuelle, o sont stocks tous les objets instances de classes ou de tableaux. A chaque objet dinstance est associe une rfrence qui permet daccder aux valeurs de chaque champ et aux mthodes associes la classe de lobjet. La libration despace dans le tas est gre automatiquement par le ramasse-miettes. 4. Zone des mthodes La JCVM possde un espace de mthodes qui est partag par tous les threads. Cet espace contient le bytecode des mthodes, les constructeurs et des informations telles que la table des symboles de constantes, tables de mthodes, champs de classe. Elle contient aussi les informations de typage sur les objets (nom, modicateur, nom de la superclasse, nombre et noms des interfaces implmentes, nombre de mthodes) et pour chaque mthode, un descripteur (nom, modicateur, nombre et type de paramtres, type du rsultat, table des exceptions, etc.) 5. La table des constantes La table des constantes est alloue dans la zone des mthodes, pour chaque classe ou interface cre par la machine virtuelle Java. Elle contient plusieurs sortes de constantes telles que les valeurs de chanes de caractres, les valeurs de constantes entires, noms symboliques de classes, interfaces, mthodes, les variables de classe ou dinstance, etc. 6. La pile des mthodes natives Les mthodes natives sont des mthodes crites dans un autre langage que Java (C/C++, assembleur) et compiles vers un langage natif de la machine sous-jacente. Ces mthodes

5.3. Processus dexcution dun bytecode

67

sont charges dynamiquement lors dune invocation par un programme Java. Notre analyse ne stend pas ce type de mthodes. Nous nous limitons aux mthodes dnies dans lapplication analyse.

5.3.2

La frame

Une frame est gnre chaque invocation dune mthode. Elle permet de stocker des donnes ncessaires lexcution de la mthode et/ou des rsultats partiels de mthodes (des valeurs de retour ou des exceptions). Elle est compose dun ensemble de structures de donnes savoir : La table de variables locales : stocke les paramtres et les variables locales de la mthode. Les variables locales sont adresses par index. Lindex de la premire variable locale est 0. Les valeurs de type long ou double occupent deux variables locales conscutives. Lors de linvocation dune mthode dinstance, la variable locale dindex 0 est utilise pour rfrencer lobjet sur lequel la mthode a t invoque (this en langage Java) et les variables locales sont indexes de manire conscutive partir de lindex 1. La pile des oprandes : contient les rsultats partiels des calculs intermdiaires ou des valeurs de retour dinvocation dautres mthodes. Des informations complmentaires : il peut sagir dun registre contenant ladresse de la prochaine instruction excuter, appel communment program counter (pc), dune rfrence vers la table des constantes de la classe laquelle appartient la mthode, dune rfrence vers la table dexceptions de la mthode, etc.

5.3.3

Les instructions de la JCVM

Notre analyse tant base sur une interprtation abstraite de lexcution du bytecode, il est ncessaire de connaitre les direntes instructions dun bytecode et comment ces dernires sont interprtes dans la JCVM. Une instruction de la machine virtuelle Java est compose dun opcode sur un octet, spciant lopration eectuer, suivi par zro ou plusieurs oprandes servant darguments qui seront utiliss par lopration. Pour une grande partie des opcodes, le mnmonique qui leur est associ est prx par une lettre reprsentant le type de la donne associe ces instructions. Par exemple, la lettre "i" correspond la manipulation dune donne de type integer (entier sign de taille 32 bits sign). Dans ce qui suit, nous prsentons quelques exemples dinstructions.

Instructions de chargement et de stockage Les instructions de chargement et de stockage permettent de transfrer les valeurs entre les variables locales et la pile doprandes dune frame de la JCVM. Ces instructions peuvent tre classes comme suit : 1. Instructions de chargement de variables locales dans la pile des oprandes : iload, iload_N, lload, lload_N, oad, oad_N, dload, dload_N, aload, aload_N. 2. Instructions de chargement dune valeur depuis la pile des oprandes vers une variable locale : istore, istore_N, lstore, lstore_N, dstore, dstore_N, astore, astore_N.

68

5. Analyse statique de bytecode Java Card 3

3. Instructions de chargement de constantes dans la pile des oprandes : bipush, sipush, ldc, ldc_w, ldc2_w, aconst_null, iconst_m1, iconst_N, lconst_N, dconst_N. 4. Les instructions qui accdent aux champs des objets : (putstatic, getstatic, puteld, geteld) et aux lments des tableaux (baload, caload, saload, iaload, laload, daload, aaload, bastore, castore, sastore, iastore lastore, dastore, aastore), ces instructions transfrent aussi des donnes depuis et vers la pile des oprandes. Le format des instructions avec des lettres gnriques N dsigne des familles dinstructions spciques une instruction gnrique qui ne prend quun paramtre. Instructions de manipulation de la pile dexcution Ces instructions permettent de manipuler directement le sommet de la pile : pop, pop2, dup, dup2, dup_x1, dup2_x1, dup_x2, dup2_x2, swap. Les instructions arithmtiques Les instructions arithmtiques prennent deux valeurs sur la pile des oprandes et chargent le rsultat au-dessus de cette mme pile. Parmi ces instructions : Addition : iadd, ladd, dadd. Soustraction : isub, lsub, dsub. Multiplication : imul, lmul, dmul. Division : idiv, ldiv, ddiv. Reste (modulo) : irem, lrem, drem. OR (bit bit) : ior, lor. AND (bit bit) : iand, land. XOR (bit bit) : ixor, lxor. Incrmentation des variables locales : iinc. Comparaison : dcmpg, dcmpl, lcmp. Cration dobjet La machine virtuelle cre les instances de classe et les tableaux de faon distincte avec un jeu dinstructions propre chacun : Cration dune nouvelle instance de classe : new. Cration dun nouveau tableau : newarray, anewarray, multianewarray. Les instructions de branchement Les instructions de branchements conditionnels ou inconditionnels permettent la JCVM de continuer sexcuter avec une instruction dirente de celle suivant linstruction de branchement. Les instructions de branchement sont : Branchement conditionnel : ifeq,iflt, ifle, ifne,ifgt, ifge, ifnull, ifnonnull, if_icmpeq, if_icmpne,if_icmplt,if_icmpgt, if_icmple, if_icmpge, if_acmpeq, if_acmpne. Branchement conditionnel compos : tableswitch, lookupswitch. Branchement inconditionnel : goto, goto_w, jsr, jsr_w, ret.

5.4. Findbugs et ses limites

69

Instructions dinvocation de mthode

Les instructions suivantes permettent dinvoquer une mthode : Invokevirtual : invoque une mthode dun objet, en appelant la bonne mthode virtuelle de lobjet. Invokeinterface : invoque une mthode qui est implmente par une interface, en cherchant les mthodes implmentes par cet objet pour trouver la mthode approprie. Invokespecial : invoque une instance qui requiert un traitement spcial ; une mthode dinitialisation dinstance, une mthode prive, ou une mthode de la super classe. Invokestatic : invoque une mthode de classe statique.

Les instructions de retour de mthodes

Elles se distinguent par leur type de donnes de retour. Linstruction return est utilise pour un retour depuis des mthodes dclares void, des mthodes dinitialisation dinstance, et des mthodes dinitialisation de classe ou dinterface. les instructions dreturn, areturn et ireturn sont utilises pour retourner des valeurs de type boolean, byte, char, short, ou int.

Lancement dexception

Une exception est lance par le programme en utilisant linstruction athrown ou par dautres instructions de la JCVM lorsquune condition inhabituelle est dtecte (par exemple, la division par zro).

5.4

Findbugs et ses limites

Notre analyse est base sur loutil Findbugs qui ore une reprsentation abstraite de lensemble des structures composant une JCVM. Lalgorithme ci-dessous prsente le fonctionnement de Findbugs dans lanalyse dun bytecode. Toutes les classes de lapplication sont visites sparment. Le dtecteur va ensuite itrer pour chaque mthode dnie dans la classe (mme si cette dernire nest jamais invoque dans le programme) et gnre une frame lui correspondant pour eectuer une analyse des ux de donnes. Si la mthode courante invoque une autre mthode, les traitements de la mthode invoque sont ignors. La frame de la mthode courante est dtruite la n de lanalyse.

70

5. Analyse statique de bytecode Java Card 3

Algorithm 1 Analyse statique par Findbugs

1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16:

Parcourir les classes de lapplication for Chaque classe do lire lensemble des mthodes dnies dans la classe courante for chaque mthode do Dtruire la frame prcdemment construite si elle existe gnrer la frame de la mthode courante for chaque instruction de la mthode do eectuer une analyse des ux de donnes mettre jour la frame suivant le type de linstruction visite if instruction== invocation dune autre mthode then ajouter un nouveau item dans la pile des oprandes pas de traitement de la mthode invoque ce niveau end if end for end for end for

Linterprtation abstraite du processus dexcution dans Findbugs est limite. Le suivi des ux de contrle nest pas interclasses et lanalyse des ux de donnes se limite au niveau dune mthode et ne tient pas compte des invocations imbriques entre mthodes. Par consquent, ce logiciel dans son tat ne conviendrait pas nos besoins. Il serait impossible de suivre la propagation des donnes dans tout le programme. Notamment dans le cas de donnes passes en paramtre dune mthode ou de variables de retour. Les champs de classe ne serait pas bien gres aussi (champs dnis par le modicateur static). Les champs de classes devraient tre modiables par toutes les mthodes de la classe et une modication devraient tre vue par lensemble de ces mthodes. Dautre part, nous avons constat que certaines instructions ne sont pas compltement gres par Findbugs, notamment les instructions de gestion des conteneurs telles aaload et astore. Nous avons amlior Findbugs par une analyse des ux de contrle et des ux de donnes qui est la fois intra-procdurale, inter-procdurale, inter-classes et galement sensible au contexte. Notre analyse de ux de donnes applique la technique de dpendance causale pour le suivi de la propagation des donnes dans un programme. Nous avons dvelopp un module (plugin ) de dtection des vulnrabilits XSS persistantes et volatiles.

5.5

Analyse inter-procdurale et interclasses

An de raliser une analyse inter-procdurale qui inclut les appels entre des mthodes de mme ou de direntes classes, nous avons construit un graphe de ux de contrle (CFG), sensible au contexte et global toute lapplication.

5.5.1

Prsentation du concept de CFG

Le CFG (Control ow graph ) est une reprsentation sous forme de graphe de tous les ux qui constituent les dirents chemins dexcution possibles dun programme. Un ux de contrle dsigne lordre dans lequel sont excutes les instructions ou les fonctions dun programme. Il peut tre modi ou interrompu par divers types dinstructions qui peuvent engendrer la sparation des

5.5. Analyse inter-procdurale et interclasses

71

ux en un ou plusieurs chemins. Dans Java ou particulirement Java Card, ces instructions peuvent tre divises en plusieurs catgories : Branchement inconditionnel : lexcution se poursuit une instruction dirente. Branchement conditionnel : dans ce cas, il existe au maximum, une alternative dexcution. Une condition doit tre satisfaite an quun ensemble dinstructions puisse tre excut. Branchement conditionnel choix multiples : ce sont des branchements conditionnels avec plus dune alternative dexcution. Boucle : consiste excuter zro ou plusieurs fois un bloc dinstructions tant quune condition nest pas encore satisfaite. Arrt inconditionnel : constitu des instructions capables darrter lexcution dun programme tels que les retours de fonction ou les leves dexceptions.

Fig. 5.3 Exemple de graphe CFG

Le graphe de ux de contrle est constitu de nuds et dartes. Les nuds correspondent aux blocs lmentaires qui sont constitus dune succession dinstructions ne contenant aucune rupture du ux de contrle et aucune cible dinstruction de branchement. Ce bloc possde un point dentre et un point de sortie. Ainsi si un bloc est excut, toutes les instructions le composant seront excutes sans interruption. Le point dentre du bloc peut tre atteint par plusieurs autres blocs, les liens entre ces dirents blocs sont reprsents par des arrtes qui relient les nuds correspondants.

72

5. Analyse statique de bytecode Java Card 3

5.5.2

Analyse inter-mthodes et inter-classes

An de suivre la propagation des donnes dans une application, il est ncessaire de connatre tous les chemins dexcution possibles incluant les appels entre des mthodes de mme classe ou de classes direntes. An de pallier aux limites de Findbugs nous avons construit un graphe dappel inter-classes sensible au contexte. Lalgorithme Algorithm 2 reprsente le processus de gnration du graphe dappel interclasses. La construction commence par lister lensemble des mthodes dnies dans lensemble des classes constituant lapplication. Nous sauvegardons une description qui distingue chaque mthode par son nom, son type, le nom de classe o elle est dnie et le contexte de lobjet auquel elle appartient. Un graphe de ux de contrle est construit pour cette mthode. Le code de chacune des mthodes enregistres est parcouru sparment. Si la mthode courante invoque une autre mthode, une arrte est construite entre les deux nuds correspondant ces mthodes. Ainsi, en itrant lopration pour chaque mthode de lapplication, nous obtenons un graphe complet incluant tous les appels interclasses. Algorithm 2 Graphe dappels inter-classes Lister lensemble des mthodes de toutes les classes Construire un nud pour chaque mthode appartenant un contexte de classe for Chaque classe du programme do for chaque mthode de la classe do rechercher toute invocation dune autre mthode et construire des liens entre le nud la mthode courantes et les nuds des mthodes invoques end for end for

5.5.3

Imprcision de lanalyse insensible au contexte

Lanalyse des ux de contrle permet de dterminer dans une suite dexcution, quelle sera la prochaine instruction qui va tre excute. Cependant, les variables pointes par linstruction peuvent dpendre fortement du contexte de la mthode dans laquelle elles sont traites. Dans une analyse insensible au contexte, deux invocations de contextes dirents une mthode m ne sont pas distingues. Les arguments formels des mthodes vont pointer sur tous les objets passs dans des mthodes de dirents appels. De faon similaire, le rsultat de retour dune mthode m pointera sur tous les objets qui peuvent tre retourns par m. Ce problme est appel "le chemin non ralisable" [LL05]. An de mieux comprendre ce problme considrons lexemple suivant :

Listing 5.1 Sensibilit au contexte

1 2 3 4 5 6 7

class MyClass { private String str ; public MyClass ( String str ) } this . str = str ; } public String getSTR () { return this . str ;

5.6. Analyse des flux de donnes

73

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 }

} public void doGet ( Ht tp Se rvl et Re qu es t request , H t tp S e rv l e tR e s p on s e response ) throws IOException {

String UserInput = request . getParameter ( " input " ) ; MyClass Obj1 = new MyClass ( UserInput ) ; String X = " Exemple " ; MyClass Obj21 = new MyClass ( X ) ;

String S1 = Obj1 . getSTR () ; String S2 = Obj2 . getSTR () ; }

Exemple Supposons le code du Listing 5.1. La classe MyClass agit comme un encapsuleur de la chaine de caractres str. Le code cre deux objets, Obj1 et Obj2, instances de la classe MyClass, et appelle la mthode getSTR() partir de ces deux objets. Lanalyse insensible au contexte consiste fusionner les informations des deux appels getSTR( ) dans les lignes 20 et 21. La variable this de la ligne 7, pointera sur les objets obj1 et obj2 allous en ligne 15 et 17. Ainsi this.STR pointera soit sur lobjet retourn en ligne 13 ou la chaine de caractres Exemple de la ligne 16. Au nal, si on considre que lobjet retourn dans la ligne 13 est tiquet, alors en appliquant la technique de dpendance causale, les deux variables S1 et S2 seront considres toutes les deux comme tiquetes. Une analyse sensible au contexte serait plus prcise : la mthode getSTR() serait analyse deux fois dans deux contextes dirents, et seule la variable S1 serait tiquete.

5.6

Analyse des ux de donnes

Notre analyse est base sur le contrle des ux de donnes an de suivre la propagation des donnes dans tout le programme. Nous nous intressons la fois aux ux de donnes internes une mthode (analyse intra-procdurale) et aux ux changs entre direntes mthodes de lapplication (analyse inter-procdurale). Lanalyse intra-procdurale consiste suivre la propagation des donnes dans une mthode, en tenant compte des dirents types dinstructions, des donnes manipules et de cas particuliers comme les branchements et les exceptions, etc. Lanalyse inter-procdurale permet de suivre les donnes propages entre direntes mthodes travers les paramtres ou la valeur de retour dune mthode ou dans les champs de classe communs un ensemble de mthodes de cette classe.

5.6.1

La dpendance causale

Notre approche applique une analyse de ux de donnes, base sur la technique de dpendance causale (Chapitre 4, section 4.3). An de suivre la propagation des donnes dans lexcution

74

5. Analyse statique de bytecode Java Card 3

abstraite dun programme, nous dnissons une tiquette isTainted associe chaque item (lment dune pile doprande, ou de la table des variables locales) potentiellement malicieux dans les structures de donnes composant la JCVM simule. La dpendance causale est initie par notre module XSSDetector qui associe chaque item correspondant un tat source S de lautomate XSS une tiquette isTainted. Ltiquette est propage tous les items gnrs partir dun tat D. Une vulnrabilit est dtecte quand une donne tiquete est rfrence par une fonction correspondant un tat nal F de lautomate. Findbugs permet de faire une analyse abstraite de lexcution du bytecode. Lanalyse quil propose est intra-procdurale. Elle traite tous les cas de branchement conditionnel et les exceptions. Cependant, de nombreux cas comme le suivi des ux externes la mthode (variables de classes, champs statiques) et le traitement des conteneurs (tableau et vecteur) ne sont pas prvus. Dautre part Findbugs parcourt toutes les mthodes de lapplication sans exception, indpendamment de leur contexte (algorithm 1). Notre outil commence son analyse partir dun point dentre du programme. Gnralement une servlet commence son excution partir dune des mthodes doGET() ou doPost() qui traitent respectivement les mthodes HTTP GET et POST. Seules les mthodes invoques partir dun point dentre sont analyses. Les mthodes dclares qui nont jamais t invoques dans le programme ne sont pas vries, ce qui permet de rduire considrablement le nombre de faux positifs quaurait gnres Findbugs. An de mieux comprendre le principe de la dpendance causale, supposons le code ci dessous, le code du listing 5.3 reprsente le bytecode correspondant au code source du listing 5.2

Listing 5.2 Code source

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 } } } finally { out . close () ; out . println ( X ) ; String X ; X = request . getParameter ( " name " ) ; public void doGet ( Ht tp Se rvl et Re qu es t request , H t tp S e rv l e tR e s p on s e response ) throws IOException { response . setContentType ( " text / html " ) ; PrintWriter out = response . getWriter () ; try {

Listing 5.3 Bytecode

5.6. Analyse des flux de donnes

75

1 2 3 4 5

Code ( max_stack = 2 , max_locals = 7 , code_length = 48) ... 15: 16: 18: 2 aload_1 ldc invokeinterface 0 astore aload_3 aload invokevirtual String ;) V (7) %5 java . io . PrintWriter . println ( Ljava / lang / %5 " name " (5) javax . servlet . http . H tt pS erv le tR eq ue st . (6)

getParameter ( Ljava / lang / String ;) Ljava / lang / String ; 6 7 8 9 10 11 23: 25: 26: 28: ... 47: return

Dans la ligne 3 du bytecode, aload-1 correspond au chargement de la variable locale 1 dans la pile des oprandes. Dans la ligne 4, la rfrence la constante name retrouve partir du constant pool est empile dans la pile des oprandes. la ligne 5 la mthode HttpServletRequest.getParameter() est invoque. Cette mthode permet de retourner des donnes entres par lutilisateur. Linterprtation de linstruction invokevirtual consiste dpiler les deux items au sommet de la pile et empiler litem correspondant la valeur retourne par la mthode HttpServletRequest.getParameter(). XSSDetector dtecte que lappel la mthode HttpServletRequest.getParameter() correspond au passage ltat S de lautomate XSS, dans ce cas une tiquette isTainted sera associe litem ajout la pile. la ligne 6, linstruction astore consiste retirer le sommet de la pile et le charger dans la table des variables locales lindex indiqu. Dans ce cas, ltiquette est galement propage la table des variables locales en associant ltiquette isTainted litem charg dans la table des variables locales. Lappel linstruction out.println(X) du code source correspond aux instructions 25, 26 et 28 du bytecode. Linterprtation de linstruction aload_3 consiste charger litem de la variable locale 3 dans la pile. cet item correspond au paramtre de la mthode println(). Vu que cette variable locale est tiquete alors litem charg au sommet de la pile va tre aussi tiquet. Linterprtation de linstruction invokevirtual (ligne 9) consiste dpiler le sommet de la pile. XSSdetector vrie dabord si cet item est tiquet. Ainsi, puisque cest le cas et que la mthode invoque JAVA.IO.PrintWriter.println() est une des mthodes dnies dans ltat F de lautomate XSS, alors XSSdetector, dtecte une correspondance complte avec lautomate XSS et lance un avertissement pour signaler une vulnrabilit XSS (volatile dans ce cas). An de faciliter la maintenance du programme, lensemble du chemin parcouru entre un tat S et ltat nal F est sauvegard dans un chier de journalisation.

5.6.2

tiquetage des conteneurs

La plupart des outils danalyse bass sur la dpendance causale eectue un tiquetage dun objet si un de ses lments est dtect comme potentiellement dangereux (tiquet). Cependant

76

5. Analyse statique de bytecode Java Card 3

cette technique peut gnrer un nombre important de faux positifs ou de faux ngatifs. En eet, si une donne malicieuse contenue dans lobjet est nettoye de tout caractre malicieux, cette dernire ne devrait plus tre considre comme malicieuse. Dans ce cas, faut-il annuler ltiquette de lobjet la contenant ? La rponse cette question pose un problme dans les deux cas. Lannulation de ltiquette prsente le risque de faux ngatifs, car dautres lments du conteneur peuvent tre malicieux et la garder risque de gnrer des faux positifs si tous les autres lments du conteneur sont correctement ltrs. Algorithm 3 tiquetage des conteneurs (tableaux et vecteurs)
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31:

container[ ] ; String str ; ... /* tiquetage dun tableau */ if instruction de chargement de str dans container[ ] then construire un tableau des indices tableauDesIndices[ ] associ au conteneur if str est tiquet then tiqueter la case correspondante dans le tableau des indices tableauDesIndices[ ] tiqueter lobjet container[ ] end if end if

/* annulation de ltiquetage en cas de ltrage */ boolean bool=faux ; if container[i] est ltr then if tableauDesIndices[i] est tiquet then tableauDesIndices[i].isTainted=false ; end if for int j allant de zro tableauDesIndices[ ].length-1 do if tableauDesIndices[i] est tiquet then bool=vrai ; end if end for if bool==vrai then tiqueter container[ ] ; end if end if

Dans Java Card 3, les conteneurs supports sont les tableaux et les vecteurs. An de palier au problme de dpendance causale dans ce cas, nous avons choisi dtiqueter les lments du conteneur aussi. Pour cela, chaque objet conteneur (tableau ou vecteur) dclar dans lapplication, lanalyseur dnit un tableau correspondant aux indices du conteneur (Algorithm 3). Quand une donne malicieuse est charge dans le conteneur, en plus de ltiquetage de lobjet conteneur, llment du tableau des indices, correspondant la donne non able est galement tiquet. Si un lment du conteneur est ltr, ltiquette de lindice lui correspondant est retire. Ltiquette du tableau est retire si et seulement si aucun des lments du tableau des indices nest tiquet.

5.6. Analyse des flux de donnes

77

tiquetage des objets instances de classe Dans cette section, nous dsignons par objet, une instance de classe. De mme que pour les tableaux et les vecteurs, ltiquetage des objets instances dune classe pause un problme. Pour comprendre la ncessit de ltiquetage des objets. Supposons lexemple du listing 5.4. Lobjet obj1 est une instance de la classe MyClass et un de ses attributs attribut1 est tiquet. Supposons aussi un tableau tab des objets instances de la classe MyClass. Ce tableau est persistant car il est dni par le modicateur static. Lobjet obj1 est stock dans tab1[ ]. Si lanalyse ne prvoit pas ltiquetage des objets dont un des attributs est tiquet alors obj1 ne sera pas tiquet, et par consquent, le tableau tab1[ ] ne le sera pas non plus. Lanalyse ne pourra donc pas dtecter la prsence de lattribut attribut1 dans un champ persistant. La donne malicieuse serait ainsi stocke de manire persistante dans la carte, ce qui correspond une vulnrabilit XSS persistante. An de palier ce cas, nous avons choisi dtiqueter tout objet dont un des attributs est tiquet. Si lattribut attribut1 est neutralis par un ltrage et si aucun des autres attributs de lobjet nest tiquet alors ltiquette de lobjet est annule.

Listing 5.4 Les objets instances de classe

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 }

class MyClass { private String attribut1 ; private String attribut2 ; public MyClass ( String str ) { this . attribut1 = attribut1 ; this . attribut2 = attribut2 ; } ... static MyClass [] tab1 ; public void doGet ( Ht tp Se rvl et Re qu es t request , H t tp S e rv l e tR e s p on s e response ) throws IOException { ... String UserInput = request . getParameter ( " input " ) ; String x = " str " ; MyClass Obj1 = new MyClass ( UserInput , x ) ; tab1 . addelement ( obj1 ) ;

78

5. Analyse statique de bytecode Java Card 3

25 26 }

...

5.6.3

Dtection des champs persistants

Rappelons que dans Java Card 3, un champ est dit persistant (sauvegard en mmoire non volatile) sil est dni par le modicateur static, ou quil est instance dune des classes javacard.framwork.applet ou javax.Servlet.ServletContext . Un champ volatile peut devenir persistant par accessibilit, si un champ persistant lui est aect. An de dtecter des attaques XSS non volatiles, il faut vrier quun champ persistant nest pas tiquet par ltiquette isTainted. Pour implmenter cette proprit, nous avons dni une nouvelle tiquette isPersistent qui est associe tout champ persistant et qui est propage tout item ou champ dpendant dun champ tiquet. Une vulnrabilit XSS persistante est dtecte en prsence dun item doublement tiquet par les tiquettes isTainted et isPersistent.

5.6.4

Dpendance causale inter-mthodes

Une mthode peut avoir une valeur de retour qui peut tre le rsultat de la manipulation de donnes potentiellement malicieuses (tiquetes). La valeur de retour peut tre utilise dans une autre mthode, dune mme classe ou dune classe dirente. Dautre part, un paramtre dune mthode peut tre le rsultat de la manipulation de donnes tiquetes. Notre analyse de ux de donnes est inter-procdurale, permettant de propager ltiquette entre une mthode appelante et une mthode appele. La gure 5.4 illustre le fonctionnement de la propagation de ltiquette. Supposons que M1 est une mthode qui invoque une mthode M2. La mthode M2 prend en entre deux paramtres, ces derniers sont calculs dans la frame frame1 de la mthode M1. Notre analyse permet de vrier si les paramtres calculs dans frame1 sont tiquets et propage ltiquetage aux items correspondants dans la table des variables locales de M2. Ce processus est ralis comme suit : Sauvegarde du contexte de la mthode M1 et de ltat de la frame frame1 ; Cration dune nouvelle frame frame2 pour la mthode M2 ; Si les paramtres calculs dans frame1 sont tiquets alors, mettre jour les items de la table des variables locales de frame2. la n du traitement de M2, si cette dernire retourne une valeur, un item correspondant cette valeur sera empil dans la pile de frame2. Une copie de cet item est empile sur la pile dexcution de la frame frame1. Ainsi, si cet item est tiquet, ltiquette sera propage frame1. A prsent, lanalyse de la mthode M2 est termine. La frame frame2 est dtruite et notre analyseur retourne au contexte de la mthode M1 sauvegard pour continuer le traitement des instructions suivantes.

5.7. API de filtrage XSS pour des applications cartes puces

79

Fig. 5.4 Suivi des ux de donnes inter-mthodes

5.7

API de ltrage XSS pour des applications cartes puces

An de protger une application contre des attaques XSS, il faut considrer toute donne gnre partir dune source externe lapplication comme potentiellement dangereuse. La meilleure protection contre des attaques par injection de code est de vrier et dchapper tous les caractres spciaux contenus dans ces donnes avant leur utilisation dans un contexte critique o ils pourraient avoir une autre interprtation que celle attendue. Contrairement dautres langages comme PHP, le langage Java ne prvoit pas de librairies ou de fonctions permettant de vrier et de neutraliser des donnes potentiellement malicieuses. Cependant, des tierces parties proposent des API que le dveloppeur peut utiliser dans le dveloppement de son application. Parmi ces API, OWASP propose lAPI ESAPI [ESA] qui comporte entre autres, des fonctions de ltrage bien dnies contre des attaques XSS. ESAPI est proprement dveloppe et son ltrage est ecace. Elle est galement simple dutilisation. Cependant, elle ne correspond pas notre plateforme dtude : la Java Card 3. Elle utilise des librairies Java qui ne sont pas supportes dans Java Card 3 telles que java.util.HashMap, java.util.LinkedList , etc. Notre API JCXSSFilter est une rcriture adapte en Java Card 3 de la partie de ESAPI qui permet de valider et dencoder des donnes potentiellement dangereuses. Le ltrage propos est bas sur le modle de "liste blanche" qui refuse tout ce qui nest pas spciquement autoris. Compte tenu de la faon dont les navigateurs Web analysent du code HTML, chaque point dinsertion a des rgles de scurit direntes. Souvent, la scurit utilise consiste encoder en entits HTML tous les caractres spciaux. Cette mesure nest ecace que dans des cas de donnes injectes dans le corps HTML, au niveau de balises HTML simple telle que <div>. Un ltrage spcique est ncessaire pour dautres points dinsertion tels que des blocs de JavaScript, les valeurs

80

5. Analyse statique de bytecode Java Card 3

dattributs HTML, dans des balises de style CSS, ou dans des attributs dURL [OWAb]. Nous prsentons dans ce qui suit chacun de ces points dinsertion et le ltrage spcique utilis pour chacun.

5.7.1

Filtrage des donnes insres dans un lment HTML

Les donnes non ables peuvent tre places dans un corps HTML. Cela inclut lintrieur des balises simples comme div, p, b, td, etc. Pour viter que ces donnes passent dun contexte de donnes un contexte de code, il sut de faire un ltrage simple qui consiste chapper certains caractres pour viter quils soient interprts comme un code ou un script par le navigateur Web. Exemple : points dinsertion dans des valeurs dattributs HTML <body>...filtrer les donnes avant de les placer ici...</body> <div>...filtrer les donnes avant de les placer ici...</div> chapper ces caractres consiste utiliser un encodage en entits HTML pour empcher le passage tout contexte dexcution, tels que le script, le style, ou des gestionnaires dvnements. Utiliser la reprsentation hexadcimale est galement recommand dans les spcications. En plus des 5 caractres importants en XML (&, <,>, ", ), la barre oblique est incluse car elle contribue mettre n une entit HTML. Caractre & < > " / Encodage en entit HTML &amp ; &lt ; &gt ; &quot ; &#x27 ; &#x2F ;

Table 5.1 Exemples de caractres spciaux et leur encodage en entits HTML

5.7.2

Filtrage des donnes insres dans des attributs HTML

Les donnes non ables peuvent tre insres dans les valeurs dattributs comme la largeur, le nom, la valeur, etc. Elles sont utilises dans les attributs complexes comme href, src, ou des gestionnaires dvnements comme onmouseover. Les valeurs dattributs peuvent tre entoures de double ctes, de ctes simples, ou parfois sans aucune cte. Exemple : points dinsertion dans des valeurs dattributs HTML <div attr=...filtrer les donnes avant de les insrer ici...>content</div>

5.7. API de filtrage XSS pour des applications cartes puces

81

<div attr=...filtrer les donnes avant de les insrer ici...>content</div> <div attr="...filtrer les donnes avant de les insrer ici...">content</div> Pour prvenir la commutation des attributs HTML et empcher que des valeurs de donnes sortent du contexte de lattribut pour lesquelles elles sont prvues, il faut encoder tous les caractres spciaux par le format &#xHH, H tant la reprsentation en hexadcimale dun caractre, et le caractre & est utilis pour spcier le dbut dun nouveau caractre. Une cte fait partie des caractres spciaux quil faut chapper car elle marque la n dune valeur dun attribut cte. Le caractre & est galement spcial car il introduit un caractre ou spare des paramtres. Cependant souvent les dveloppeurs laissent les attributs HTML sans ctes. Les attributs non cts peuvent tre mal interprts (sortir du contexte prvu) et rpartis par des caractres dont , / ; < = > et | . An de rendre le ltrage puissant, nous avons suivi les recommandations dOWASP, et nous avons appliqu un encodage dun ensemble large de caractres qui comprend tous les caractres de valeurs ASCII infrieur 256, excepts les caractres alphanumriques en leur format \&#xHH.

5.7.3

Filtrage des donnes insres dans un code JavaScript

Le troisime point dinsertion est au niveau des codes JavaScript gnrs dynamiquement partir de blocs de scripts ou des attributs de gestionnaires dvnements. Le seul endroit sr o des donnes non ables peuvent tre insres dans un code est dans un point dinsertion entre deux ctes. Linsertion de donnes non ables dans dautres contextes JavaScript est dangereux. En eet, il est trs simple de changer le contexte dexcution courant en utilisant des caractres dont ;, =, +, etc. Il est donc recommand de les utiliser avec prudence et appliquer un ltrage puissant pour prendre en compte les dirents cas possibles.

Exemple : points dinsertion dans un script <script>alert(...filtrer les donnes avant de les insrer ici...)</script> <script>x=...filtrer les donnes avant de les insrer ici...</script> <div onmouseover="x=...filtrer les donnes avant de les insrer ici..."</div> La spcication OWASP dconseille fortement le ltrage utilisant des raccourcis comme un antislash. En eet, le caractre cte peut tre lu par lanalyseur dattributs HTML qui est toujours excut en premier. Dautre part, ce type de ltrage est vulnrable une attaque par chappement dun chappement qui consiste utiliser un deuxime antislash pour annuler celui utilis en protection. Si lattaquant injecte la chane \" et que la protection appliqu utilise un antislash \ alors on obtiendra la chaine \\" o la protection est annule et la cte est interprte. Le ltrage que nous avons implment consiste chapper tous les caractres de valeurs ASCII infrieur 256, excepts les caractres alphanumriques, en les encodant au format \xHH an de prvenir tout passage dun contexte de valeur de donne un contexte de script ou dun autre

82

5. Analyse statique de bytecode Java Card 3

attribut. Nous avons appliqu lencodage sur un ensemble aussi large de caractres, car les valeurs dattributs gestionnaires dvnements sont souvent laisss sans ctes. Les attributs non cts peuvent tre mal interprts et clats en plusieurs parties par des caractres tels que [espace] % * + , - / ; < = > . Dautre part, la balise de fermeture </script> pourrait fermer un bloc de script mme si elle est injecte lintrieur dune chane de caractres entre ctes car lanalyseur HTML est excut avant lanalyseur JavaScript. Cependant dans certains cas, les fonctions JavaScript ne devraient jamais utiliser des donnes non ables comme entres, mme si ces donnes sont ltres. Par exemple : <script> window.setInterval(...Quel que soit le filtrage utilis une vulnrabilit XSS est possible ici...); </script>

5.7.4

Filtrage et validation des donnes insres dans les proprits de style HTML

Les balises de style CSS sont utilises pour modier la typographie du texte. Elles peuvent contenir des points dinsertions o le dveloppeur peut dnir une proprit dun style. Cependant, CSS est trs puissant, et peut tre exploit pour de nombreuses attaques. Par consquent, il est important dutiliser des donnes non ables uniquement dans une valeur de proprit et pas dans dautres endroits dans les donnes de style. Exemple : points dinsertion dans des proprits CSS <style>selector { property : ...Filtrer les donnes non fiables avant de les insrer ici...; } </style> <style>selector { property : "...Filtrer les donnes non fiables avant de les insrer ici..."; } </style> <span style="property : ...Filtrer les donnes non fiables avant de les insrer ici...">text </style>

Certains contextes CSS ne devraient jamais utiliser des donnes non ables comme entre mme si un chappement correct de CSS est prvu. Il est recommand dviter des proprits complexes comme les URL, les proprits de comportement dnies dans Internet Explorer. Il est donc recommand de vrier que les URL commencent par "http" et non pas par "javascript" et que les proprits ne commencent jamais par "expression" (expression() est dnie par IE : elle permet dutiliser un code JavaScrip comme valeur dune proprit CSS) Exemple : { background-url : "javascript:alert(1)"; } { text-size: "expression(alert(XSS))"; }

5.8. Conclusion

83

Pour les mmes raisons que le ltrage prcdent, lutilisation dun chappement par le caractre antislash "\" est trs dconseille dans les recommandations dOWASP. Le ltrage propos consiste encoder tous les caractres ASCII infrieurs 256, excepts les caractres alphanumriques, au format \HH. Cet encodage est susamment fort pour empcher une XSS lorsque les donnes non ables sont places dans des contextes sans ctes. Les valeurs dattributs non ctes peuvent tre rparties si elles contiennent des caractres spciaux dont [espace] * % + , - / ; < = > | . Dautre part, linjection de la balise de fermeture </style> pourrait fermer un bloc de style, mme dans le cas o elle est utilise lintrieur dune chane entre double ctes car lanalyseur HTML sexcute avant lanalyseur JavaScript.

5.7.5

Filtrage des donnes insres dans des valeurs de paramtres dURL

Le dernier point dinsertion que nous avons pris en compte est la valeur dun paramtre dune URL. Une URL peut tre utilise dans une requte HTTP GET. Ses paramtres doivent tre considrs comme donnes non ables et tre ltrs en consquence. Exemple : points dinsertion dans des attributs dURL <a href="http://www.somesite.com?test=...Filtrer les donnes non fiables ici...">link</a > Les attributs dURL non cts peuvent sortir de leur contexte par de nombreux caractres spciaux dont [espace] *% +, - / ; < = > | . Le ltrage dans ce cas consiste encoder au format %HH tous les caractres de valeur ASCII infrieures 256, excepts les caractres alphanumriques. Cependant, dans le cas dune URL complte, il est recommand de la valider avant de lencoder. Si une entre non able est destine tre place dans href, src ou dautres attributs dURL, elle devrait tre valide an de sassurer quelle ne pointe pas vers un protocole inattendu, particulirement des liens JavaScript. LURL devrait tre ensuite encode en fonction du contexte dachage comme nimporte quel autre type de donnes HTML. Par exemple, un dveloppeur appliquant une URL axe sur les liens href doit utiliser un encodage des attributs. String userURL = request.getParameter( "userURL" ) userURLvalide= Valider(userURL) /* valider la valeur de userURL */ if (isValidURL) { <a href="<\%=utiliser le filtrage des atributs HTML sur userURLvalid\%>">link</a> }

5.8

Conclusion

Notre outil danalyse de bytecode est un moyen de prvention contre des vulnrabilits XSS permettant de vrier quune application est bien dveloppe, utilisant notre API de ltrage JCXXSFilter dans tout point dinsertion de donnes non ables. Cette analyse est eectue avant le chargement de lapplication dans la carte puce. Notre outil eectue une analyse statique et se

84

5. Analyse statique de bytecode Java Card 3

base sur la simulation du processus dexcution dun bytecode et du comportement de linterprteur de la JCVM. Il utilise la technique de dpendance causale dans lanalyse des ux de donnes intraet inter-procduraux et eectue un suivi de la propagation des donnes dans toute lapplication en se basant sur un graphe dappel interclasses sensible au contexte. An de rduire le nombre de faux positifs, nous avons gr les conteneurs et les donnes quils contiennent de faon prcise an dviter quune donne soit considre tort comme non able. Limplmentation de cet outil est prsente dans le chapitre suivant.

85

Chapitre 6

Implmentation et exprimentations
Sommaire
6.1 6.2 Prsentation de BCEL . . . . . . . . . . . . . . . . . . . . . . . . . . . Interprtation abstraite de la JCVM . . . . . . . . . . . . . . . . . . . 6.2.1 6.2.2 6.2.3 6.3 6.4 Simulation dune frame . . . . . . . . . . . . . . . . . . . . . . . . . . . Reprsentation dun item . . . . . . . . . . . . . . . . . . . . . . . . . . Plugin XSSDetector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 86 86 88 90 91 91 92 93 94 97

Implmentation de JCXSSFilter

Exprimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1 6.4.2 6.4.3 6.4.4 6.4.5 Stratgie dvaluation de loutil danalyse statique . . . . . . . . . . . . Temps de lanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dtection de vulnrabilits . . . . . . . . . . . . . . . . . . . . . . . . . Faiblesse de lanalyse statique . . . . . . . . . . . . . . . . . . . . . . . .

Surcot du ltrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

6.5

Conclusion

Notre outil danalyse statique fournit son utilisateur la liste des points du programme o une vulnrabilit XSS est dtecte. Lutilisateur doit par la suite corriger manuellement ces failles avant de charger lapplication dans la carte puce. Cet outil a t implment en Java en utilisant lAPI ByteCode Engineering Library. Notre API de ltrage JCXSSFilter a t dveloppe en Java Card 3 (sous ensemble de Java).

6.1

Prsentation de BCEL

BCEL [Apa06] est une librairie open source permettant danalyser, de crer, et de manipuler des chiers class. Ces chiers contiennent des classes qui sont charges en mmoire sous forme dobjets contenant toutes les informations sur la structure de cette classe : les mthodes, les attributs et les instructions (Opcode ). Elle est compose principalement de deux paquetages Java :

86

6. Implmentation et exprimentations

1. le paquetage contenant des classes permettant de lire le bytecode. Il est particulirement utilis dans lanalyse des applications Java dont le code source nest pas fourni. La principale structure de donnes de cette classe est la classe JavaClass qui contient les mthodes, les champs, le pool de constantes de la classe, etc. 2. le paquetage Java contenant des classes permettant de modier ou de gnrer des objets de type JavaClass ou Method. Loutil que nous avons dvelopp durant cette thse et loutil Findbugs sur lequel se base notre analyse utilisent cette librairie pour lire et parcourir les chiers class dune application.

6.2

Interprtation abstraite de la JCVM

Tel que prsent dans le chapitre prcdent, notre analyse statique se base sur une interprtation abstraite de lexcution dun programme. Linterprteur de la machine virtuelle est simul en implmentant le dispositif de frame dune mthode, la table des variables locales et la pile des oprandes. Lespace mmoire partag par un ensemble de mthodes est galement simul, an de grer la prsence des variables de classe et des champs statiques dans un programme. La simulation ne se limite pas implmenter les structures de donnes manipules par linterprteur, mais elle tient compte galement du fonctionnement de ce dernier pour lensemble des instructions possibles dans un bytecode. Notre analyse utilise un graphe dappel interclasses, sensible au contexte et parcourt tous les chemins dexcution possibles du programme analys. Le parcours du graphe dappel commence partir de points dentres bien dnis correspondant lappel des mthodes de traitement de requtes HTTP dnis dans la classe javax.servlet.http.HTTPServlet (exemple : doGet() et doPost()). Les structures de donnes composant la JCVM sont mises jour instantanment, suivant le type dinstructions visites et le type de donnes manipules.

6.2.1

Simulation dune frame

Linterprteur abstrait est principalement implment dans la classe opcodeStack de Findbugs. Il prend en entre un chier class qui est interprt et sauvegard dans un objet Java. Il eectue une excution abstraite des mthodes en simulant le dplacement du pointeur de code entre les direntes instructions et la frame Java. Nous avons modi la classe opcodeStack pour introduire la dpendance causale (tiquetage des items) et pour complter limplmentation de quelques instructions (opcode ) qui ntaient pas compltement gres. Le code du listing 6.1 nous montre limplmentation des structures de donnes reprsentant une frame avec sa pile des oprandes et sa table des variables locales.

Listing 6.1 Abstraction dune frame

1 2 3 4

class opcodeStack { private List < Item > stack ; private List < Item > lvValues ;

6.2. Interprtation abstraite de la JCVM

87

/* toutes les methodes necessaires a la gestion de la pile et de la table des variables locales : Item Item i ) , etc . */ pop () , void void push ( replaceTop ( Item newTop ) , void pop ( int count ) ,

6 7 8 9 10 11 12 13 14 /* traitement de l instruction et type d instruction . */ 15 16 17 18 } } } mise a jour de la pile et la tables des variables locales suivant le switch ( seen ) { /* seen est la representation en decimal d une instruction ( opcode ) */ public void sawOpcode ( int seen ) {

La pile et la table des variables locales sont reprsentes par des structures de donnes de type list (lignes 2 et 3) contenant des objets de type Item. La mthode sawOpcode(int seen) est appele chaque analyse dune nouvelle instruction du bytecode ; son paramtre seen est une reprsentation en entier dun Opcode visit. Cette mthode implmente le fonctionnement de linterprteur (ajouter ou supprimer un item de la pile ou de la table des variables locales ou de la mmoire partage) pour tous les cas possibles dinstructions. Lexcution abstraite de bytecode se base sur le suivi du graphe dappel interclasses de lapplication. Elle consiste maintenir le pointeur du code et la frame de chaque mthode de lapplication. Pour chaque mthode visite, linterprteur cre une frame compose principalement de la pile et de la table des variables locales. La hauteur de la pile va augmenter ou diminuer en fonction des instructions pointes. La reprsentation des structures de linterprteur abstrait est la mme que linterprteur classique de la machine virtuelle. Cependant, linterprtation des opcodes est dirente. Linterprteur abstrait eectue une analyse statique off-card 15 du bytecode ; les instructions ne sont pas rellement excutes, mais une abstraction de leur excution est eectue ; par exemple, dans le cas de linstruction iadd, la hauteur de la pile est diminue de deux lments (correspondant aux oprandes) puis augmente dun lment reprsentant le rsultat de laddition mais lopration daddition nest pas ralise. Dautre part, dans le cas des branchements conditionnels, la vrication de la condition tant impossible, nous traitons donc les dirents chemins possibles que la condition soit vraie ou fausse. Ceci est le cas des exceptions aussi.
15. ralis lextrieur de la carte puce

88

6. Implmentation et exprimentations

6.2.2

Reprsentation dun item

Les objets Item sont reprsents par une structure de donnes qui contient direntes informations sur une donne stocke dans la pile ou la table des variables locales (listing 6.2).

Listing 6.2 Reprsentation dun item

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

class Item { /* ensemble des information representant un item */ private int pc = -1; private String signature ; private Object constValue = UNKNOWN ; private @CheckForNull ClassMember source ; private int registerNumber = -1; private Object userValue = null ; private int f i e l d L o a d e d F r o m R e g i s t e r = -1; public static final @SpecialKind ; int isTainted = 0; int UnTainted = 15; public H t t p P a r a m e t e r I n j e c t i o n injection = null ; public ta bleauD esIndi ces []= null ; /* utiliser dans le cas ou l item correspond a un tableau ou un vecteur */ /* . . . */ public Item ( Item it ) { this . signature = it . signature ; this . constValue = it . constValue ; this . source = it . source ; this . registerNumber = it . registerNumber ; this . userValue = it . userValue ; this . injection = it . injection ; this . flags = it . flags ; this . specialKind = it . specialKind ; this . pc = it . pc ; } /* Toutes les fonctions permettant de manipuler les items ou de recuperer des informations : Item merge ( Item i1 , Item i2 ) , g e t F i e l d L o a d e d F r o m R e g i s t e r () , getPC () , etc . */

34 35 public boolean i s S e r v l e t P a r a m e t e r T a i n t e d () {

6.2. Interprtation abstraite de la JCVM

89

36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 } } } } }

return getSpecialKind () == Item . isTainted ;

public void s e t S e r v l e t P a r a m e t e r T a i n t e d () { setSpecialKind ( Item . isTainted ) ;

public void s e t S e r v l e t P a r a m e t e r U n T a i n t e d () { setSpecialKind ( Item . UnTainted ) ;

public void setSpecialKind ( int SpecialKind ) { item . SpecialKind = SpecialKind ;

tiquetage des items.

Lattribut SpecialKind est utilis an dappliquer ltiquetage des items

malicieux. Un item est source dune donne extrieure au programme si SpecialKind est gal isTainted. Cet attribut est manipul par les fonctions suivantes : setServletParameterTainted() est appele pour tiqueter les items rsultant dun tat S de lautomate XSS (chapitre 5, section 5.2), ou pour propager ltiquette un item gnr partir dun tat D, isServletParameterTainted() vrie si un item est tiquet ou pas, setServletParameterUnTainted() permet dannuler ltiquette dun item ; elle est appele dans le cas o litem correspondant passe en paramtre dune fonction de ltrage. Lattribut tableauDesIndices[] est utilis dans le cas o litem correspond un objet de type tableau ou vecteur. Ses lments sont de valeur "isTainted" ou "UnTainted". chaque fois quun lment est ajout dans un tableau une position i, si cet lment est tiquet alors la valeur tableauDesIndices[i] est mise "isTainted" sinon elle est mise "UnTainted". Lattribut injection est un objet instance de la classe HttpParameterInjection. Il est utilis pour sauvegarder un ensemble dinformations sur lorigine et le chemin dexcution qui a men jusqu la vulnrabilit. chaque visite dun tat D, lobjet injection de litem correspondant est mis jour en sauvegardant le numro de ligne courant du code source et le nom de la mthode visite.

Listing 6.3 La classe HttpParameterInjection

1 2 3 4 5 6

public class H t t p P a r a m e t e r I n j e c t i o n { private String parameterName ; private int line ; private Vector < LineInMethod > path = new Vector () ; private int pc ;

90

6. Implmentation et exprimentations

7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 }

public H t t p P a r a m e t e r I n j e c t i o n ( String parameterName , int pc , Method m , Vector path ) { this . parameterName = parameterName ; this . path = path ; int l = getSourceLine ( pc , m ) ; LineInMethod line = new LineInMethod (l , m ) ; this . path . add ( line ) ; } /* Calculer le numero de ligne dans le code source a partir de pc */ private int getSourceLine ( int pc , Method m ) { } private class LineInMethod { public int line ; public Method method ; public LineInMethod ( int line , Method m ) { this . line = line ; this . method = m ; } }

6.2.3

Plugin XSSDetector

Le plugin XSSDetector se charge de : ltiquetage des items gnrs dans un tat S ; la dtection des tats F ; la propagation des tiquettes inter-mthodes. Au lancement de Findbugs le plugin XSSDetector est charg. Les chiers class sont transforms en JavaClass. Lanalyse commence par la construction du graphe dappel complet de lapplication partir du module inter-class-calls. XSSDetector parcourt ensuite le bytecode partir des mthodes qui traitent des requtes HTTP (doGet(), doPost(), etc.) et cre une instance de la classe opcodeStack(que nous avons amliore) pour chaque mthode visite qui gnre la frame de cette mthode. Pour raliser une analyse interclasse, loutil consulte le graphe dappel complet an de connatre la prochaine fonction excuter et son contexte dexcution. Le code de la mthode est parcouru instruction par instruction, et les lments de la frame sont mis jour en fonction de linstruction visite. Dans le cas o linstruction visite est de type

6.3. Implmentation de JCXSSFilter

91

invokeinstruction (invocation dune mthode), alors une nouvelle instance de opcodeStack est cre pour la nouvelle mthode visite sans supprimer linstance prcdente (frame de la mthode qui linvoque). Le code de la nouvelle mthode est parcouru et sa frame est mis jour pour chaque instruction visite. Quand lanalyse de la mthode invoque est termine, la frame est supprime et lanalyse reprend au contexte de la mthode appelante pour continuer linterprtation des instructions suivantes. Comme expliqu prcdemment, nous tenons compte dans notre analyse de la dpendance causale inter-mthodes et nous propageons ltiquetage aux valeurs de retour et aux paramtres des mthodes. La propagation des tiquettes lintrieur de la mthode est ralise dans la classe opcodeStack modie. Un chier de journalisation est mis jour chaque dtection dune nouvelle vulnrabilit XSS. la n de lanalyse ce chier contiendra lensemble des vulnrabilits dtectes, indiques par le numro de ligne du code source o la faille a t dtecte et le chemin dexcution qui conduit cette faille. Nous avons galement implment lannulation de ltiquette pour des items ltrs. Sachant quil nexiste pas dAPI de ltrage XSS compatible avec Java Card 3, nous avons dvelopp lAPI JCXSSFilter compose de cinq fonctions de ltrage, chacune correspondant un point dinsertion particulier. Ltiquette dun item est annule sil est ltr par une de ces fonctions. Cependant notre outil danalyse statique ne permet pas de vrier si la fonction utilise est celle qui convient pour le point dinsertion courant.

6.3

Implmentation de JCXSSFilter

Pour utiliser lAPI JCXSSFilter, le dveloppeur doit limporter et ensuite appeler ses fonctions pour ltrer une donne. Elle est compose de cinq fonctions de ltrage. 1. EncodeForHTMLEnteties() : ltrage des donnes insres dans le corps HTML, entre des balises HTML simples ; 2. EncodeForHTMLattribut() : ltrage des donnes non ables injectes dans un attribut HTML ; 3. EncodeForjavascript() : encodage des donnes non ables injectes dans un code JavaScript prvu dans lapplication ; 4. EncodeForCSS() : ltrage des donnes non ables injectes dans des attributs de style CSS ; 5. EncodeforURL() : ltrage des donnes non ables injectes dans des attributs dURL. En plus de ses mthodes, nous avons implment la mthode Validator() qui est utilise pour valider le format dune URL.

6.4

Exprimentations

Ce chapitre dcrit les rsultats exprimentaux de notre outil danalyse statique et de lAPI de ltrage XSS prsente dans le chapitre prcdent. Lanalyse statique a t applique deux catgories dapplications de rfrence. La premire comporte un ensemble dapplications relles conues pour fournir des services bien particuliers et la deuxime est un large ensemble de programmes de base qui traitent une varit de cas qui peuvent se prsenter dans une application concrte. Notre

92

6. Implmentation et exprimentations

objectif est de vrier si notre outil danalyse traite le maximum de cas possibles et de dterminer sa performance en temps dexcution et le nombre de faux positifs gnrs. Nous avons galement test notre API de ltrage JCXSSFilter sur un prototype de cartes puce Java Card 3, an de tester son inuence sur la performance en temps dexcution.

6.4.1

Stratgie dvaluation de loutil danalyse statique

An de raliser un test pertinent de notre outil danalyse statique, il est ncessaire de lappliquer des applications industrielles destines tre utilises sur le march. Cependant, au jour o nous crivons cette thse, la carte serveur Web embarqu en particulier la plateforme Java Card 3 na pas connu un grand succs. notre connaissance, il nexiste aucune application Web pour carte puce sur le march. Nanmoins, nous avons exploit lapplication Disque virtuel dveloppe au sein de notre quipe (SSD) et prsente dans le chapitre 1, et une autre application nomme JC3CreditDebit qui est ralise au centre CNAM de Paris. Rappelons que lapplication Disque virtuel a pour but de scuriser laccs distance des chiers. Elle garantit que seul le propritaire dune carte puce (condentialit) contenant cette application, a le droit daccs, en lecture ou en criture, des chier chirs, sauvegards sur des serveurs FTP distants. Les cls de chirement/dchirement sont sauvegardes dans la carte puce. Lapplication JC3CreditDebit dveloppe par Thomas SOUVIGNET (tudiant du cnam de Paris) est une application de gestion de solde, utilisant deux types doprateurs : Visa et MasterCard au choix. Elle est compose de deux servlets de paiement qui partagent une interface SIO et qui grent les connexions externes. Nous avons galement dvelopp un paquetage dapplications de test nomm TestPackage qui a t inspir de lapplication Securibench Micro 16 . Il est compos dune srie de programmes simples qui traitent dirents cas possibles qui peuvent se retrouver dans une application concrte. Ces programmes sont classs en quatre catgories selon la proprit que nous voudrions tester. Les quatre sous paquetages de lapplication TestPackage sont prsents ci-dessous. Chacun de ces paquetages est compos dun ensemble de programmes : basique : ensemble de programmes traitant dirents cas de manipulation de donnes de type String et StringBuffer. conteneur : ensemble de programmes traitant dirents cas de manipulation des lments dun tableau ou dun vecteur. inter-procedurale : ensemble de programmes traitant des cas de propagation des donnes entre des mthodes dune mme classe ou de classes direntes. persistance : ensemble de programmes traitant les cas dobjets persistants. Le programme de test listing 6.4 traite un cas de manipulation de variables de type String. Lensemble des vulnrabilits sont indiques par des commentaires : /*Tainted*/ qui correspond la source et /*Bad*/ qui correspond un tat puits atteint partir dun tat source (vulnrabilit). Ces commentaires nous facilitent la comparaison des rsultats de notre analyse aux rsultats attendus. Dans cet exemple la ligne 3 correspond un tat S, une tiquette est donc associe la variable s1. Cette tiquette est propage aux variables s2, s3, s4, s5 et s6 car elles sont le rsultat
16. suite de programmes de test pour suif.stanford.edu/ livshits/work/securibench-micro/ des analyseurs dapplications JEE http ://-

6.4. Exprimentations

93

de la manipulation dune variable tiquete respectivement par les mthodes : toUpperCase(), concat(),replace(), append() et substring()(tats D). la ligne 12, la variable tiquete s6 est passe en paramtre de la mthode HttpServletResponse.getWriter().println(), lexcution passe donc un tat nal F et une vulnrabilit doit tre signale ce niveau.

Listing 6.4 Exemple de programme de test contenu dans lapplication testPackage

1 2 3 4 5 6 7 8 9 10 11 12 13

public class Basic6 extends BasicTestCase implements MicroTestCase { protected void doGet ( H tt pS er vl etR eq ue st req , H tt p S e rv l e tR e s po n s e resp ) throws IOException { String s1 = req . getParameter ( " name " ) ; /* Tainted */ String s2 = s1 . toUpperCase () ; String s3 = s2 . concat ( " ; " ) ; String s4 = s3 . replace ( ; , . ) ; String s5 = " : " + s4 + " : " ; String s6 = s5 . substring ( s5 . length () - 1) ; PrintWriter writer = resp . getWriter () ; writer . println ( s6 ) ; } /* BAD */

6.4.2

Temps de lanalyse

Pour les deux applications Disque virtuel et JC3CreditDebit , nous avons calcul le temps dexcution en trois phases : la premire correspond Findbugs la deuxime la gnration du graphe dappel interclasses et la dernire correspond lanalyse par dpendance causale, qui inclut la dtection des tats S et F et la propagation de ltiquetage. Pour les deux applications testes nous avons constat que la plus grande partie du temps a t occupe par le calcul du graphe dappel complet ; cela sexplique par le fait que le graphe dappels complet ncessite de parcourir toutes les classes de lapplication teste et toutes les mthodes contenues dans chaque classe pour gnrer lensemble des ux possibles de lapplication. Findbugs occupe galement une grande partie du temps de lanalyse. Durant cette phase, Findbugs charge notre plugin XSSDetector (et dautre plugins sils existent) et lapplication tester. Il eectue une premire passe du bytecode pour lire les chiers class et gnrer des objets JavaClass. Il lance ensuite une deuxime passe o les plugins sont excuts. Lanalyse par dpendance causale occupe la plus petite partie du temps. Cela est d au fait que lanalyse parcourt uniquement les chemins dexcution pr-calculs dbutant partir des mthodes qui traitent les requtes HTTP. Le temps total de lanalyse est faible dans les deux cas dapplications testes.

94

6. Implmentation et exprimentations

Application JC3CreditDebit Disque Virtuel

taille 68 ko 100 ko

Findbugs 843 ms 842 ms

construction du CFG interclasses 710 ms 825 ms

analyse 359 ms 452 ms

Table 6.1 Temps de lanalyse statique

6.4.3

Dtection de vulnrabilits

Lutilisation de notre outil pour vrier les applications Disque virtuel et JC3CreditDebit a permis de rvler des vulnrabilits XSS persistantes et volatiles dans ces applications. Les rsultats sont prsents dans le tableau 6.2. Application JC3CreditDebit Disque Virtuel XSS volatiles 8 5 XSS tantes 2 4 persistotal 10 9 faux tifs 3 1 posi-

Table 6.2 Rsultat danalyse des applications Disque virtuel et JC3CreditDebit

Dans lapplication JC3CreditDebit , lutilisateur est invit entrer un montant dbiter ou crditer. Le solde est ensuite sauvegard de manire persistante dans la carte et il est ach plusieurs niveaux dans les pages Web de lapplication. Vu que les valeurs entres par lutilisateur ne sont pas ltres, alors des vulnrabilits XSS volatiles et persistantes sont dtectes par notre outil danalyse. Le code du listing 6.5 est un cas o un faux positif a t gnr.

Listing 6.5 Faux positif gnr dans lanalyse de JC3CreditDebit

public void doGet ( Ht tp Ser vl et Re qu es t request , H t tp S e rv l e tR e s po n s e response ) throws IOException , ServletException {

2 3 4 5 6 7 8 9 10 11 12 13 14

// Creation du lien avec la SIO PMSIO pm = ( PMSIO ) ServiceRegistry . g et Se rv ic eR eg ist ry () . lookup ( SIO_URI ) ; ... // Creation d un canal de reponse PrintWriter out = response . getWriter () ; String login = request . getParameter ( " login " ) ; String pass = request . getParameter ( " password " ) ; if (! pm . isLoginCorrect ( login , pass ) ) { // Si mot de passe incorrect setHeader ( response , out , " Vous etes deconnectes " ) ; out . println ( " Vous etes deconnectes < br > " ) ;

6.4. Exprimentations

95

15 16 17 18 19 20 21 } else

// Fermeture de la page setFooter ( response , out ) ; { ... // login et password retournes en sortie out . println ( " < td colspan =2 > < input type =\" hidden \" name =\" login \" value =\" " + login + " \" > < input type =\" hidden \" name =\" password \" value =\" " + pass + " \" >) ;

22 23 }

Dans ce code les donnes dauthentication (login et le mot de passe) dun utilisateur authenti sont aches dans lURl dune page Web gnre par lapplication (ligne 21). Bien que lachage des donnes condentielles ne soit pas une bonne pratique (un attaquant peut les capturer et les utiliser pour usurper lidentit de lutilisateur lgitime), aucune vulnrabilit XSS nest prsente dans ce cas. En eet, le login et le mot de passe sont compars une liste didentiants valides par la mthode isLoginCorrect(login, pass) (ligne 10) et lURL nest ache que dans le cas o ces identiants sont valides (ligne 18). Vu que notre analyse ne vrie pas la vracit de la condition dans une instruction de branchement conditionnelle, alors une vulnrabilit est signale gnrant un faux positif. Lapplication Disque virtuel est compose de plusieurs points dentre o lutilisateur est invit ajouter un chier ou serveur par son nom et son adresse. Ces valeurs sont sauvegardes de manire persistante dans lapplication et sont retournes dans plusieurs sorties, gnrant ainsi des vulnrabilits XSS volatiles et persistantes. Les vulnrabilits dtectes sont dues la sauvegarde de ces donnes de manire persistante dans lapplication, et leur utilisation dynamique dans certaines pages Web de lapplication qui fournit la liste des noms de serveurs sauvegards dans lapplication ou la liste des chiers disponibles dans un serveur. Notre outil a dtect des vulnrabilits XSS (persistantes) mme dans le cas o un objet dont un attribut tiquet, est sauvegard dans un vecteur persistant. Les rsultats des tests que nous avons raliss sur notre application de rfrence TestPackage sont prsents dans le tableau 6.3. La deuxime colonne du tableau nous donne le nombre de vulnrabilits prvues pour chacune des proprits testes, la troisime colonne prsente les rsultats obtenus par notre analyse, et la quatrime colonne nous informe sur le nombre de faux positifs obtenus. Catgorie de test basique conteneur inter-procdural persistance Total Vulnrabilits implmentes 37 14 14 20 85 vulnrabilits dtectes 40 18 17 24 99 faux positifs 3 4 3 4 14

Table 6.3 Rsultats danalyse de lapplication TestPackage

96

6. Implmentation et exprimentations

Les rsultats que nous avons obtenus sont satisfaisants. Tous les cas de vulnrabilit que nous avons prvus dans notre application de test ont t dtects (analyse complte). Cependant, quelques faux positifs ont t gnrs, mais leur taux nest que de 14%. Les faux positifs sont une caractristique de tous les outils danalyse statique. Ils sont gnralement gnrs en prsence de conteneurs ou des instructions de branchement conditionnels. Dans le cas des conteneurs (tableau, vecteur), notre outil ne se limite pas ltiquetage de lobjet conteneur mais il applique un tiquetage des lments du tableau aussi. En eet, si nous nous limitons tiqueter le conteneur alors tous ses lments seront considrs comme non ables, mme si seulement un lment lest rellement. Ainsi, notre implmentation nous rduit considrablement le nombre de faux positifs. Les faux positifs. Une partie des faux positifs gnrs par notre outil est due au fait que dans certains cas des donnes tiquetes qui sont ltres sont considres comme non ables. Lexemple du listing 6.6 illustre un cas o il serait dicile de savoir si la donne est able ou pas. Dans cet exemple, nous dnissons une classe element contenant un attribut a1 et un vecteur tab persistant (dni par le modicateur static) dobjets instances de la classe element. Notre outil danalyse statique dtecte la ligne 3 un tat S, il associe donc une tiquette la variable s1. Cette tiquette est galement associe lobjet e1 auquel appartient cette donne. la ligne 8, la variable s1 est ltre en utilisant notre API de ltrage JCXSSFilter. Ltiquette qui lui est associe est donc retire. Cependant, lobjet e1 reste tiquet. En eet, il serait risqu de retirer ltiquette cet objet car il est possible que dautres attributs le composant soient non ables. Ainsi, la ligne 10, notre outil gnre un faux positif car il considre quun objet (e1) tiquet est sauvegard dans un vecteur persistant.

Listing 6.6 Programme de test sur les vecteurs

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

public class vecteur03 extends BasicTestCase implements MicroTestCase { protected void doGet ( H tt pS erv le tR eq ue st req , H t tp S e rv l e tR e s po n s e resp ) throws IOException { String s1 = req . getParameter ( " name " ) ; static Vector tab = new Vector < element >() ; element e1 = new element ( s1 ) ; element e1 = new element ( " toto " ) ; JCXXFilter . encodeforHTML ( e1 . get () ) ; tab . addelement ( e1 ) ; tab . addelement ( e2 ) ; } ... public class element { private String a1 ; public element ( String str ) { /* OK */ /* OK */ /* Tainted */

6.4. Exprimentations

97

17 18 19 20 21 22 23 24 } } } }

a1 = str ;

public String get ( String str ) { a1 = str ;

6.4.4

Faiblesse de lanalyse statique

Une analyse statique performante se doit de ne pas gnrer de faux ngatifs et prsenter le moins possible de faux positifs. Cependant nous avons dtect quelques cas particuliers qui gnrent de fausses alertes et quil serait dicile, de traiter par une analyse statique : Branchements conditionnels Dans certains cas, les faux positifs sont invitables pour une analyse statique, en particulier en prsence dinstructions de branchement conditionnel. Lexemple 6.7 illustre un de ces cas. Dans le code suivant, les lignes 5 et 10 correspondent des branchements conditionnels utilisant linstruction if. Les deux conditions correspondantes ne peuvent pas tre toutes les deux la fois vries (true ). En eet, un entier i ne peut pas tre la fois suprieure 1 et infrieur 2. Quand la premire condition est vrie, linstruction de la ligne 6 est excute, celle-ci prsente un tat S ; la variable X doit donc tre tiquete. Quand la deuxime condition est vrie linstruction de la ligne 11 est excute, celle-ci est une invocation de la mthode HttpServletResponse.getWriter().println() qui si ses paramtres sont tiquets, alors une vulnrabilit est dtecte. Mais comme la deuxime condition ne peut pas tre vrie, si la premire lest alors, ce code ne prsente aucune vulnrabilit. Cependant, notre outil ne traite pas la vracit de la condition dans une instruction de branchement conditionnel mais elle considre les deux cas possibles (vrai et faux). Une vulnrabilit est donc signale pour cet exemple, gnrant un faux positif. Une amlioration consiste vrier laccessibilit de chaque condition par rsolution des contraintes.

Listing 6.7 Faux positif indtectable par une analyse statique

1 2 3 4 5 6 7 8 9

class branchement05 { String X = " toto " ; if (i >1) { X = getParameter () ; /* Tainted */ } else X = " toto " ;

98

6. Implmentation et exprimentations

10 11 12 }

if (i <2) out . println ( X ) ; /* OK */

Ordre dexcution des mthodes HTTP Notre outil analyse une application en parcourant son graphe dappel partir dune mthode de la classe HTTPServlet qui traite les requtes HTTP (doGet, doPost, etc). Lanalyse consiste chercher ces mthodes (points dentres) dans le graphe dappel complet pr-construit et parcourir partir de ces points dentres tous les ux qui en dcoulent. Cependant, une application peut contenir plusieurs mthodes de la classe HTTPServlet, et lordre de vrication de ces direntes mthodes peut inuencer sur les rsultats de lanalyse. En eet, supposons le cas o une page Web est compose de deux liens, lun correspond une requte GET traite par une mthode doGet() dune servlet SERVLET et lautre est une requte POST traite par la mthode doPost() de la mme servlet. Supposons aussi une variable X (variable dinstance) qui est partage par ces deux mthodes (Listing 6.8). la ligne 6 du listing 6.8 notre analyse statique va tiqueter la variable X car la valeur de retour de la mthode request.getParameter() lui est aecte. La ligne 10 correspond linvocation de la mthode HttpServletResponse.getWriter().println() avec la variable X en paramtre, cela correspond une potentielle vulnrabilit XSS. Cette vulnrabilit nest eective que dans le cas o la mthode doGet() est analyse avant la mthode doPost(). Ainsi lanalyse statique peut donc engendrer des erreurs (faux positifs ou faux ngatifs) suivant son ordre danalyse. En eet, si notre outil commence par lanalyse la mthode doPost(), la potentielle vulnrabilit ne sera pas dtecte. Pour palier ce problme nous proposons de traiter les dirents cas possibles dordre dxecution des mthodes HTTP. Une autre solution moins exhaustive est prsente dans les perspectives.

Listing 6.8 Ordre dexcution des mthodes HTTP

1 2 3 4 5 6 7 8 9 10 11

public class inter - procedural10 extends BasicTestCase implements MicroTestCase { static String X ; protected void doGet ( H tt pS erv le tR eq ue st req , H t tp S e rv l e tR e s po n s e resp ) throws IOException { X = request . getParameter () ; } protected void doPost ( H tt pS er vle tR eq ue st req , H t tp S e rv l e tR e s po n s e resp ) throws IOException { PrintWriter out = resp . getWriter () ; out . println ( X ) ;

6.4. Exprimentations

99

12 13 }

Appels interclasses via des scripts Dans le cas prcdent, lordre dexcution des mthodes est alatoire et ne peut tre connu au pralable car il dpend du comportement de lutilisateur en interagissant avec lapplication. Dans cette partie, nous prsentons un autre cas particulier o lordre dexcution peut tre spci dans lapplication via des scripts (JavaScript) mais que notre analyse nest pas capable de dtecter. An de mieux comprendre, supposons un exemple dapplication compose de deux Servlets : Accueil, Servlet1. La servlet Accueil fournit une page Web constitue dun bouton dont un clic excute la mthode du script fonction.js. La fonction envoi() contient un appel la servlet SERVLET par son URI. La correspondance entre lURI et le nom de la servlet est prcise dans le chier de conguration web.xml.

Listing 6.9 Appel interclasses via un code JavaScript

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

public class Accueil implement HTTPServlet { public static String X = " toto " ; protected void doGet ( H tt pS er vl etR eq ue st req , H tt p S e rv l e tR e s po n s e resp ) throws IOException { ... X = req . getParameter ( " name " ) ; ... out . println ( " < script language =\" javascript \" type =\" text / javascript \" src =\" fonctions . js \" > </ script > " ) ; out . println ( " < td >< input type =\" button \" name =\" envoyer \" value =\" envoyer \" onClick =\" envoi () \" > </ td > " ) ; ... } public class Servlet1 implement HTTPServlet {

protected void doGet ( H tt pS er vl etR eq ue st req , H t tp S e rv l e tR e s po n s e resp ) throws IOException { ... PrintWriter out = resp . getWriter () ; ... out . println ( Accueil . X ) ;

100

6. Implmentation et exprimentations

23 24 25 }

...

Pour construire le graphe dappel complet, notre outil danalyse parcourt tous les chiers class de lapplication. Cependant la mthode doGet() de la classe Accueil appelle la servlet servlet1 via un script. Pour pouvoir dtecter cet appel lanalyse statique devrait analyser successivement : 1. le code HTML en paramtre de la mthode println() dans la servlet Accueil an de dtecter lappel au script (ligne 11), 2. le script fonctions.js pour dtecter lappel la servlet servlet1 via son URI, et enn 3. le chier de conguration Web.xml pour dtecter la servlet correspondant lURI. Cette analyse serait complique raliser et ncessiterait en plus de parcourir du bytecode, danalyser du code HTML et du code JavaSript. Notre outil se limite analyser des chiers class. Il nest donc pas en mesure de propager ltiquetage entre une mthode appelante et une mthode appele via un autre moyen quune invocation Java. Dans le cas de lexemple 6.9, si notre outil commence son analyse par la mthode doGet() de servlet1. La vulnrabilit XSS ne sera pas dtecte (faux ngatif).

6.4.5

Surcot du ltrage

LAPI de ltrage que nous avons dveloppe est une archive au format .jar qui doit tre charge en mmoire persistante non modiable : la ROM. Pour tre utilise dans une application, le dveloppeur doit limporter. Elle est compose de cinq fonctions que le dveloppeur doit utiliser avec prudence en choisissant la fonction qui convient au point dinsertion quil voudrait scuriser. La taille de lAPI JCXSSFilter est de 30ko. Par consquent elle est largement supporte dans la ROM dune Java Card 3 dont la taille est suprieure 256 Ko. Cette API serait galement supporte en terme de taille dans une carte puce Java Card 2.2 SCWS dont la taille de la ROM est suprieur 64 ko, cependant son implmentation est base sur le langage Java Card 3 (utilisation des types : Vector, String, StingBuffer). Des modications seraient donc ncessaires pour porter cette API dans des cartes SCWS. Pour tester linuence de lutilisation de JCXSSFilter sur la performance en temps dexcution, nous lavons applique dans lapplication Disque virtuel . Nous avons utilis dans un premier temps lapplication Disque virtuel pour calculer le temps dexcution des requtes possibles et nous lavons compar au temps obtenu en utilisant les fonctions de JCXSSFilter. La comparaison a montr que la dirence tait inconsidrable (de lordre de quelque nanosecondes). Cependant, notons que vu les contraintes de ressources de la carte puce, les applications qui lui sont ddies sont gnralement de petite taille compares des applications standards. Les points dinsertion seraient donc moins importants quune application Web classique. En consquence le nombre dappels aux mthodes de notre API ne peut pas tre important. Des rsultats exprimentaux que nous avons obtenus, nous dduisons que JCXSSFilter apporte de la scurit dans les cartes puce sans inuencer leurs performance.

6.5. Conclusion

101

6.5

Conclusion

Dans ce chapitre, nous avons expliqu la faon dont nous avons implment les dirents points essentiels de notre analyse. Nous avons galement prsent les rsultats exprimentaux sur des applications concrtes et une application de test. Les rsultats que nous avons obtenus ont montr lecacit de notre outil qui gnre un taux minime de faux positifs. Nous avons galement test notre API de ltrage JCXSSFilter pour vrier sa portabilit sur la carte et son inuence sur le temps dexcution. Les rsultats obtenus montrent que notre API JCXSSFilter est parfaitement supporte par des plateformes Java Card 3. Cependant de potentielles amliorations peuvent tre apportes, telles que lanalyse de propagation des contraintes qui permet la prdiction des branchements, et une analyse du code HTML pour vrier si une fonction de ltrage correspond au contexte dans lequel elle est appele.

102

6. Implmentation et exprimentations

103

Troisime partie

Scurit du protocole HTTP

105

Chapitre 7

Le protocole HTTP et les techniques de vrication

Sommaire
7.1 7.2 Introduction 7.2.1 7.2.2 7.3 7.3.1 7.3.2 7.3.3 7.4 7.4.1 7.4.2 7.4.3 7.4.4 7.4.5 7.4.6 7.4.7 7.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 106 Les techniques de vrication et de validation de protocoles . . . .

La vrication formelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Test de logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 108 Dnition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 tat de lart des logiciels de fuzzing . . . . . . . . . . . . . . . . . . . . 109 111 Le fuzzing sur carte puce . . . . . . . . . . . . . . . . . . . . . . . . . 110 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Principe de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . 111 Les requtes HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Les rponses HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Les champs dentte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Accs aux ressources protges . . . . . . . . . . . . . . . . . . . . . . . 115 Antmmoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Le Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Le protocole HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conclusion

7.1

Introduction

La multitude et la sensibilit des domaines dutilisation de la carte puce ont multipli les recherches sur les mcanismes de scurisation au niveau matriel. Cependant, la scurit de ces plateformes est galement lie aux vulnrabilits au niveau applicatif. Lutilisation dun serveur Web expose la carte puce des menaces supplmentaires. Pour ces raisons, il est ncessaire de garantir quaucune vulnrabilit au niveau des protocoles installs sur la plateforme nest prsente dans la carte. Il existe deux faons dliminer les vulnrabilits :

106

7. Le protocole HTTP et les techniques de vrification

lutilisation des mthodes formelles dans le dveloppement de logiciels sans faille, conformes leur spcication. la gnration dune suite de tests an de vrier que certaines proprits de scurit sont respectes dans la mise en uvre de lapplication. Souvent les modles formels vrient uniquement si le logiciel est conforme sa spcication, tandis que lapproche de test, en particulier le test par fuzzing, permet de dtecter des failles de scurit dans lapplication mise en uvre. La carte puce est un dispositif trs limit et le protocole HTTP est un protocole complexe, sujet aux erreurs. Notre travail a pour but de tester la conformit et la robustesse de limplmentation du protocole HTTP dans les serveurs Web, en particulier, les serveurs Web embarqus. Nous avons choisi la technique de fuzzing pour son ecacit dans la vrication des applications et systmes. Ce chapitre est constitu principalement de deux parties. La premire est un tat de lart des techniques de vrication de protocoles, en particulier le fuzzing. La deuxime partie prsente le protocole HTTP et ses principales caractristiques.

7.2

Les techniques de vrication et de validation de protocoles

La complexit dans la conception dun protocole rside dans la gestion de toutes les actions et ractions possibles. Cela signie quil faut prendre en compte toutes les commandes et les squences de commandes possibles. La vrication dune application consiste vrier quelle fonctionne correctement, respectant des proprits prdnies ; les techniques de vrication de protocoles sont gnralement bases sur les mthodes formelles. La validation dune application consiste la tester dans le but de rvler la prsence derreurs ou des cas de non-conformit la spcication. Nous dtaillerons ces deux techniques dans ce qui suit.

7.2.1

La vrication formelle

Pour vrier quune spcication respecte tous les besoins et que le protocole implment respecte sa spcication, diverses approches ont t utilises. Une catgorie doutils de vrication de protocoles est base sur les techniques de spcication formelle dont les modles de transition [Boc03, Hol91], les rseaux de Petri [YX11], les langages de modlisation formelle [MF05] et la logique temporelle [CMcMW04]. Les modles de transitions [STE+ 82] sont les plus souvent utiliss dans la modlisation des protocoles de communication car ces derniers sont bass sur un ensemble dvnements tels que des commandes ou des vnements de synchronisation. Les machines tats nis modlisent un protocole dont les vnements forment ses entres. Dautres mthodes qui ne ncessitent pas de dnition dtat explicite peuvent galement tre utilises. Une variante des systmes transitions consiste dnir les squences dentres et sorties autorises et leurs relations. Aprs la modlisation du protocole, il est ncessaire de vrier la validit de son implmentation. La validation de protocoles, consiste vrier labsence derreurs logiques de spcication telles que les erreurs dinter-blocages, les rceptions non spcies, etc. La spcication algbrique [BMV05] est une technique largement utilise dans la validation de protocoles cryptographiques [CDL06]. Elle

7.2. Les techniques de vrification et de validation de protocoles

107

consiste vrier le protocole en tenant compte de toutes les proprits algbriques de lalgorithme de chirement utilis. Lanalyse daccessibilit standard est gnralement lapproche la plus utilise. Elle se base sur une modlisation par automate tats nis. Ltat global du systme est exprim pour chaque transition. Chaque tat global est ensuite analys. Une recherche exhaustive vrie que tous les tats sont accessibles en toute scurit. Lanalyse daccessibilit est approprie pour dterminer si un protocole est correct par rapport sa spcication, mais elle ne garantit pas quil soit scuris. Une autre limitation importante de cette technique est lobligation de prendre des hypothses radicales an de garder un espace dtats rduit.

7.2.2

Test de logiciels

La validation dun logiciel en utilisant la mthode base sur des tests consiste excuter le logiciel en lui appliquant un jeu de tests dans lintention de dtecter des anomalies ou des dfauts (bogues) ou de rvler la prsence derreurs de non-conformit la spcication. Cette approche se base gnralement sur la comparaison des rsultats dexcution des tests sur lapplication aux rsultats attendus [BGLP08, UL07]. La norme IEEE (Standard Glossary of Software Engineering Terminology) dnit le test par : Le test est lexcution ou lvaluation dun systme ou dun composant, par des moyens automatiques ou manuels, pour vrier quil rpond ses spcications ou identier les dirences entre les rsultats attendus et les rsultats obtenus. Les outils de test peuvent tre classs selon : le moyen daccessibilit, la stratgie dvaluation ou le critre dvaluation. 1. Classication par accessibilit : le systme cibl peut tre fourni avec ou sans son code source. Nous distinguons : le test en boite noire : cette catgorie suppose navoir aucune connaissance sur limplmentation de la cible. Les tests sont slectionns partir dune spcication du systme cibl (formelle ou informelle). Le fuzzing est la mthode la plus utilise dans ce cas. le test en boite blanche : consiste slectionner des tests partir de lanalyse du code source du systme. 2. Classication par stratgie : dans le cycle de vie dun logiciel trois types de test peuvent intervenir : les tests unitaires : test des parties dun programme indpendamment les unes des autres ; le test dintgrit : test de la composition des modules via leur interface (vrication des communications entre modules, appels de procdures, etc.) ; le test systme : test de la conformit du produit ni par rapport ce qui est prvu dans le cahier des charges. Ces tests sont raliss en bote noire via linterface du systme. 3. Classication par critre dvaluation : les mthodes de test peuvent tre direntes selon le critre que nous souhaitons valuer : conformit : consiste gnrer des tests partir de la spcication et de vrier que toutes les fonctionnalits prvues sont implantes selon leur spcication ; robustesse : contrairement au test de conformit, les tests gnrs dans ce cas ne respectent pas les comportements spcis dans le but de dtecter si le systme gre les utilisations imprvues.

108

7. Le protocole HTTP et les techniques de vrification

performance : consiste appliquer les tests dirents niveaux de charge dutilisateurs et de mesurer la performance du systme (temps de rponse du systme, lutilisation des ressources, etc.) scurit : consiste appliquer une suite dattaques sur la cible pour dcouvrir les vulnrabilits et les faiblesses du systme. Les mthodes de spcication formelle se basent sur un modle de protocole et une procdure pour vrier des proprits bien dnies. Leur inconvnient est principalement le temps ncessaire la conception du modle et la ncessit de connatre limplmentation de lapplication vrie. Les approches bases sur le modle de transitions sont trs vite limites par lexplosion combinatoire des tats gnrs. Dautre part, la validation par test permet de dtecter des failles de scurit et de vrier la conformit et la robustesse des applications. Notre objectif tant de valider limplmentation du protocole HTTP dans les cartes puce (en boite noir), nous avons choisi la technique de test par fuzzing que nous prsentons dans la section suivante.

7.3
7.3.1

Le Fuzzing
Dnition

Le fuzzing est une technique de dtection derreurs dimplmentation logicielle par injection de donnes invalides. Le but principal du fuzzing est de russir faire passer le systme, lapplication ou le protocole dans un tat non souhait ou inattendu. On distingue trois techniques de gnration de donnes de fuzzing [TDM08] : la gnration alatoire : cette technique prsente linconvnient dtre "aveugle", gnrant un nombre important de donnes de test dont une grande partie pourrait tre rejete par le systme cibl. En eet, celui-ci rejettera les donnes ds quelles ne correspondent plus ce qui est attendu ; les modles de donnes : il sagit dune technique de gnration semi-alatoire. Elle se base sur un format descriptif des donnes valides que les donnes de fuzzing doivent respecter. Lecacit de cette technique nest plus prouver, condition que la spcication soit bien modlise. Cependant lcriture des modles de donnes est un processus complexe et fastidieux et ncessite de disposer de la spcication du systme ou de lapplication cible ; Les mutations : cest une alternative entre les deux prcdentes techniques. Elle consiste muter une session connue et valide (chier, rseaux, etc). Contrairement la technique prcdente, celle-ci ne requirt pas de connaissance particulire du protocole car elle utilise seulement une session connue et la transforme. Elle est donc facilement mise en uvre mais ne traite que les cas prsents dans le chier de test. Il existe galement des outils qui appliquent une combinaison de ces direntes techniques [MP07, Micb]. La gure 7.1 reprsente un modle gnral dun outil de fuzzing. Tous les outils de fuzzing partagent un ensemble de fonctions semblables, savoir : la gnration des donnes de test suivant une logique propre loutil, la transmission des donnes vers la cible, la surveillance et la sauvegarde des rponses et ractions de la cible,

7.3. Le Fuzzing

109

et ventuellement lautomatisation de lanalyse des rsultats (rduire autant que possible lintervention de lutilisateur dans lanalyse). Les deux derniers lments pourraient tre considrs comme facultatifs ou tre mis en uvre en dehors de loutil de fuzzing.

Fig. 7.1 Principe du fuzzing

7.3.2

tat de lart des logiciels de fuzzing

Les outils de test par fuzzing peuvent tre rpartis en deux types. Les outils spciques permettent de tester un programme ou un protocole particulier, alors que les logiciels de fuzzing proposent une interface de programmation permettant limplmentation doutils de test dirents niveaux (chiers, API, argument de lignes de commandes, etc). Dans ce qui suit nous prsentons quelques exemples de logiciels, open source, les plus connus : SPIKE : ce logiciel [Ait04] est crit en langage C. Il est ddi en particulier dvelopper des outils de fuzzing pour des protocoles rseaux. Il a t lorigine du concept de blocs qui a t repris dans plusieurs outils par la suite, dont Peach et Sulley, etc. Les structures de donnes sont rparties et reprsentes sous forme de blocs. Cette approche permet de faire abstraction de la construction des direntes couches dun protocole ; Peach : est une plateforme de fuzzing [Micb] dveloppe en Python et base la fois sur les modles de donnes et les mutations, dans la gnration des donnes de test. Elle applique galement le concept de blocs dnis dans SPIKE. Lutilisation de cette plateforme ncessite de dnir un ensemble de chiers XML, appels Pits, qui dcrivent le protocole cibl et la conguration du processus de fuzzing. Chaque chier peut tre compos de plusieurs blocs et spcier les champs sur lesquels le fuzzing sera appliqu. Peach prsente lavantage dtre exible, permettant lutilisateur de dnir sa propre stratgie de fuzzing (modication dune ou de plusieurs donnes, dnition des mutants utiliser, modication des parties du modle de donnes, changement des ux des modles dtats, etc). Un autre avantage de Peach est quil permet de congurer un fuzzing parallle sur plusieurs cibles la fois. Sulley : [P.A07] il se base galement sur la technique de gnration de donnes par blocs. tant principalement conu pour tester des protocoles rseau, la transmission des donnes

110

7. Le protocole HTTP et les techniques de vrification

est implmente par le mcanisme de sockets. Il utilise un ensemble dagents permettant de grer direntes cibles (communications rseau, dtection dventuelles failles, contrle de la machine virtuelle VMWare). Il ore plusieurs types lmentaires permettant de construire des trames (static, bit-field, size, etc). Fusil : [I.M] est une librairie dveloppe en Python, utilise pour crire des programmes de fuzzing. Elle a t conue la base pour les programmes GNU/Linux en ligne de commande. Elle utilise des agents qui schangent des messages pour dclencher des actions. Fusil ore diverses manires de rendre alatoire les donnes qui sont transmises lapplication. Il ore aussi des mcanismes pour injecter des donnes incorrectes via la ligne de commande, les variables denvironnement, les chiers de donnes, ou le rseau.

7.3.3

Le fuzzing sur carte puce

La plupart des outils de fuzzing sont ddis tester des protocoles rseau tels que les protocoles TCP/IP, mais leur utilisation ne se limite pas cet environnement. En eet, cette technique a t utilise dans dautres domaines tels que les applications en lignes de commandes, les formats de chiers ou les communications interprocessus. Le fuzzing a galement t appliqu dans le test des applications et protocoles pour cartes puce. Les premiers travaux [joi09] consistaient tester les applets par injection dune suite de commandes APDU invalides dans une entre de lapplet, dans le but de la forcer sortir de son contexte dexcution prvu (buer overow ) et de dtecter des failles qui sont exploites par la suite pour raliser des attaques. Des travaux plus rcents se sont intresss au test des protocoles implments dans les cartes puce. M.Barreaud [BLIC11, MICL11] dans ses travaux a dmontr lecacit de cette technique dans le test de la robustesse et de la conformit du protocole BIP implment dans les cartes puce serveur Web embarqu, par-rapport la spcication dnie par ETSI. Loutil propos est bas sur le logiciel de fuzzing Peach. Dans les travaux prsents par Lancia [Lan11], le logiciel Sulley est utilis pour tester et dtecter des failles dans un protocole de paiement scuris pour les cartes puce EMV. Dan Grin [Gri] propose un outil nomm SCFuzz, destin tester les Middlewares des cartes puce. En gnrant des exceptions, SCFuzz va permettre de se servir des dysfonctionnements observs an de dcouvrir ventuellement des vulnrabilits exploitables. Nous avons utilis la technique du fuzzing dans lobjectif de tester la robustesse et la conformit du protocole HTTP implment dans les cartes puce serveur Web embarqu. Loutil que nous avons dvelopp est bas sur le logiciel Peach. Notre choix pour ce logiciel est principalement d au fait quil a t prouv par plusieurs recherches, en particulier les travaux de M.Barreaud qui ciblent le mme environnement que celui auquel nous nous intressons (cartes puces serveur web embarqu). Dautre part, Peach permet de raliser les tests sur plusieurs plateformes en parallle, ce qui est trs avantageux pour nous, vu les fortes contraintes en terme de ressources des cartes puce. Dans la section suivante, nous prsentons les principales caractristiques du protocole HTTP ncessaires la comprhension du fonctionnement de notre outil prsent dans le chapitre suivant.

7.4. Le protocole HTTP

111

7.4

Le protocole HTTP

HTTP (Hyper Text Transfert Protocol ) [FGM+ 99] est le protocole de communication le plus utilis sur le Web. Il permet dacheminer un ux dinformations suivant larchitecture client/serveur. Le client est gnralement le navigateur Web (Mozilla, Konqueror, etc.) qui envoie des requtes un serveur (Apache, IIS, etc.) contenant des donnes. Un paquet HTTP est le plus souvent encapsul dans un paquet TCP qui lui-mme est encapsul dans des paquets IP et le tout dans des trames Ethernet. Un serveur peut contenir diverses ressources de dirents types notamment celles au format HTML. La localisation de ces ressources est base sur le concept des URIs. Cest un moyen simple pour un humain de mmoriser lemplacement dune ressource sur internet et dindiquer galement le moyen dy accder. Les URIs se dcomposent en deux catgories : URL (localisateur uniforme de ressource ) qui indique lemplacement dans sa forme absolue dune ressource (ex : http ://www.backtrack-linux.org/BT5-GNOME-ARM.7z) ; URN (nom uniforme de ressource ) : qui identie les ressources et non pas son emplacement.

7.4.1

Historique

A lheure daujourdhui, le protocole HTTP a connu trois volutions majeures. Le tableau 7.1 rcapitule brivement lvolution du protocole en indiquant la principale caractristique de chacune dentre elles. Version HTTP/0.9 HTTP/1.0 HTTP/1.1 Date 1989 1996 1999 RFC Non normalise 1945 2616 Caractristiques Communication basique Support des formats MIME Connexions persistantes

Table 7.1 Versions du protocole HTTP

7.4.2

Principe de fonctionnement

Le protocole HTTP repose sur une architecture client/serveur. Une application de ce genre suit la trame dchange suivante (gure 7.2) le client transmet une requte vers le serveur, contenant des informations sur la ressource demande ; le serveur renvoie la ressource demande si disponible ou, le cas chant, un message derreur.

7.4.3

Les requtes HTTP

La requte transmise par le client au serveur est compose dun ensemble de lignes (listing 7.1), dont : 1. la ligne de requte : contenant la mthode utilise, lURL de la ressource demande et la version HTTP utilise.

112

7. Le protocole HTTP et les techniques de vrification

Fig. 7.2 Communication en HTTP

2. les champs dentte de la requte : il sagit dun ensemble de lignes facultatives permettant de donner des informations supplmentaires sur la requte et/ou le client (navigateur, systme dexploitation, ...). Chacune de ces lignes est compose dun nom spciant le type dentte et dune valeur correspondante. 3. le corps de la requte : la requte peut optionnellement contenir un corps (des donnes) qui est notamment utilis pour transmettre des paramtres avec la mthode POST. Le corps est transmis aprs les lignes denttes, il est spar du dernier entte par une ligne vide spcie par un double CRLF (carriage return et linefeed ).

Listing 7.1 Exemple de requte HTTP

1 2 3 4 5 6

GET / index . html HTTP /1.1 Host : www . example . com Accept : */* Accept - Language : fr User - Agent : Mozilla /4.0 ( MSIE 6.0; windows NT 5.1) Connection : Keep - Alive

Les mthodes HTTP Le type des requtes HTTP est spci par des mthodes qui dnissent laction demande au serveur. La norme HTTP/1.1 dnit 11 mthodes parmi lesquelles 8 sont le plus souvent implmentes. Nous les prsentons ici : OPTIONS : permet de demander des informations sur les options de communication disponibles sur la chaine requte/rponse ; GET : est utilise pour rcuprer des informations spcies par une URI. Elle peut tre conditionnelle en utilisant les champs If-Modied-Since , If-Match ou partielle en utilisant le champ "Range" permettant de spcier une partie de la ressource demande ; HEAD : est identique GET, une exception prs. Le serveur ne doit retourner que lentte. Elle est utilise pour obtenir des informations sur une ressource sans en transfrer lintgralit ; POST : est utilise pour envoyer un nombre consquent de donnes vers un script hberg par le serveur qui va les traiter pour crer ou mettre jour une ressource. Elle est plus souvent utilise dans les formulaires HTML ;

7.4. Le protocole HTTP

113

PUT : permet un utilisateur de mmoriser un document sur le serveur (lURI de demande). La dirence entre la mthode PUT et POST est que lURI dans une demande POST identie la ressource qui va traiter lentit. A linverse, lURI dans la demande PUT identie lentit ; DELETE : demande au serveur la suppression de la ressource identie par lURI. Elle ralise laction inverse de PUT. TRACE : permet au client davoir en rponse une requte, un retour des informations reues par le serveur. Cela signie que dans le corps de la rponse, le serveur inclut les enttes quil a reus dans la requte mise par le client. Cette mthode est utilise pour tester la connexion. CONNECT : ne fonctionne que sur des serveurs mandataires et permet au client de se connecter via un tunnel HTTP (ou HTTPS pour des donnes chires). LINK/UNLINK : permet dassocier (et de dissocier) des informations de lentte un document sur le serveur. PATCH : Cette mthode est similaire au PUT lexception que lentit contient une liste des dirences entre la version originale et la ressource identie dans lURI. Les trois dernires mthodes prsentes sont rarement implmentes.

7.4.4

Les rponses HTTP

A chaque requte du client, le serveur retourne une rponse qui est compose de (listing 7.2) : la premire ligne : contient la version utilise du protocole, le code de retour, et linformation qui correspond la dnition en langage humain du code de retour. les lignes suivantes sont composes de dirents champs et potentiellement de donnes.

Listing 7.2 Exemple de rponse HTTP

1 2 3 4 5

HTTP /1.1 200 OK Server : HTTPd /1.0 Date : Sat , 27 Nov 2004 10:19:07 GMT Content - Type : text / html Content - Length : 10476

Les codes de retour

Le code de retour dune rponse HTTP permet de donner des informations sur le bon droulement de la communication. La norme du protocole HTTP/1.1 dnit 5 classes de code de retour. Le tableau 7.2 rcapitule lensemble de ces classes ainsi que les codes de retour les plus rencontrs.

114

7. Le protocole HTTP et les techniques de vrification

Classe 1xx (Information) 2xx (Succs)

3xx (Redirection)

4xx (Erreur du client)

5xx (Erreur du serveur)

Code 100 101 200 201 206 301 302 304 307 400 401 403 404 405 406 500 501 503 505

Information Continue Switching Protocols OK Created Partial Content Moved Permanently Found Not Modied Temporary Redirect Bad Request Unauthorized Forbidden Not Found Method Not Allowed Not Acceptable Internal Server Error Not Implemented Service Unavailable Version Not Supported

Table 7.2 Les codes de retour dune rponse HTTP

7.4.5

Les champs dentte

Certains enttes peuvent se trouver aussi bien dans la requte que dans la rponse : Content-Length : la taille en octet des donnes utiles. Content-Type : type du contenu transmis ainsi que le jeu de caractres utilis. Connection : options souhaites pour la connexion courante. Les enttes suivants nexistent que dans les requtes HTTP. Seul lentte Host est cependant obligatoire dans la version 1.1 de HTTP : Host : spcie le nom et optionnellement le port de lhte qui hberge la ressource demande ; User-Agent : indique le programme client utilis pour mettre la requte ; Accept : spcie les types de supports qui sont accepts ; Accept-Language : dnit les langues acceptes par le client ainsi que leurs facteurs de priorit ; Accept-Encoding : similaire au champ Accept, mais apporte une restriction sur le codage du contenu ; Accept-Charset : indique les jeux de caractres acceptables ; Keep-Alive : temps maximal dattente de la rponse et nombre maximum de requtes par connexion ; Cookie : donnes de cookie mmorises par le client ; Referer : URL de la page partir de laquelle le document est demand ; Cache-Control : spcie les directives qui doivent tre respectes par tous les mcanismes de mise en cache. Et parmi les enttes dune rponse, il existe : Content-encoding : dnit la mthode dencodage des donnes envoyes ;

7.4. Le protocole HTTP

115

Content-language : langue dans laquelle le document retourn est crit ; Date : date et heure courante du serveur ; Expires : date et heure aprs laquelle la rponse est considre comme expire ; Last-modified : date de dernire modication du document envoy ; Location : adresse du document lors dune redirection ; Etag : version du document ; Server : nom et version du logiciel serveur.

7.4.6

Accs aux ressources protges

Lorsquun client demande une ressource protge, il envoie une requte GET au serveur en indiquant lURL de celle-ci. Le serveur rpond par un code 401 (Authorization Required ) si toutes les conditions dauthentication ne sont pas remplies. La rponse contient lentte WWW-Authenticate qui indique la mthode dauthentication utilise. Le protocole HTTP supporte deux types de mthodes dauthentication : la mthode basic : cette mthode nest pas scurise car les donnes transmises ne sont pas chires. Elles sont simplement codes avec lalgorithme Base64. la mthode digest : utilise le hach du mot de passe transmis au serveur. Mme si cette mthode est plus sre que la mthode Basic, elle reste tout de mme sensible aux attaques (vol de chier de mot de passes). Quand le client reoit une rponse 401, il renvoie une nouvelle requte GET contenant le champ Authorization dont la valeur indique la mthode dauthentication utilise (Basic ou Digest ) ainsi que les valeurs des champs du formulaire dauthentication. Une authentication russie est suivie dune rponse avec un code de retour 200, incluant la ressource demande, sinon le code derreur 401 est renvoy.

7.4.7

Antmmoire

Les mcanismes de base dantmmoire ou mmoire cache dans HTTP consistent sauvegarder temporairement dans un cache les ressources demandes dans des requtes. Cette stratgie permet de rduire le nombre daccs au serveur et les envoie rpts dune mme ressource chaque requte. Il existe dirents niveaux de mmoire cache : cache local : un client peut tre amen demander souvent les mmes pages Web. Les pages Web charges sont stockes dans le cache durant un temps x par le client. A un nouvel accs une page, si cette page se trouve dj dans le cache et quelle est encore valide , le client sen sert directement. Cette technique peut limiter les transferts sur le rseau. Server Cache : est un cache intermdiaire entre le client et le vrai serveur. Il communique avec le vrai serveur et transmet les rponses au client tout en gardant une copie de celles-ci (cache). Si un client demande au serveur-cache une page qui se trouve dj dans son cache et quelle est encore "valide", il la transmet au client. Cette approche permet de diminuer la charge sur le serveur et le temps dobtention dune page. Server Proxy : Le serveur proxy est un intermdiaire entre le client et le serveur. Il sert de pare-feu. Il interroge le vrai serveur la place du client et sert de cache.

116

7. Le protocole HTTP et les techniques de vrification

Dans la version HTTP 1.1, lentte Cache-Control a t ajoute orant la possibilit de dnir des directives explicites aux caches HTTP. Lentte Cache-Control permet un client ou serveur de transmettre diverses directives dans des requtes ou des rponses. Ces directives outrepassent normalement les algorithmes de mise en antmmoire par dfaut. En rgle gnrale, si il y a un conit apparent entre les direntes valeurs dentte, cest linterprtation la plus restrictive qui sapplique. Les directives suivantes peuvent tre appliques : no-store : empche le stockage non volatile des donnes ; max-age : permet au serveur de xer la dure maximale de rtention ; no-transform : indique au cache quil ne doit pas transformer le corps du message quil reoit ; max-stale : permet un client dautoriser le(s) cache(s) renvoyer une rponse expire, tout en xant une limite cette premption ; min-fresh : permet un client dexiger une rponse qui sera valable pendant toute la dure indique.

7.5

Conclusion

Dans ce chapitre nous avons prsent le protocole HTTP et les direntes techniques de validation de protocoles, particulirement le fuzzing. Ltude approfondie de la spcication RFC 2616 du protocole HTTP, nous a permis de comprendre en dtail son fonctionnement et le rle de chaque champ composant les requtes et rponses. La complexit et le nombre dinformation important que peuvent vhiculer les requtes/rponses HTTP peuvent conduire des vulnrabilits dues au non-respect de la spcication ou des failles de scurit dans son implmentation. Nous prsentons dans le chapitre suivant notre outil de fuzzing, permettant de vrier la conformit et la robustesse du protocole HTTP embarqu dans les cartes puce.

117

Chapitre 8

Fuzzing HTTP
Sommaire
8.1 8.2 Prsentation gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lapplication PyHAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 8.2.2 8.2.3 8.3 8.3.1 8.3.2 8.3.3 8.3.4 8.3.5 8.3.6 8.3.7 8.3.8 8.4 Prsentation Fonctionnalits de PyHAT 117 118

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 . . . . . . . . . . . . . . . . . . . . . . . . . 119 123

Stratgie danalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Loutil Smart-Fuzz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

tude des requtes HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Conception dune BNF (Backus Normal Form ) HTTP interactive . . . . 128 Modlisation des donnes de test . . . . . . . . . . . . . . . . . . . . . . 128 Conguration de Peach pour les cartes puce SCWS . . . . . . . . . . . 129 Le paralllisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Fichiers de journalisation . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Analyse des vnements . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Conclusion

Dans ce chapitre nous prsentons notre deuxime contribution dans le cadre de cette thse, qui porte sur la scurit des cartes puce serveur Web embarqu, au niveau du protocole HTTP implment. Les failles dimplmentation dans un protocole peuvent tre dues au non respect de la spcication et conduire des vulnrabilits. Limplmentation du protocole HTTP doit respecter la spcication dnie dans RFC 2616 [FGM+ 99] et tre robuste et scurise en garantissant que des commandes sensibles (ajout, suppression, modication) ne puissent pas sexcuter dans un autre contexte que celui autoris. Pour vrier la conformit et la robustesse de limplmentation du protocole HTTP embarqu dans les cartes puce, nous avons choisi dutiliser la technique du fuzzing.

8.1

Prsentation gnrale

Loutil que nous avons mis en uvre permet de vrier limplmentation du protocole HTTP dans un serveur Web quelconque. Nous nous intressons particulirement aux serveurs web embar-

118

8. Fuzzing HTTP

qus dans des cartes puce. Nous navons aucune connaissance sur limplmentation du serveur cibl ; notre outil fonctionne en boite noire, en se basant sur la spcication HTTP. Notre outil est compos de deux applications complmentaires PyHAT (Python HTTP Assessment Test ) et Smart-Fuzz (gure : 8.1). Le fuzzing est ralis par lapplication Smart-Fuzz qui se base sur le logiciel Peach. Les donnes de test sont gnres de manire semi-alatoire en utilisant un ensemble de descripteurs de donnes (les modles de donnes, les modles dtats ainsi que les mutations) reprsentant les requtes HTTP et les dirents champs qui les composent. An de rendre le fuzzing plus intelligent et rduire le temps dexcution excessif d un nombre important de donnes de test dont certaines seraient inutiles, nous avons dvelopp lapplication PyHAT. PyHAT est excute en premier. Elle permet de dtecter les direntes fonctionnalits supportes par limplmentation du protocole HTTP dans la carte puce teste. Les rsultats de cette application sont ensuite exploits par loutil Smart-Fuzz qui limite la gnration des tests uniquement des fonctionnalits implmentes dans lapplication cible. Nous avons galement congur un fuzzing parallle pour rpartir les tests sur un ensemble de cartes la fois et rduire le nombre de donnes traites par une carte. Les rsultats du fuzzing sont rpartis dans des chiers dvnements structurs qui sont ensuite automatiquement analyss pour dtecter des vulnrabilits.

Fig. 8.1 Vue gnrale de loutil de fuzzing HTTP

8.2
8.2.1

Lapplication PyHAT
Prsentation

PyHAT est un outil danalyse de serveurs Web. Il permet de mettre en vidence les principales caractristiques des serveurs HTTP installs sur dirents supports. Il a t conu dans un but danalyser des serveurs embarqus dans des cartes puce, mais il est cependant en mesure dvaluer toute application implmentant le protocole HTTP du ct serveur (gure : 8.2). Le but principal de PyHAT est de recueillir autant dinformations que possible sur les fonctionnalits HTTP implmentes sur le serveur cibl an de rduire le nombre de tests raliser lors de ltape du fuzzing.

8.2. Lapplication PyHAT

119

Fig. 8.2 Fonctionnement de lapplication PyHAT sur une carte SCWS

8.2.2

Fonctionnalits de PyHAT

Dans ce qui suit, nous prsentons les direntes fonctionnalits HTTP que lapplication PyHAT permet de dtecter. 1. Dtection des mthodes HTTP implmentes Comme vu dans le chapitre prcdent, le protocole HTTP est principalement caractris par ses mthodes. Celles-ci permettent aux clients dinteragir avec les ressources du serveur et de spcier laction eectuer. La norme du protocole dnit 8 mthodes de base auxquelles peuvent se rajouter des extensions. La premire fonctionnalit de PyHAT est de tenter de dterminer celles qui sont implmentes dans un serveur donn. 2. valuation de la sensibilit la casse des requtes La spcication du protocole HTTP indique que les mthodes et enttes des requtes envoys au serveur doivent tre sensibles la casse. Les mthodes doivent tre entirement en majuscule (exemple : POST), tandis que dans les enttes, uniquement la premiere lettre des mots le composant est en majuscule (exemple : Transfer-Encoding). Notre outil dvaluation comporte une fonctionnalit qui permet de savoir si limplmentation du serveur test respecte cette proprit. 3. Dtection des versions supportes Depuis sa cration, le protocole HTTP a connu 3 versions majeures. PyHAT compte parmi ses fonctionnalits la dtection des versions supportes dans le serveur cibl. 4. Dtection des mthodes dencodage de contenu supportes Le protocole HTTP autorise lencodage du contenu dune page demande en appliquant une mthode spcie par le client et supporte par le serveur. Parmi les mthodes dencodage dnies dans la RFC 2616, IETF, on cite : gzip, compress, deflate. Il est possible dindiquer dans une requte une prfrence de type dencodage pour une ressource demande. Le mot cl identity signie que les donnes attendues ne doivent pas tre encodes. PyHAT dispose dune fonction lui permettant de dtecter quels mcanismes dencodage de donnes sont grs par le serveur.

120

8. Fuzzing HTTP

5. Dtections des enttes HTTP implments dans le serveur Nous avons prsent dans le chapitre prcdent la structure dun paquet HTTP. Outre la premire ligne concernant la requte eective, plusieurs autres champs (enttes) en rapport avec la ressource ou encore les capacits du client, peuvent tre intgrs dans ce paquet. PyHAT permet de dtecter les dirents champs implments. 6. Rcupration dune liste des pages du serveur PyHAT compte parmi ses fonctionnalits celle de rcuprer une liste des URI prsentes sur le serveur partir dune analyse de la page index se trouvant la racine de ce dernier. 7. Synthse des rsultats dans un chier au format XML Lapplication PyHAT gnre une synthse de lensemble des rsultats obtenus durant le processus dvaluation dans un chier au format XML, ce chier est utilis par lapplication Smart-Fuzz dans la gnration des donnes de test.

8.2.3

Stratgie danalyse

La stratgie applique dans PyHAT pour fournir les fonctionnalits listes prcdemment consiste transmettre au serveur cibl des requtes bien spcies et de dduire en fonction des rponses HTTP, si une fonctionnalit est implmente ou pas (gure 8.2). Comme prsent dans le chapitre prcdent, le protocole HTTP dnit un ensemble de codes de retour, chacun ayant une signication particuliere. Ces codes de retour ont t trs utiles pour dterminer les caractristiques du serveur test. PyHAT est conu pour tre appliqu sur tout serveur HTTP, quel que soit son environnement dexcution (standard, carte puce, etc.). Cependant dans le cas des cartes puce SCWS, nous dnissons une interface HTTP<->BIP qui se place entre le gnrateur des donnes de test (requtes HTTP) et le serveur SCWS. Son rle consiste encapsuler les paquets dune requte HTTP dans un format BIP support par le SCWS. Inversement, les rponses BIP reues par le serveur sont dcapsules an de rcuprer la rponse HTTP qui sera analyse (gure 8.2). Dans ce qui suit, nous prsentons la stratgie adopte pour limplmentation des direntes fonctionnalits de PyHAT. Cas des mthodes implmentes : la RFC 2616 indique qu un serveur DEVRAIT retourner le code dtat 501 (Non mis en uvre) si la mthode nest pas reconnue ou pas mise en uvre dans le serveur dorigine . Nous avons exploit cette proprit pour dterminer les mthodes implmentes dans un serveur. En pratique, pour chaque mthode, nous avons dni une requte respectant le format de la norme HTTP prsent dans le chapitre prcdent. Seule la premire ligne de la rponse nous intresse. En eet, partir de celle-ci nous pouvons isoler le code de retour et dterminer si la mthode concerne est implmente ou pas. Tester la sensibilit la casse : le test de la sensibilit la casse porte la fois sur le nom de la mthode et les champs de la requte. Pour raliser ces tests, nous dnissons dans un premier temps des requtes dont la mthode utilise est crite en minuscule. Dans un second temps, la mthode est formate conformment la norme (en majuscule), mais les autres champs sont crits de faon alatoire. Dans chacun des cas, lanalyse de la rponse se fait

8.2. Lapplication PyHAT

121

base du code de retour. En eet, si le serveur rpond avec un code 200 (OK) alors nous en dduisons que ce dernier ne fait aucune distinction entre les majuscules et minuscules. Cas des versions supportes : valuer quelles sont les versions du protocole supportes par un serveur est simple. Lors de lenvoi dune requte un serveur, ce dernier doit si cest possible rpondre avec la mme version que celle utilise par le client. Notre analyse se base donc sur ce fait et suit lalgorithme suivant : envoi dune requte dans une version donne ; rception de la rponse et analyse de la version utilise ; si la version de la requte est la mme que celle indique dans la rponse, alors celle-ci est supporte par le serveur ; sinon, la version utilise dans la requte nest pas supporte. Cet algorithme est rpt pour chacune des versions. Remarque : La norme dnit un code de retour correspondant une version non prise en charge (505). Cependant, nous avons remarqu que certains serveurs nen tiennent pas compte. Cest pourquoi nous avons choisi de suivre lalgorithme prcdent. Cas des encodages supports : Le serveur doit rpondre une requte en utilisant lorsque cest possible un mcanisme dencodage support par le client sinon aucun encodage nest ralis. Dun point de vue pratique, lorsquun client envoie une requte, il spcie quels sont les encodages quil supporte via le champ Accept-Encoding. Le serveur qui reoit cette requte commence par analyser ce champ. Si la valeur de ce dernier fait partie des mcanismes dencodage quil peut grer alors la rponse inclura le champ Content-Encoding dont la valeur sera la mme que lencodage utilis dans la requte. La norme dnit 4 valeurs possibles pour ces champs : gzip, compress, defate, identity. An de dterminer les encodages grs par un serveur, PyHAT envoie une requte par type dencodage et analyse le champ Content-Encoding de la rponse. Il existe deux cas possibles : la rponse ne contient pas le champ Content-Encoding. Dans ce cas, deux interprtations sont possibles : 1. lencodage nest pas gr ; 2. la valeur de lencodage dans la requte est identity. la valeur du champ Content-Encoding est la mme que dans la requte. Nous en dduisons alors que lencodage est gr. Cas des champs supports : la dtection des champs implments dans un serveur est de loin la tche la plus complexe raliser. En eet, la spcication HTTP ne fournit pas de rgles explicites permettant de dterminer pour lintgralit des champs si ceux-ci sont supports. La stratgie que nous avons adopte est celle denvoyer des requtes respectant le format dnit dans la norme avec un champ spci par la requte. En outre, en fonction de la valeur du champ, nous savons daprs la RFC 2616 quelle rponse du serveur nous devons nous attendre. Pour les champs dont aucune indication nest prsente dans la norme, nous considrons par dfaut quils sont implments. Le tableau 8.1 prsente quelques exemples de champs et la stratgie utilise pour vrier leur implmentation. Pour chacun de ces champs nous avons inject une valeur qui selon la spcication devrait retourner un code derreur particulier.

122

8. Fuzzing HTTP

Id 1 2 3 4 5 6 7 8

Champ Accept Accept-Charset Expect If-Modied-Since If-Range If-UnmodiedSince Range Content-Length

Valeur injecte text/plain ;q=1,text/html ;q=0 ISO-8859-1,utf-8 ;q=0 10-continue Sun, 06 Nov 2014 08 :49 :37 GMT UUID gnr alatoirement Sun, 06 Nov 1970 08 :49 :37 GMT 1-30 1000000000000000000000000000

Rponse due code 406 code 406 code 4xx code 200 code 200 code 412 code 206 code 413

atten-

Table 8.1 Stratgie de dtection des champs HTTP implments

Les lignes du tableau 8.1 sont expliques respectivement ci-dessous. 1. Interdire la rception de contenu HTML au prot de contenu de type text devrait provoquer au niveau du serveur lenvoi dune rponse indiquant son incapacit fournir ce type de donnes (code 406). 2. Si le serveur ne peut pas fournir au client une rponse qui applique un encodage spci par le client, il devrait renvoyer une rponse de type 406. 3. Une valeur du champ Expect qui ne correspond pas ce qui est dni dans la norme devrait engendrer une erreur de classe 4xx. 4. Si la ressource demande na pas t modie depuis la date indique, le serveur doit retourner un code 304. Dans notre cas, la date est invalide (suprieure lanne en cours) ; le serveur devrait alors retourner un code 200. 5. La valeur utilise pour le champ if-Range est gnre alatoirement, il est peu probable quelle corresponde ltiquette dune entit prsente sur le serveur. Le code attendu est donc 200. 6. Si une ressource na pas t modie depuis lheure indique, le serveur doit retourner un code 412. La date que nous avons xe tant trs ancienne par rapport la date courante, il est trs peu probable que la ressource demande nait pas t modie depuis celle-ci. 7. La demande de donnes partielles doit dboucher sur une rponse de type 206. Si ce nest pas le cas, la partie demande nest pas accessible ou le champ nest pas support. 8. Si un serveur reoit une demande avec un contenu de taille suprieure ce quil peut grer, il doit retourner un code 413. Cas de lURI Tracker : la rcupration de lensemble des URI dun site donn suit le principe de fonctionnement des aspirateurs de sites classiques. En partant de la page index du site, nous rcuprons toutes les chanes de caractres correspondant une certaine expression rgulire (dans notre cas, celle des attributs href). Nous recommenons lopration sur chacune des URI trouves en prenant soin deectuer quelques vrications : nous vrions que lURI dtecte nest pas dj prsente dans la liste des rsultats an dviter de boucler indniment.

8.3. Loutil Smart-Fuzz

123

dans le cas o une URL est rcupre (domaine/ressource) nous vrions que le domaine a la mme adresse IP que le domaine analys initialement.

8.3
8.3.1

Loutil Smart-Fuzz
Prsentation

Smart-Fuzz constitue le cur de notre outil de fuzzing HTTP, il est compos principalement de 4 parties : gnration des donnes de test, transmission des donnes la cible, gnration des chiers dvnements, analyse des rsultats (gure 8.3). Il est conu pour tester tout type de serveur Web, standard ou embarqu. Nous nous intressons particulirement au cas des serveurs SCWS. Son objectif est de vrier la conformit et la robustesse du protocole HTTP implment dans un serveur Web en analysant son comportement quand il reoit des entres invalides (crash, comportement inattendu de la carte, comportement non conforme la spcication). Pour gnrer les donnes de test, Smart-Fuzz se base sur le logiciel Peach. Il utilise des descripteurs de requtes HTTP prdnis et limite les tests sur uniquement des fonctionnalits supportes par la cible et qui sont spcis dans le chier rsultat de PyHAT. Smart-Fuzz est galement compos dune interface HTTP<->BIP optionnelle, utilise dans le cas de test sur des serveurs SCWS, pour garantir la compatibilit du format des donnes de test avec la cible. La dtection des vulnrabilits se base sur lanalyse des codes de retour, savoir : le code de retour BIP, le code de retour APDU status word contenu dans la rponse BIP et le code de la rponse HTTP en fonction des donnes envoyes en entre. Nous avons galement appliqu un fuzzing parallle pour optimiser le temps de fuzzing.

Fig. 8.3 Fonctionnement de lapplication Smart-Fuzz (cas des serveurs SCWS)

8.3.2

tude des requtes HTTP

La construction dun modle reprsentatif des requtes HTTP ncessite une tude exhaustive de ces dernires. Nous nous sommes bass sur la RFC 2616 pour tudier de manire dtaille les dirents champs qui composent une requte, en tenant compte de la version du protocole HTTP.

124

8. Fuzzing HTTP

La stratgie de notre outil de fuzzing consiste muter un champ par requte injecte et danalyser les rponses du serveur et de la carte compares aux rponses attendues. Telle que prsente dans le chapitre prcdent, une requte HTTP est compose de 3 niveaux, une ligne de commande, une ou plusieurs lignes correspondant aux enttes et optionnellement le corps de la requte :

<Requte> = <Method> <URI> <Version> CRLF *(<Header>CRLF) CRLF [<Corps>]

La ligne de commande La ligne de commande est compose des champs : <Method>, <URI>, <Version>, et CRLF <Method> : lensemble des valeurs de ce champ est bien dni. Il peut prendre comme valeur un des types supports par la plateforme teste (dtects par PyHAT ). Exemple : GET, POST. <URI> : dnit le chemin absolu ou relatif ( partir du serveur) qui localise la ressource demande dans la requte. <Version> : dnit la version du protocole HTTP qui sera utilise durant la communication (utilis uniquement dans les versions suprieures HTTP/0.9). Sa syntaxe est de la forme : HTTP/<major>.<minor>, <major> et <minor> tant des entiers. <Header> : permet au client dinformer le serveur sur ses capacits (langage accept, encodage accept, etc. . . ). Elle doit contenir le nom de lentte suivi de sa valeur, les deux parties tant spares par deux points comme suit : <champ> : *(<valeur>) <Corps> : est utilis pour acheminer les donnes dnies par lutilisateur. Il est reprsent sous forme dune chaine de caractres alatoire.

Les enttes HTTP Une requte HTTP peut tre compose de dirents champs (enttes) dont le format est diffrent les uns des autres. tant donne la quantit dinformations importante contenue dans la spcication du protocole HTTP, nous nous limitons dans ce qui suit la description de quelques exemples de champs que nous avons modliss. 1. Format de date et dheure Par souci de compatibilit avec les versions antrieures du protocole, nous tenons compte des dirents formats de date et dheure dnis dans chaque norme. Les trois dirents formats existants sont : Sun, 06 Nov 1994 08 :49 :37 GMT Sunday, 06-Nov-94 08 :49 :37 GMT Sun Nov 6 08 :49 :37 1994 Un serveur HTTP/1.1 doit prendre en compte ces trois dirents formats.

8.3. Loutil Smart-Fuzz

125

2. Caractristiques du contenu Le protocole HTTP permet de ngocier les caractristiques des ressources attendues (encodage, type, langue). Il existe dirents formats de codage de contenu (gzip, compress, deate, etc). Tous ces formats ont t dnis dans le registre de lIANA (Internet Assigned Number Authority ). Ils peuvent tre demands par le client dans le champ Accept-Charset ou dans le champ Content-Encoding. Par dfaut, le codage Identity (aucun codage) est appliqu. Lentte Accept dnit le type attendu : elle prend comme valeur un des types MIME ou le caractre * pour spcier que le client accepte tous les types/sous-types. Lentte Accept-Language spcie les direntes langues acceptes. 3. Codage de transfert Cest le type de codage appliqu une entit pour assurer un transport scuris sur le rseau. Contrairement au codage de contenu, cest une proprit du message en lui-mme. Il est dni par lentte Transfer-Encoding. La valeur chuncked dnie par la RFC 2616 pour ce champ permet de transmettre une ressource en une srie de fragments. Chaque fragment commence par un nombre reprsentant la taille en octet du fragment envoy. Si le nombre envoy est 0, cela signie latteinte de la n du message. Il existe des enttes spciques au cas du codage de transfert chuncked. Comme le message est gnr automatiquement, il est possible que certains enttes ne soient connus quaprs la gnration du message. Lentte Trailer permet de dnir les dirents enttes qui seront envoys la n du message. Lentte TE est utilis pour dnir quels codages de contenu (content-encoding) seront accepts par le client et si lentte Trailer est support par le client, le mot cl trailers est ajout la liste des encodages. 4. Valeurs de qualit Certains champs, notamment le champ Accept, utilisent des valeurs de qualit permettant de prciser un ordre de priorit des prfrences du client, concernant le type et lencodage des donnes attendues en rponse. Ces valeurs sont comprises entre 0.000 et 1.000 avec trois digits au maximum aprs le point. La valeur 0.000 signie que le type nest pas accept alors que la valeur 1.000 signie que cest la prfrence maximale. La valeur la plus forte compte toujours en premier. Si aucune valeur de qualit nest prcise, alors il sagit de la prfrence maximale. Exemple : Accept: text/plain; q=0.5, text/html text/x-dvi; q=0.8, text/x-c Cet exemple est interprt comme suit : "text/html et text/x-c" sont les types de donnes prfrs par le client, mais sils ne sont pas supports par le serveur alors il faut utiliser des entits text/x-dvi et si ce dernier nest galement pas support alors il faut utiliser le type text/plain. 5. tiquettes dentits Elles sont utilises dans les enttes E-tag, If-Match, If-None-Match et If-Range, Range pour comparer les versions de deux ou plusieurs entits reues aprs plusieurs demandes dune mme ressource. Elles sont utilises dans la gestion des caches pour vrier si la page a chang depuis la dernire requte. Ltiquette dune entit est une chane de caractres prsente entre guillemets avec ventuellement un prxe indicateur de faiblesse. Lindicateur fort (Strong Validators) est partag entre deux ressources si elles sont identiques octet par octet et lindicateur faible (Weak Validators) not par "W/", correspond vrier simplement que les

126

8. Fuzzing HTTP

ressources sont smantiquement quivalentes ; il est utilis pour allger les traitements sur certains serveurs. Exemple : ETag: W/"123456789" tiquette indicateur faible. ETag: "123456789" tiquette indicateur fort. 6. Transactions partielles Ce processus a t introduit dans HTML/1.1. Il consiste dcouper la ressource en parties (en octets). Le client spcie la partie de la ressource quil souhaite rcuprer dans lentte Range. La valeur de cet entte peut tre un intervalle doctets born (de loctet 200 loctet 400) ou innie ( partir du 100 me octet), ou consister en un ensemble de parties demandes dans une mme requte. Exemple : Range : bytes=100-1000 intervalle doctets born ("de loctet 100 loctet 1000") La rponse sera donc segmente, contenant les parties demandes. Si la requte nest pas satisfaite le code de rponse 416 sera retourn. La rponse contient lentte Accept-Range qui indique que lunit de mesure "octet" est accepte par le serveur et lentte Content-Range indique lintervalle doctets transmis et la taille totale de la ressource. Les serveurs qui implmentent les rponses partielles renvoient la partie demande avec le code 206 (partial content ) sinon le champ Range est ignor et la requte est traite normalement. 7. Le type Multipart Il procure un mcanisme commun pour reprsenter des objets composs dun ensemble de parties distinctes de types MIME. Tirs du format MIME, les types multipart permettent dencapsuler un ou plusieurs corps dans un mme corps. Comme dans le format MIME, une dlimitation boundary est utilise pour sparer les dirents corps. Chaque corps peut avoir dirents enttes qui renseignent sur les caractristiques dune partie. Exemple : Content-type: multipart/byteranges; boundary="content_example" type=Text/HTML; start=example1 --content_example Part 1: Content-Type: Text/HTML; charset=US-ASCII Content-ID: <example1> Content-Location: http://www.example.com/images/the.one --content_example Part 2: Content-Type: Text/HTML; charset=US-ASCII Content-ID: <example2> Content-Location: the.one ; Content-Base: http://www.example.com/images/ --content_example-Lentte Content-Type dnit le type et les sous-types des donnes (exemple Text/HTML) et exceptionnellement un paramtre charset dnissant le jeu de caractres utilis et spar du type de donnes par un point-virgule. La valeur de lentte Content-ID est une chaine de caractres identiant une partie de la ressource.

8.3. Loutil Smart-Fuzz

127

8. Les requtes conditionnelles Une requte peut tre rattache des conditions indiques dans les champs If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since, If-Range. Un de leurs cas dutilisation est en rapport avec la gestion du cache. Dans le cas o la page demande a dj t mise dans le cache, une validation est eectue pour savoir si la ressource du serveur a chang entre temps. Si la ressource na pas chang, le serveur ne va pas renvoyer la ressource mais juste les enttes de la rponse, ce qui amliore la performance du rseau. Le tableau 8.2 prsente le type de valeurs attendues pour chacune des dirents enttes : Entte If-Match If-None-Match If-Modified-Since If-Unmodified-Since Last-Modified If-Range Format de la valeur "tiquette dentit" "tiquette dentit" HTTP-date HTTP-date HTTP-date "tiquette dentit" | HTTP-date

Table 8.2 Les requtes conditionnelles

9. La persistance de la connexion Dans les premires versions du protocole HTTP, une connexion TCP tait ouverte et ferme pour chaque bloc requte/rponse, ce qui posait des problmes de congestion du rseau. Dans le Web, une ressource est presque toujours rattache dautres. Par exemple une page Web est rattache ses feuilles de style, ses scripts, ses images etc. Ce qui quivaut parfois bien plus dune dizaine de requtes GET. Si on multiplie cela par le nombre de pages demandes par un client et le nombre de clients simultans pour un serveur, les connexions TCP sont bien trop nombreuses et surchargent le serveur inutilement. Les connexions TCP sont devenues par dfaut persistantes dans la version HTTP/1.1, en ajoutant le champ Connection et sa valeur keep-alive qui force la connexion TCP rester ouverte. Le navigateur peut alors relancer une nouvelle requte sur une mme connexion, sans avoir rtablir un nouvel change TCP. La valeur close est rserve pour spcier que la connexion doit tre ferme aprs traitement de la requte en cours. 10. Mise en place dun champ HOST Avant la version HTTP/1.1, il nexistait pas de solution standard pour faire face aux problmes de confusion que rencontraient les serveurs hbergeant plusieurs sites Web de nom de domaine dirents et recevant une requte avec un chemin relatif. Do la mise en place de ce champ OBLIGATOIRE (le seul dans la norme HTTP) indiquant le nom du domaine rel et virtuel du serveur. Pour des soucis de rtrocompatibilit avec les anciennes versions, des rgles prcises doivent tre respectes pour des requtes HTTP/1.1. En eet, le domaine peut galement tre prsent dans le champ <Request-URI> si lURI est absolue et porter confusion avec le champ HOST. Ces rgles donnent la priorit au champ <Request-URI>, si ce champ contient le nom du domaine, le champ HOST doit tre ignor, si le nom du domaine pris en compte est invalide ou le champ HOST est absent, le code de statut 400 (Bad request) est renvoy, Le champ HOST peut-tre vide, il indique alors le mme nom de domaine que la couche de transport (TCP).

128

8. Fuzzing HTTP

8.3.3

Conception dune BNF (Backus Normal Form ) HTTP interactive

tant donne la masse importante dinformations contenues dans la RFC 2616, il nous est paru utile de crer un outil permettant de visualiser et de retrouver facilement et rapidement celles-ci. Nous avons implment une interface dveloppe en HTML et JavaScript. Elle se prsente sous forme de BNF interactive compose par une structure de liens o le plus haut niveau dune requte ou dune rponse HTTP est reprsent et chaque sous partie de cette dernire se dveloppe laide de clics. Lutilisateur peut ensuite rajouter les enttes quil souhaite. La description de chaque entte HTTP a t reprsente par 5 caractristiques : Do : explique le rle de lentte dans la requte/rponse, Compatibility : versions HTTP compatibles avec celui-ci, Constraints : spcie les fortes contraintes associes celui-ci, Warning : spcie certaines situations et traitements particuliers, Status-code : indique les codes de retour HTTP possibles pour cet entte, et pour quelle valeur chaque code est retourn. Lexemple ci-dessous nous montre la description du champ Date :

Fig. 8.4 BNF de lentte Date

8.3.4

Modlisation des donnes de test

Les donnes de fuzzing doivent respecter une logique de programmation du systme cibl an dviter que celui-ci les rejette ds quelles ne correspondent pas ce qui est attendu. Smart-Fuzz est bas sur le logiciel Peach qui gnre des donnes partir dun ensemble de chiers descripteurs des formats de donnes valides et applique des mutations sur les dirents champs composant un descripteur. Compte tenu du nombre important dinformations contenues dans la RFC, nous utilisons la BNF que nous avons conue pour la construction des chiers descripteurs. Ces chiers sont au format XML contenant un ensemble de structures de donnes. Ils sont gnrs par Smart-Fuzz et utiliss dans Peach pour la gnration des direntes donnes de test. Smart-Fuzz se base sur le rsultat de lanalyse de PyHAT, prsent dans un chier nomm assessment.xml, qui comporte toutes les fonctionnalits supportes (les mthodes, les champs, les encodages, etc.) dans la plateforme cible. Seules les proprits dnies dans le chier assessment.xml sont modlises et transmises Peach. Il existe principalement trois types de structures de donnes :

8.3. Loutil Smart-Fuzz

129

Modle de donnes : une requte HTTP est reprsente par lensemble des champs qui la composent. Les champs utiliss sont dirents selon le type de requte. Un modle de donnes est une reprsentation en XML de la structure des champs composant la requte. Il consiste galement dnir quels sont les lments que nous voudrions ou ne voudrions pas muter et de xer des valeurs par dfaut dans certains cas. Peach ore la possibilit de rpartir la description des donnes par blocs. Cette particularit ore lavantage de rduire la quantit de modle gnrer. En eet, chaque entte est reprsent par son modle, et pour modliser une requte il sut de runir les dirents modles correspondant aux enttes contenus dans la requte.

Modle dtats : il permet de constituer une squence dinstructions dans Peach, correspondant aux ux de donnes pendant le processus de fuzzing. En eet, dans certains cas, la rponse du systme peut dpendre dune suite dactions excutes dans un ordre bien dni. Un modle dtats doit contenir au moins un tat.

Mutations : en plus de la reprsentation des donnes par leur structure et leur ordre dapplication, nous avons dni les types de mutations utiliser. En eet, certains champs nacceptent que des types de donnes spciques tels que le type String. Le format de ces donnes peut galement tre x comme dans le cas des dates ou des URI. Lutilisation de cette approche permet de rduire considrablement le nombre de donnes de test utilises par loutil et dviter des tests inutiles avec des donnes non conformes.

8.3.5

Conguration de Peach pour les cartes puce SCWS

partir des chiers XML (pit les) que nous avons dnis, Peach construit les donnes HTTP injecter dans la cible. Cependant dans le cas des cartes puce SCWS, bases sur le protocole BIP, la carte sattend recevoir des paquets BIP encapsulant des paquets HTTP et Peach ne supporte pas le protocole BIP. An de palier ce problme nous avons utilis une application que nous appelons interface HTTP<->BIP . Cette interface joue le rle dun intermdiaire. Elle permet denvelopper des paquets de donnes au format HTTP dans un format BIP accept par la carte puce. Les rponses BIP sont galement traites par linterface HTTP<->BIP, pour ressortir la partie HTTP de la rponse, utile pour lanalyse des rsultats. Nous avons congur Peach an de dsigner linterface HTTP<->BIP comme cible du fuzzing. Nous avons spci un chemin daccs vers cette interface qui reoit les donnes de fuzzing pour les transfrer par la suite la carte puce dans un format BIP (gure 8.5).

Fig. 8.5 Fuzzing sur SCWS

130

8. Fuzzing HTTP

8.3.6

Le paralllisme

Linconvnient majeur du fuzzing est le temps important ncessaire avant la n de lanalyse. Le fuzzing peut dans certains cas prendre plusieurs jours avant darriver au rsultat nal. Ce temps est principalement relatif au nombre de donnes de test appliques au systme. Lutilisation des descripteurs de donnes (modles de donnes, modles dtats) et des mutations permet de rduire considrablement le nombre de donnes de test gnrer, compar un fuzzing alatoire. Lexploitation de lapplication PyHAT permet galement dviter des tests inutiles sur des fonctionnalits non supportes. An damliorer le temps dexcution, nous avons exploit loption du paralllisme oerte par Peach. En eet, Peach permet de congurer le fuzzing sur plusieurs plateformes la fois. Nous avons exploit cette proprit an de rpartir les donnes de test sur plusieurs cartes. Nous avons congur Peach de telle sorte gnrer autant densemble de donnes que de cartes disponibles. Peach va ensuite transmettre ces donnes aux direntes cartes (si les cartes sont bases sur du TCP/IP) ou vers linterface HTTP<->BIP (si les cartes sont bases sur le protocole BIP) qui les retransmet aux cartes SCWS. Ainsi le temps dexcution serait rduit T/N, T tant le temps ncessaire pour le fuzzing sur une seule carte et N le nombre de cartes utilises dans le fuzzing parallle.

Fig. 8.6 Fuzzing parallle sur plusieurs cartes puce

8.3.7

Fichiers de journalisation

An de vrier la prsence de failles ou de comportements anormaux dus au non-respect de la spcication du protocole HTTP, il est ncessaire danalyser les dirents messages envoys et reus par le serveur cibl. Pour cela nous sauvegardons une trace des direntes transactions durant le fuzzing dans des chiers dvnements. Il existe deux possibilits de gnration des chiers dvnements : utiliser le mcanisme par dfaut de Peach qui consiste tout sauvegarder dans un chier enregistr la racine de Peach, ou concevoir un systme de journalisation personnalis. An de faciliter lanalyse des rsultats, nous avons choisi de dnir notre propre organisation des chiers dvnements. Dans le cas de cartes SCWS, le mcanisme de journalisation (logging ) est gr par linterface HTTP<->BIP qui transmet les donnes de fuzzing la carte et reoit les rponses du serveur. Les rsultats sont rpartis et organiss par types de mthode HTTP et par nom dentte

8.3. Loutil Smart-Fuzz

131

mut dans la requte injecte. Nous dnissons un ensemble de rpertoires correspondant aux direntes mthodes supportes par lapplication cible. Chacun de ces rpertoires est compos de chiers correspondant aux dirents enttes supports. chaque test, des informations concernant la requte et la rponse changes entre Peach et la cible sont tries et sauvegardes dans le rpertoire convenu. Les informations recherches sont : le couple requte/rponse HTTP, la commande BIP, le code de retour HTTP, le code de retour de la carte status word . Ces informations sont spares par blocs requte/rponse.

8.3.8

Analyse des vnements

Lanalyse des rsultats consiste parcourir lensemble des chiers dvnements la recherche de comportements suspects ou non conformes la norme HTTP. Pour la plupart des outils de fuzzing existants, cette tche est eectue manuellement par lutilisateur. Ce dernier doit parcourir tous les rsultats pour dtecter une faille ou une anomalie. An de rduire lintervention de lutilisateur, nous avons conu une application appele Analyseur qui vrie automatiquement la prsence de motifs (patterns ) prdnis dans les chiers dvnements. Les comportements suspects recherchs sont : les requtes provoquant un arrt total des communications (crash du serveur). labsence de rponses HTTP (contient uniquement des trames TCP ou BIP). les codes de statuts incompatibles avec la mthode teste. une rponse une requte HTTP qui ne correspond pas la rponse prvue par la norme. la gnration derreurs APDU (SW : 6F00). LAnalyseur utilise en entre un chier qui comporte un ensemble de motifs recherchs dans les blocs requte/rponse sauvegards dans les chiers dvnements. Lensemble des chiers dvnements est parcouru pour dtecter la prsence dun des motifs prdnis. Parmi ces motifs : NO CHANNEL DATA : (motif spcial dans le cas de SCWS) est une rponse BIP gnre dans le cas o la carte puce rpond par une trame BIP sans aucun contenu HTTP. 6F 00 (motif spcial pour carte puce) : est un code de retour APDU de la carte qui signie que la requte a lev une exception Java non traite. 5XX : cette catgorie de codes de retour HTTP correspond une erreur interne au serveur. Des associations de motifs : pour vrier la prsence de codes de retour qui ne correspondent pas un type de requte, nous dnissons des expressions rgulires composes dune association de motifs entre la requte et la rponse. Lapplication Analyseur recherche dans les chiers dvnements la prsence dune de ces expressions rgulires prdnies. Par exemple : lassociation des motifs GET et 201 Created dans un bloc requte/rponse constitue une expression rgulire. En eet, selon la spcication HTTP le code de retour 201 ne peut pas tre une rponse une requte dont la mthode est GET, car ce code signie la bonne cration de la ressource envoye alors que la mthode GET ne renvoie pas de donne. Lanalyse automatique rduit considrablement la tche lutilisateur qui peut dsormais slectionner un ensemble de failles grce notre application Analyseur et ventuellement parcourir les quelques vnements restants manuellement pour une analyse plus approfondie si cest ncessaire.

132

8. Fuzzing HTTP

8.4

Conclusion

Loutil de test par fuzzing prsent dans ce chapitre est bas sur le logiciel Peach. Il permet de vrier la robustesse et la conformit de limplmentation du protocole HTTP dans un serveur Web, particulirement les serveurs Web embarqus dans des cartes puce. Nous supposons navoir aucune connaissance sur limplmentation du protocole HTTP test. Lavantage de notre outil est quil rduit considrablement le nombre de donnes de test en liminant des donnes inutiles qui ne rvleraient aucune information pertinente. Pour cela nous avons appliqu un ensemble de mcanismes savoir : conception dune application PyHAT permettant de dduire lensemble des fonctionnalits (mthodes, versions, champs, etc.) implmentes dans lapplication cible, construction dune reprsentation (modles de donnes, modles dtat) des requtes/rponses valides qui seront utilises dans la gnration des mutants, conguration dun fuzzing parallle. Notre outil est particulirement adapt des cartes SCWS (bases sur le protocole BIP) grce linterface HTTP<->BIP que nous avons dveloppe et qui gre la communication entre le gnrateur de tests (au format HTTP) et le serveur SCWS (communication BIP).

133

Chapitre 9

Implmentation et rsultats exprimentaux de Smart-Fuzz et PyHAT

Sommaire
9.1 9.2 9.3 Implmentation de PyHAT . . . . . . . . . . . . . . . . . . . . . . . . 133 136 136 Rsultats de lanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loutil Smart-Fuzz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.1 9.3.2 9.3.3 9.3.4 9.3.5 9.4 9.4.1 9.4.2 9.5 Les modles dtats

Les modles de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Les mutations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Conguration des tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Conguration du processus dexcution . . . . . . . . . . . . . . . . . . 141 . . . . . . . . . . . . . . . . . . . . . . 141 Temps dexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Failles dtectes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 143 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exprimentations et Rsultats

Conclusion

Notre outil de fuzzing compos des applications PyHAT et Smart-Fuzz a t dvelopp en langage Python. Smart-Fuzz se base sur le logiciel Peach qui est un outil de fuzzing libre dutilisation et de modication crit en Python et destin gnrer et muter des donnes sur un protocole quelconque. En eet, il nest pas restreint un modle de donnes particulier. Nous avons donc dni la structure du protocole HTTP que nous voudrions tester. Dans ce chapitre, nous prsentons notre implmentation des applications PyHAT et Smart-Fuzz et quelques rsultats exprimentaux.

9.1

Implmentation de PyHAT

Lapplication PyHAT permet de dvoiler limplmentation du protocole HTTP dans un serveur Web. Elle permet de dtecter les versions, les mthodes, les encodages et les champs HTTP implments dans le serveur Web. Cependant, elle est aussi destine tre utilise sur nimporte quel

134

9. Implmentation et rsultats exprimentaux de Smart-Fuzz et PyHAT

serveur Web. Au lancement de son excution, lutilisateur est invit choisir le type du serveur quil souhaite tester. Dans cette thse nous nous intressons particulirement au cas des cartes puce SCWS. Ces cartes sont spcies par ladresse IP 127.0.0.1 et le numro de port 3516 associ la communication HTTP.

Listing 9.1 Excution de PyHAT sur un SCWS

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

if choice == 1 : target = 127.0.0.1 port = 3516 try : http = HTTP ( target , port , doc_root , scws ) if ( __OS == Linux ) : interactive = raw_input ( \033[0 m \ n * Enter in interactive mode ( y / n ) ? ) else : interactive = raw_input ( \ n * Enter in interactive mode ( y / n ) ? ) if interactive == y : interactive_mode ( http ) http . cl ose_bi p_cha nnel () choice = continue except Exception , descr : if ( __OS == Linux ) : print \033[31 m \ n % s \033[0 m % descr else : print \ n % s % descr choice = continue Une fois que le type du serveur est spci, PyHAT commence son analyse. Cette analyse peut tre ralise en mode interactif o lutilisateur doit saisir en entre lensemble des requtes permettant de tester le protocole (listing 9.1) ou en mode non-interactif dans lequel les requtes sont gnres de manire automatique. Lanalyse dans ce dernier cas est ralise par quatre fonctions qui sexcutent squentiellement et dont la fonction de chacune consiste respectivement : vrier les mthodes implmentes ; vrier les versions supportes ; vrier les encodages supports ; vrier les enttes implments. La vrication dune proprit est base sur lanalyse des rponses du serveur HTTP, compares aux rponses attendues en fonction des requtes spcies en entre. Dans la recherche des versions supportes par exemple, la spcication RFC 2616 du protocole HTTP stipule quune version est supporte sur un serveur si la rponse retourne par celui-ci indique la mme version que

9.1. Implmentation de PyHAT

135

celle utilise dans la requte. Limplmentation de cette proprit est prsente dans le code du listing 9.2.

Listing 9.2 Dtection des versions HTTP supportes

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

# g e t _ s u p p o r t e d _ v e r s i o n s is used to check what # HTTP versions is managed by the server # @return a list of supported HTTP versions def g e t _ s u p p o r t e d _ v e r s i o n s ( self ) : # Request - Line definition for # several HTTP version request_line_0_9 n \ r \ n ) request_line_1_0 n \ r \ n ) request_line_1_1 n \ r \ n ) requests su pp or te d_ ve rs io ns /1.1 : True } res_list = [] = [ request_line_0_9 , request_line_1_0 , = { HTTP /0.9 : True , HTTP /1.0 : True , HTTP request_line_1_1 ] = ( HEAD % s , HTTP /1.1 , \ r \ nHost : % s \ r \ = ( HEAD % s , HTTP /1.0 , \ r \ nHost : % s \ r \ = ( HEAD % s , HTTP /0.9 , \ r \ nHost : % s \ r \

for request in requests : ... if ( self . _mode == scws ) : # Send query self . _bip . send ( request [0] \% self . _URL + request [1] + request [2] \% self .\ _host ) # Receive response response = self . _bip . recv () # Parse response if ( response and self . _c at ch _st at us _l in e ( response ) == []) : su pp or te d_ ve rs io ns [ request [1]] = False elif ( not response or ( response and self .\ _catch \ _status \ _line ( response ) [0] != request [1]) ) : su pp or te d_ ve rs io ns [ request [1]] = False else : res_list . append ( request [1]) self . s e r v e r _ c h a r a c t e r i s t i c s [ Supported versions ] = res_list return sup po rt ed _v er si on s

136

9. Implmentation et rsultats exprimentaux de Smart-Fuzz et PyHAT

Dans cet exemple, PyHAT gnre trois types de requtes HTTP (request_line_0_9, request_line_1_0, request_line_1_1), chacune indiquant une version HTTP dirente (HTTP/0.9, HTTP/1.0, HTTP/1.1). Dans le cas o la cible est un serveur SCWS, la ligne 20, la fonction self._bip.send() se charge dencapsuler la requte HTTP dans un format BIP avant de lenvoyer au serveur SCWS. Pour chacune de ces requtes, la rponse HTTP retourne par le serveur est analyse. Si la version HTTP utilise dans la rponse est la mme que celle dnie dans la requte alors PyHAT ajoute cette version la liste des versions HTTP supportes.

9.2

Rsultats de lanalyse

Les rsultats de PyHAT sont sauvegards dans un chier au format XML nomm assesment.xml. Ce chier utilise principalement trois balises XML que nous avons dnis : <ImplementedMethods> : dnit les mthodes supportes, <SupportedVersions> : dnit les versions supportes, <SupportedEncodings> : dnit les encodages supports, <ParsedHeaders> : dnit les enttes implments. Lutilisation de ces direntes balises XML facilite la lecture automatique du chier assesment.xml par loutil de Smart-Fuzz, qui limite la gnration des donnes de test uniquement des fonctionnalits prsentes dans ce chier.

9.3

Loutil Smart-Fuzz

Peach utilise des chiers de conguration crits en XML. Chaque chier contient une ou plusieurs structures/blocs de donnes qui permettent de dcrire le format des donnes de test pour une lapplication ou le systme que lon voudrait tester. Il fournit un ensemble de balises XML telles que : <DataModel>, <StateModel>, <String>, <Number>, etc. permettant de reprsenter les modles de donnes et les modles dtats pour la description de la grammaire du protocole tester et pour spcier les champs muter et leur type. An dutiliser Peach pour tester le protocole HTTP, nous avons construit un ensemble de chiers de descripteurs des requtes HTTP. Ces chiers sont composs de modles de donnes et des modles dtat.

9.3.1

Les modles de donnes

Les modles de donnes sont un moyen de reprsenter la grammaire de lapplication vise. Pour cela, on utilise la balise <DataModel>. Il est galement possible de dnir des valeurs par dfaut dun modle de donnes, de dnir le type des donnes insres (<String>, <Number>. . . ) et de choisir les champs quon souhaite muter. Chaque balise peut contenir un ou plusieurs attributs (ref, name, value. . . ). Exemple : La premire ligne dune requte HTTP utilisant la mthode GET est dnie comme ceci :

9.3. Loutil Smart-Fuzz

137

RequestLine = Method SP RequestURI SP HTTPVersion CRLF Elle est reprsente par un modle de donnes comme suit :

Listing 9.3 reprsentation de la premire ligne dune requte HTTP

1 2 3 4 5 6 7 8

< DataModel name =" RequestLine " > < String name =" Method " value = " GET "/ > < String value =" "/ > < String name =" RequestUri "/ > < String value =" "/ > < Block name =" HttpVersion " ref =" HttpVersion "/ > < String value ="\\ r \\ n "/ > </ DataModel > La balise <DataModel> est identie par lattribut name qui indique quelle partie de la grammaire est modlise. Cette balise contient des sous balises <String> dcrivant les dirents champs composant une ligne de requte. Chaque champ est gnralement dcrit par son nom et sa valeur. La conguration de Peach ore la possibilit de rfrencer un bloc de donnes partir dun autre bloc. Nous avons exploit cette proprit pour dcouper la grammaire du protocole HTTP en blocs et rduire ainsi la quantit de code gnrer, en vitant des redondances de reprsentation des mmes champs prsents dans des requtes direntes. La reconstitution dune requte HTTP est ralise par rfrencement. Dans lexemple prcdent, le champ HttpVersion est rfrenc dans une structure <bloc> dont lattribut name indique le nom du champ et lattribut ref fait rfrence au modle de donnes identi par le nom HttpVersion. Le modle de donnes HttpVersion est dni sparment dans un autre modle de donnes. Une rfrence ne peut tre utilise que dans une balise reprsentant un bloc de donne (<DataModel>, <Bloc>) Le modle de donnes reprsentant une requte HTTP complte regroupe tous les blocs reprsentant les dirents champs constituant cette requte (la ligne de requtes et les enttes). Dans lexemple ci-dessous (code 9.4) le modle de donnes dune requte HTTP est compos dune suite de blocs faisant rfrences dautres modles dont le premier est RequestLine qui reprsente la premire ligne dune requte.

Listing 9.4 Modle de donnes dune requte HTTP

1 2 3 4

< DataModel name =" HttpRequest " > < Block name =" RequestL " ref =" RequestLine "/ > </ DataModel > Il est galement possible de rutiliser un mme bloc pour reprsenter un autre type de donnes de mme format en changeant simplement les valeurs des attributs des direntes structures de donnes. Cette proprit rduit considrablement le temps ncessaire pour reprsenter toute la grammaire HTTP. En eet, pour reprsenter dautres types de requtes, il sut de reprendre le

138

9. Implmentation et rsultats exprimentaux de Smart-Fuzz et PyHAT

modle construit pour une requte GET et de ladapter pour dautres types de requtes. Dans lexemple du modle de donnes RequestLine (Listing 9.5) ; pour reprsenter une requte POST, il sut de changer la valeur du champ Method par POST.

Listing 9.5 Modle de donnes dune requte POST

1 2 3 4 5 6

< DataModel name =" HttpRequest " > < Block name =" RequestL " ref =" RequestLine " > < String name =" Method " value = " POST "/ > </ Block > </ DataModel > La structure <Data> permet de dsigner une nouvelle valeur un champ dni dans un modles de donnes. Ce sont ces valeurs qui seront prises en compte durant la gnration des donnes de fuzzing. Dans lexemple listing 9.6, nous rutilisons le modle de donne HttpRequest pour reprsenter une requte GET.

Listing 9.6 La structure <Data>

1 2 3

< Data name =" DataRequest " DataModel =" HttpRequest " > < Field name =" RequestL . Method " value =" GET "/ > </ Data >

9.3.2

Les modles dtats

Aprs avoir reprsent la grammaire HTTP sous forme de modles de donnes, il est ncessaire de crer la structure que Peach va prendre en compte pour lui spcier les modles de donnes quil doit gnrer et dnir la suite des actions eectuer. Un modle dtat permet galement dindiquer si les donnes reprsentes dans un modle de donnes vont tre envoyes ou bien reues par loutil de fuzzing (output ou input). Un modle dtats est reprsent par la balise <StateModel> qui peut avoir une ou plusieurs sous-balises <State>, chacune delles ayant une ou plusieurs sous-balises <Action>. Voici un exemple de modle dtat :

Listing 9.7 modle dtat

1 2 3 4 5 6 7

< StateModel name =" State1 " initialState =" Initial " > < State name =" Initial " > < Action type =" output " > < DataModel ref =" HttpRequest "/ > < Data ref =" DataRequest "/ > </ Action > </ State >

9.3. Loutil Smart-Fuzz

139

</ StateModel > Lattribut initialState de la balise <StateModel> prcise le nom de la premire balise <State> excuter. Dans cet exemple, on veut gnrer des donnes dnies par le modle de donnes Test . Il est utile davoir plusieurs <Action>/<State> lorsquon doit grer plusieurs choses en mme temps. Par exemple, pour le protocole HTTP, si on veut aussi recevoir les rponses du serveur pour pouvoir les traiter, alors il sut de rajouter une balise <Action> de type input et de crer un modle de donnes implmentant les rponses.

9.3.3

Les mutations

An de gnrer des donnes semi-alatoires, nous avons utilis les mutateurs (mutators ) qui dnissent un type des donnes muter. Comme prsent prcdemment, les donnes sont reprsentes dans des balises <DataModel> ou <Data>. Ces donnes sont utilises par loutil de fuzzing pour eectuer des mutations et gnrer les donnes de test. La mutation dun champ consiste aecter des valeurs alatoires ce champ mais en se limitant un ensemble de caractres prdnis. Peach propose un ensemble de mutateurs de types dirents tels que StringMutator qui agit sur les donnes de type String. Lensemble des mutateurs supports est contenu dans le chier default.xml prsent la racine de Peach. Cependant, il est possible de dnir ces propres mutateurs. Dans certains cas, la valeur aecte un champ peut tre limite un ensemble de valeurs bien dnies, ceci est le cas par exemple des champs spciant lencodage, la version HTTP, la mthode HTTP, etc. Dans ce cas, il est plus judicieux de limiter les mutations un ensemble prdni de valeurs possibles. La conguration, dans ce cas, est implmente dans une balise <choice>. Lexemple du listing 9.8 montre lutilisation de cette balise pour la dnition des valeurs possibles du champ Method.

Listing 9.8 Mutations sur un ensemble de valeurs bien dni

1 2 3 4 5 6 7 8 9

< choice > < String value =" GET " mutable =" false " / > < String value =" POST " mutable =" false " / > < String value =" HEAD " mutable =" false " / > < String value =" PUT " mutable =" false " / > < String value =" DELETE " mutable =" false " / > < String value =" CONNECT " mutable =" false " / > < String value =" OPTIONS " mutable =" false " / > < choice >

9.3.4

Conguration des tests

La conguration dun test consiste dnir pour ce test : le modle dtat, la cible du fuzzing et dautres options de conguration telles que les types de mutateurs utiliser et les lments

140

9. Implmentation et rsultats exprimentaux de Smart-Fuzz et PyHAT

qui ne ncessitent pas dtre muts. Cette conguration est implmente dans des balises <Test> composes dun ensemble de sous balises dont <StateModel> et <publisher> sont obligatoires. Dans lexemple du listing 9.9, nous faisons le choix de ne pas muter le champ RequestL en le prcisant par la balise <Exclude>. Pour les autres champs que nous voudrions faire muter, deux types de mutateurs sont appliqus, savoir : StringCaseMutator et StringMutatorWithValidData. La balise <Publisher> permet de spcier la cible. Elle est compose dun ensemble de paramtres pour spcier certaines informations utiles. La cible dans cet exemple est un serveur standard www.unilim.fr qui communique sur le rseau internet suivant le protocole TCP et utilise le port 80 pour les communications HTTP.

Listing 9.9 Conguration des tests

1 2 3 4 5 6 7 8 9 10 11 12 13

< Test name =" MutableTest " > < Exclude xpath ="// RequestL "/ > < Mutator class =" string . St ringC aseMut ator " / > < Mutator class =" string . S t r i n g M u t a t o r W i t h V a l i d D a t a " / > < StateModel ref =" State1 "/ > < Publisher class =" tcp . Tcp " > < Param name =" host " value =" www . unilim . fr " / > < Param name =" port " value ="80" / > </ Publisher > </ Test >

Dans le cas des serveurs SCWS (bas sur le protocole BIP), la cible spcie est le programme PCSC qui joue le rle dune interface HTTP<->BIP. Il se charge de transmettre les donnes dans leur format convenu, de recevoir les rponses du serveur et de slectionner les parties des donnes sauvegarder dans les chiers dvnements.

Listing 9.10 Conguration de la cible

1 2 3 4 5 6 7

< Test name =" TestGet " > < Publisher class =" PCSC . PCSC " > < Param name =" Reader " value ="0" / > < Param name =" FolderLog " value =" c :/ peach / http / logs / GET " / > </ Publisher > </ Test >

9.4. Exprimentations et Rsultats

141

9.3.5

Conguration du processus dexcution

La balise <Run> regroupe un ou plusieurs lments <Test> excuter ; elle permet aussi, optionnellement, de dnir le mcanisme de journalisation utiliser pour capturer les rsultats de lexcution. Les chiers dvnements par dfaut de Peach, nenregistrent que les horaires et des cas dun crash du systme. Ces donnes ne nous donnent pas beaucoup dinformations sur la qualit du protocole cibl. Nous avons donc congur notre propre systme de journalisation que nous avons implment dans lapplication PCSC (interface HTTP<->BIP). Lexemple du listing 9.11 illustre la conguration dune balise <Run> :

Listing 9.11 Conguration du processus dexcution

1 2 3 4 5 6

< Run name =" DefaultRun " > < Test ref =" MutableTest " / > < Logger class =" logger . Filesystem " > < Param name =" path " value =" c :\\\\ peach \\ logtest " / > </ Logger > </ Run >

9.4

Exprimentations et Rsultats

Pour vrier la performance et lecacit de notre outil, nous lavons appliqu sur des cartes puce MNFC, bases sur la plateforme Java Card 2.2 et qui embarquent un serveur Web SCWS. Nous avons galement eectu des tests sur un prototype de carte Java Card 3. Les rsultats de nos tests ont dmontr lecacit de notre outil dtecter des failles dans le protocole test et mesurer lapport des direntes optimisations apportes par notre outil.

9.4.1

Temps dexcution

An de calculer la performance en temps dexcution de notre outil, nous avons test le fuzzing sur une carte puce sans utiliser lapplication PyHAT, le fuzzing dans ce cas a ncessit plus de 8 jours (nous avons arrt lexcution du fuzzing avant sa n). Lapplication PyHAT rduit nettement ces mtriques, en limitant le fuzzing des mthodes, des enttes, des encodages ou des versions implments dans la carte puce teste. Le temps dexcution a t rduit en moyenne 6 jours. Bien que PyHAT ait considrablement amlior la performance du fuzzing, le temps dexcution reste important, notamment dans le cas de test sur des cartes puce. Nous avons donc appliqu un fuzzing parallle an de rduire la charge des donnes imposes une carte. Le temps dexcution est relatif au nombre de cartes utilises. Nous avons appliqu notre outil sur trois cartes en parallle. Cependant, une des cartes ne terminait pas son excution, sans doute parce que des mcanismes de scurit taient implments sur cette dernire. Nayant aucune connaissance sur limplmentation des cartes que nous avons utilises, nous navons pas russi dceler la cause exacte de ce cas. Le fuzzing appliqu sur les deux cartes puce restantes a rduit le temps dexcution gnr par lutilisation dune seule carte de presque la moiti. Ce temps a t denviron 56h.

142

9. Implmentation et rsultats exprimentaux de Smart-Fuzz et PyHAT

9.4.2

Failles dtectes

Les cartes puce que nous avons testes nous ont rvl quelques vulnrabilits et des cas de non-conformit la spcication, parmi ces cas :

Autorisation dajout ou de suppression dune ressource : nous avons remarqu que certaines cartes acceptent les commandes PUT et DELETE et les commandes dadministration. La commande PUT permet de crer ou de modier une ressource et la commande DELETE permet de supprimer une ressource. Ces commandes dadministration sont destines tre utilises par lmetteur de la carte (administrateur de lapplication) qui accde de manire scurise au serveur de la carte puce pour eectuer des tches telles que lajout ou la suppression dun utilisateur, modication dun chier de conguration etc. Lensemble de ces tches ne devrait pas tre accessible par lutilisateur qui pourrait eectuer des modications malintentionnes dans le but daugmenter ses privilges (par exemple : augmenter le nombre de points sur une application de dlit) ou attaquer la carte dune tiece personne. Certaines cartes puce testes ont rvl des failles dans cette proprit. En eet, lenvoi de la requte PUT a permis dajouter une ressource HTML dans la carte. An de vrier que la modication a bien t prise en compte, nous avons excut une requte GET qui demande de retourner la page HTML ajoute. Nous avons constat que la rponse de la carte contenait bien dans son corps, la page HTML que nous avions ajoute. La fonction DELETE est aussi autorise, nous avons russi supprimer cette ressource de la carte.

Gnration dune exception Java : une erreur au niveau de la carte peut engendrer un code derreur de type 6F XX qui correspond une exception Java. Pour des raisons de scurit, les cartes puce masquent les dtails de lerreur en retournant dans tous les cas dexception Java, le code 6F 00. Les rsultats obtenus ont rvl que les cartes puce SCWS testes gnrent une exception Java (6F 00) suite linjection dune requte vide.

Rponse HTTP non conforme la spcication : comme prsent prcdemment, notre outil permet de dtecter des non conformits avec la spcication, lorsque les rponses du serveur des requtes bien spcies ne correspondent pas ce qui est prvu dans la spcication. Parmi les rsultats de notre analyse nous avons constat que lors de lenvoi dun entte If-Match invalide, les cartes repondent par le code derreur HTTP 500 qui signie quune erreur interne au serveur sest produite, alors que la carte doit envoyer une erreur HTTP 501 (Non implment) ou une erreur HTTP 400 (requte incorrecte).

Implmentation incomplte : le respect de la conformit une spcication consiste galement vrier que tous les champs obligatoires sont bien implments. Les rsultats obtenus ont montr que les cartes testes nimplmentent pas correctement certaines rgles dnies dans la spcication : Le champ Host qui dnit le domaine de lapplication cibl est obligatoire partir de la version HTTP/1.1. Les tests que nous avons eectus en injectant une requte sans inclure ce champ obligatoire na engendr aucune erreur. Le dernier entte dune requte HTTP et son corps doivent tre spares par deux retours la ligne. Les rsultats que nous avons obtenus montrent que cette rgle est ignore dans les

9.5. Conclusion

143

cartes SCWS que nous avons test. En eet, en envoyant une requte sans respecter cette rgle la carte renvoie la rponse APDU 90 00 signiant que la transaction sest bien droul mais la rponse ne contient aucune rponse HTTP (pas de rponse du serveur SCWS). Les tests que nous avons ralis sur des cartes puces Java Card 3 ont rvl que seules les mthodes GET et POST taient implmentes, alors que selon la spcication de Java Card 3, cette plateforme est base sur le protocole HTTP/1.1, qui dnit les mthodes GET, POST, HEAD comme les mthodes qui DOIVENT tre obligatoirement implmentes. Cependant, ne sagissant que du premier et unique prototype ( notre connaissance), il tait trs probable que limplmentation ne soit pas complte. Loutil que nous avons propos permet de faire un audit des serveurs Web embarques dans les cartes puce. Cependant, il serait intressant dans des travaux futurs de tenter dexploiter ces failles pour eectuer des attaques.

9.5

Conclusion

Dans ce chapitre, nous avons explor lecacit de la mthode de fuzzing pour dcouvrir des vulnrabilits ou des erreurs de mise en uvre du protocole HTTP embarqu dans une carte puce. Nous avons utilis le logiciel Peach pour dvelopper notre outil qui gnre des donnes de test de manire intelligente grce lutilisation de nos propres modles de donnes et des modles dtat. Notre outil est ddi tout type de serveurs Web, y compris les serveurs Web embarqus bass sur SCWS ou la plateforme Java Card 3. Nous utilisons lapproche en bote noire. Pour cela, notre application PyHAT est utilise pour dcouvrir toutes les fonctionnalits mises en uvre sur la cible, an de limiter, par la suite, notre analyse aux seules proprits existantes, et rendre ainsi notre fuzzing plus performant avec un temps dexcution rduit. Cependant, les cartes puce ont une faible bande passante, pour amliorer encore plus la performance de notre analyse, nous avons appliqu un fuzzing parallle sur de multiples cartes puce. Les rsultats exprimentaux ont dmontr lecacit de nos propositions dans la rduction du temps dexcution. Lanalyse automatique des rsultats du fuzzing qui est base sur la comparaison entre les rponses du serveur et de la carte avec un ensemble de motifs bien dnis a permis de dtecter des vulnrabilits et des non conformits la spcication RFC 2616 du protocole HTTP implment dans des cartes puce. Lanalyse sauvegarde lensemble des squences compltes de requtes qui ont conduit une vulnrabilit.

144

9. Implmentation et rsultats exprimentaux de Smart-Fuzz et PyHAT

145

Quatrime partie

Conclusions et perspectives

147

Chapitre 10

Conclusions et perspectives
Sommaire
10.1 Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Principales contributions . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 148 149

10.3.1 Analyse des applications Web . . . . . . . . . . . . . . . . . . . . . . . . 149 10.3.2 Fuzzing HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 10.4 Synthse gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Les cartes puce serveur Web embarqu constituent une grande volution. Grce cette nouvelle technologie, la carte devient accessible une multitude de dveloppeurs via un modle de programmation bas sur des servlets. Ainsi, les dlais de dploiement de nouveaux services sont sensiblement rduits. Dautre part, les services fournis par ces dispositifs sont beaucoup plus faciles dusage travers des interfaces graphiques ergonomiques, accessibles lutilisateur partir du navigateur Web install sur le terminal (tlphone par exemple). Les cartes serveur Web embarqu orent galement la possibilit dadministrer distance les applications installes sur la carte de manire scurise et une connexion des applications distantes via une authentication robuste fournie par la carte. Malgr tous ces avantages, cette nouvelle technologie na toujours pas connu lvolution attendue, les spcications tant sorties depuis 2008. En eet, dune part lutilisation des plateformes Java Card 3 ncessite des dispositifs haut de gamme, de performances beaucoup plus leves que la plupart des cartes utilises dans le monde ; et dautre part, la plateforme SCWS ddie des cartes classiques, ne supporte pas les protocoles TCP/IP. Elle utilise dautres protocoles plus adapts tel que BIP. Il est donc ncessaire que le matriel auquel la carte sera connecte soit dot dun protocole spcique pour assurer la compatibilit entre les deux parties. Cependant, nous pensons quavec la nouvelle technologie des cartes NFC, les cartes serveur Web embarqu vont nir par susciter lintrt des industriels. De plus, la vitesse laquelle la technologie volue laisse croire que les cartes haut de gamme ne vont pas tarder remplacer les cartes classiques.

148

10. Conclusions et perspectives

10.1

Problmatique

Dans le cadre de cette thse, nous nous sommes intresss la scurit de ces nouveaux dispositifs. Louverture de la carte au standards du Web oblige reconsidrer toute la scurit des cartes puce. En eet, de nouveaux protocoles (par exemples : TCP/IP, BIP et HTTP) doivent tre ncessairement implments dans la carte pour assurer sa communication avec le navigateur Web et les dirents nuds du rseau. Des failles dimplmentation de ces protocoles peuvent engendrer des vulnrabilits qui pourraient mettre en pril la scurit de la carte puce. Dautre part, les vulnrabilits peuvent tre causes par des failles dimplmentation des applications Web charges dans ces cartes. Ces applications fournissent des interfaces qui facilitent linteraction avec lutilisateur. Avec les nouvelles technologies de gnration de contenus dynamiques (JavaScript, AJAX, etc.), nous pouvons considrer que lutilisateur contribue la cration de contenus dans des applications Web. En eet, il ne se limite pas consulter des informations mais il publie aussi du contenu (texte, vido, musique). Les applications Web fournissent des points daccs partir desquels lutilisateur est invit entrer des donnes. Une personne malintentionne peut donc exploiter ces points dentre pour injecter des donnes malicieuses dans lapplication. Les attaques Web classiques exploitant les technologies du Web narrtent pas de se multiplier et les cartes puce serveur Web embarqu nen sont pas labri.

10.2

Principales contributions

Dans ce rapport de thse nous avons prsent les direntes spcications existantes des serveurs Web embarqus (plateforme Java Card 3 et la plateforme base sur les spcications SCWS) et les risques que peuvent engendrer les nouvelles entits qui sont incluses dans ces spcications. Notre contribution se divise en deux parties. La premire concerne la scurit des applications Web contre les attaques XSS et la seconde sintresse la scurit de limplmentation du protocole HTTP dans les cartes puce. Notre premire contribution durant cette thse concerne la prvention et la dtection des vulnrabilits XSS. Pour prvenir ces vulnrabilits, nous avons propos une API JCXSSFilter de ltrage des donnes qui est compatible avec la Java Card 3. Cette API est compose dun ensemble de fonctions de ltrage, chacune tant destine tre utilise dans un point dinsertion particulier (entit HTML, code JavaScript, contenu CSS, paramtre dURL). La dtection des vulnrabilits XSS consiste vrier que lAPI de ltrage est utilise dans tout point dinsertion de donnes non ables (issues de donnes externes lapplication) dans un programme. Loutil de dtection que nous avons ralis est bas sur une analyse statique et la technique de dpendance causale. Contrairement la plupart des outils danalyse statique existants, notre outil permet de dtecter des attaques XSS persistantes et volatiles. Il rduit galement le nombre de faux positifs grce une analyse interclasse sensible au contexte et une analyse ne des objets conteneurs (vecteur et tableau). Les rsultats exprimentaux ont montr que notre API de ltrage permet de scuriser les applications Web tout en tant portable sur la carte puce et sans rduire les performances en temps de rponse de la carte. Dautre part, lanalyse statique a permis de dtecter tous les cas de vulnrabilits que nous avons prvus dans nos applications de test.

10.3. Perspectives

149

La solution que nous avons adopte pour la vrication du protocole HTTP consiste en un outil de fuzzing labor, permettant deectuer un test en boite noire du protocole HTTP, quel que soit le type de la plateforme sur laquelle il est install. Notre approche augmente considrablement la performance du fuzzing (en temps et en pertinence de donnes de test), grce lensemble des optimisations que nous avons appliques : une application PyHAT qui permet de dtecter les fonctionnalits HTTP implmentes dans la cible ; un outil de fuzzing Smart-Fuzz bas sur des modles de donnes ; conguration dun fuzzing parallle sur plusieurs cartes. Nous avons galement conu une application danalyse automatique qui recherche la prsence de motifs prdnis dans les vnements enregistrs durant le fuzzing. Nos rsultats exprimentaux ont dmontr lecacit de la technique du fuzzing dans le test des cartes puce, permettant la dtection des failles de scurit et des non-conformits la spcication. Ce projet a t ralis en collaboration avec des industriels qui nous ont fourni des cartes SCWS que nous avons utilises dans nos exprimentations.

10.3

Perspectives

Les outils que nous avons proposs apportent des avantages par rapport aux solutions existantes. Cependant des amliorations peuvent tre envisages. Dans cette section nous proposons quelques travaux futurs pour chacun des outils que nous avons propos.

10.3.1

Analyse des applications Web

Notre outil danalyse statique est le premier outil destin particulirement lanalyse des applications Web Java Card 3. Il ore lavantage dtre prcis compar des approches existantes, se basant sur le calcul de la dpendance causale entre lensemble des objets (tiquetage des objets non ables et propagation de ltiquette tout objet qui rentre en relation avec un objet tiquet) dune application quils soient dune mme classe ou de classes direntes, tout en tant sensible au contexte. Il a galement lavantage de rduire le nombre de faux positifs qui se prsentent gnralement en prsence dobjets tableaux dans un programme. En eet, notre outil est prcis sur llment du tableau concern par la dpendance causale contrairement la plupart des outils qui se limitent traiter un tableau en tant quobjet sans prciser llment concern. Notre analyse permet la fois de dtecter des XSS volatiles et persistantes. Cependant, tel que nous lavons expliqu dans le chapitre prcdent cette analyse a des limites. Nous allons proposer dans la suite quelques approches qui permettraient de complter ces limites. 1. Ordre danalyse des mthodes de la classe HTTPServlet Notre analyse sexcute en boucle, en parcourant le graphe dappel partir de lensemble des nuds correspondant aux fonctions de la classe HTTPServlet (doGet, doPost) que nous appelons points dentre de lanalyse . Elle ritre plusieurs fois en reprenant chaque itration partir dun point dentre dirent. Lordre danalyse de ces mthodes peut inuencer sur la prsence ou non dune vulnrabilit, en particulier en prsence de variables de classe ou des interfaces de partage SIO (voir chapitre exprimentations pour plus dexplications).

150

10. Conclusions et perspectives

An de palier ce problme nous avons propos une solution exhaustive qui consiste considrer toutes les combinaisons dordre dexcution possibles et de relancer lanalyse pour chaque ordre dexcution. Cependant, cette approche risque gnrer un nombre trs important de faux positifs. La seconde approche que nous proposons consiste appliquer une analyse supplmentaire dans certains cas particuliers. Cette analyse applique lalgorithme suivant : lanalyseur XSSDetector parcourt lensemble des instructions dune mthode, si linstruction visite est une sauvegarde persistante (putStatic) dune donne ou un appel une mthode qui envoie des informations vers lextrieur de lapplication (println()), et que la donne concerne (paramtre de la mthode, ou donne sauvegarde en mmoire persistante) nest pas signale comme non able (ne porte pas dtiquette) alors ; lanalyse supplmentaire intervient pour cette donne. Elle consistera vrier si la donne est le rsultat de la manipulation dune variable de classe. Si cest le cas alors ; lanalyse supplmentaire parcourt lensemble de lapplication pour vrier si un moment, une donne non able est aecte cette variable de classe ; si cest le cas, alors une vulnrabilit XSS est signale. Plus prcisment lanalyse supplmentaire propose applique une technique de dpendance causale qui linverse de celle applique par notre analyseur XSSDetector, commence par un tat puits et remonte jusqu la source pour vrier si cette dernire est able ou non. Le d de cette solution est de traiter tous les cas possibles dans le calcul du chemin inverse permettant de remonter jusqu la source. 2. Validation de lAPI de ltrage Notre API de ltrage XSSFilter, respecte parfaitement les recommandations dOWASP. Cependant, les attaques XSS sont trs malicieuses : un mme script peut scrire de direntes faons avec dirents encodages. Il serait donc ncessaire de tester notre API pour conrmer son ecacit. Notre proposition dans ce cadre, consiste exploiter notre outil de fuzzing (dvelopp pour analyser limplmentation du protocole HTTP dans des cartes puce) pour tester lecacit de lAPI JCXSSFilter. Lapplication PyHAT, permet de dtecter lensemble des pages Web prsentes dans la carte, ces pages pourraient tre exploites pour recueillir lensemble des points dinsertion de donnes dans une application. Loutil de fuzzing va ensuite injecter un ensemble de combinaison de donnes de test, gnres partir de mutations sur dirents ensembles dencodages pour vrier si un encodage peut outrepasser le ltrage de notre API. Une autre solution consiste utiliser des outils existants comme Metasploit [Lud11] qui applique une base de donnes dattaques pour tester une application Web. 3. Vrier si la fonction de ltrage utilise est celle qui convient Loutil danalyse statique que nous avons propos permet de vrier que lAPI JCXSSFilter est utilise dans tout point dinsertion dans un programme o un danger XSS se prsente. Cependant, cette API est compose de cinq fonctions, chacune destine ltrer un point dinsertion particulier (code HTML, attribut HTML, JavaScript, CSS, URL). Une mme fonction ne peut pas tre utilise dans des points dinsertion de dirents types. En eet, le code nest pas interprt de la mme faon selon le type de donnes. Les navigateurs Web sont dots de dirents interprteurs et des caractres non malicieux pour les uns ne le sont pas forcment pour les autres. Malheureusement, notre outil danalyse permet uniquement

10.3. Perspectives

151

de vrier si une donne est ltre par JCXSSFilter sans contrler laquelle des mthodes a t utilise. Pour amliorer notre analyse nous proposons de construire un parseur HTML qui parcourt le code HTML de chaque page visite durant lanalyse. Toutes les balises HTML ou JavaScript rencontres doivent tre sauvegardes. Quand XSSDetector dtecte un appel une mthode de ltrage, le parseur HTML parcourt toutes les balises pr-enregistres avant cet appel et supprime tous les couples de balises ouvrantes et leurs correspondantes balises fermantes (par exemple <img> </img>). La dernire balise ouvrante qui na aucune balise fermante correspondante dnit le contexte dans lequel la mthode de ltrage a t appele. Par exemple, si la balise est <script> alors la mthode de ltrage est appele dans un contexte de JavaScript et la fonction de ltrage adapte dans ce cas est encodeforJavaScript(). La lecture du code HTML est simple, il sut de rcuprer les paramtres des mthodes qui achent le code HTML dune page Web tel que HTTPSetvletResponse.getWriter().println(). Il faut ensuite parcourir le text rcupr et slectionner toutes les balises HTML utilises dans ce texte. La dicult de cette analyse rside dans la multitude des balises existantes et les direntes faons pour les reprsenter. 4. Factorisation et adaptation aux cartes SCWS LAPI de ltrage que nous avons utilise est destine des applications Java Card 3. Les API Java utilises dans son implmentation ne conviennent pas des cartes Java Card 2.2 serveur SCWS. Il faudrait donc radapter JCXSSFilter pour quelle soit compatible avec cette plateforme. Dautre part, loutil danalyse statique que nous avons conu permet de dtecter des failles dans des applications Java Card 3 qui sont bases sur lAPI servlet 2.4. Les plateformes Java Card SCWS utilisent une autre API dnie par la norme ETSI. Pour adapter notre analyse statique la plateforme Java Card SCWS, il sut de dnir les mthodes des tats source, puits et drivations correspondant cette plateforme. An de rendre notre outil plus simple dusage. Nous proposons de faire une factorisation, en proposant une interface o lutilisateur dnit le type de lapplication quil voudrait analyser, et selon son type (Java Card 3 ou plateforme SCWS), loutil charge les fonctions correspondant aux tats source, drivation et puits, de la plateforme cible. Ces fonctions vont tre prdnies dans des chiers spares pour chaque plateforme.

10.3.2

Fuzzing HTTP

Loutil de fuzzing que nous avons conu prsente beaucoup davantages par rapport aux outils existants notamment grce lutilisation de lapplication PyHAT qui rend le fuzzing beaucoup plus intelligent en se limitant des fonctionnalits supportes par la cible et les modles de donnes qui permet dinjecter des donnes ayant un format de requte HTTP valide. La complexit du fuzzing rside dans lanalyse des vnements sauvegards. Gnralement cette analyse se fait manuellement, ce qui est trs fastidieux vu la quantit dvnements gnrs. Notre outil propose une analyse des vnements en les comparant un ensemble de motifs dnis par un oracle. Cependant, notre base de motifs est limite des cas de non-conformit ou au crash de la carte. An denrichir notre oracle, il serait intressant dans des travaux futurs dtablir un tat de lart des vulnrabilits les plus rpandues sur des serveurs HTTP et de dnir pour chacune des motifs qui la caractrisent.

152

10. Conclusions et perspectives

Dautre part, les vulnrabilits dtectes peuvent tre exploites pour tenter des attaques sur la carte puce via le protocole HTTP. Parmi ces attaques nous avons les attaques Web. Loutil PyHAT que nous avons dvelopp permet de dtecter les direntes pages Web prsentes dans la carte puce. Il serait donc intressant dexploiter cette information pour tenter des attaques telle quune XSS via les points dinsertion fournis par ces pages Web.

10.4

Synthse gnrale

Cette thse tourne autour de la technologie des cartes serveur Web embarqu. Elle permet dapporter des rponses des questionnements sur lintrt dintgrer un serveur Web dans une carte puce et met laccent sur les risques que peuvent apporter les nouveaux lments intgrs dans ces dispositifs (serveur HTTP, applications Web, protocoles rseau). Nous nous sommes intresss la scurit au niveau du protocole HTTP et au niveau des applications Web. Nous avons donc propos un outil de fuzzing pour tester la conformit et la robustesse du protocole HTTP, un outil danalyse statique pour dtecter des vulnrabilits par injection de code (XSS) dans des applications Web et une API de ltrage que les dveloppeurs dapplications Web Java Card 3 peuvent utiliser pour scuriser leur application. Le choix des approches appliques a t fait aprs un tat de lart des approches existantes. Cet tat de lart nous a permis de constater que la technique de fuzzing est lapproche la plus adapte pour tester des environnements en boite noire et que la meilleure protection contre les XSS doit tre apportes durant la phase de dveloppement de lapplication en prvoyant un ltrage des donnes non ables. Les exprimentations que nous avons ralises sur nos outils ont montr leur ecacit. Cependant, des amliorations peuvent tre apportes. Nous avons propos un ensemble de travaux pour lamlioration de lanalyse des vnements dans notre outil de fuzzing et un ensemble de propositions pour rduire les fausses alertes dans notre outil danalyse statique.

153

Cinquime partie

Annexes

155

Annexe A

A.1
suit : <HTTP>

Reprsentation du chier assesment.xml

Le chier assesment.xml est le rsultat de lanalyse ralise par PyHAT il est organis comme

<Characteristics > <ImplementedMethods> <Method isCaseSensitive="False"name="HEAD"/> <Method isCaseSensitive="False"name="TRACE"/> <Method isCaseSensitive="False"name="GET"/> <Method isCaseSensitive="False"name="CONNECT"/> <Method isCaseSensitive="False" name="PUT"/> <Method isCaseSensitive="False" name="POST"/> <Method isCaseSensitive="False" name="OPTIONS"/> <Method isCaseSensitive="False" name="DELETE"/> </ImplementedMethods> <SupportedVersions> <Version num="HTTP/1.0"/> <Version num="HTTP/1.1"/> </SupportedVersions> <ParsedHeaders> <Header name="Cache-Control"/> <Header name="Connection"/> <Header name="Date"/> . . . <Header name="Pragma"/> <Header name="Last Modified"/>

156

A.

</ParsedHeaders> <SupportedEncodings> <Encoding name=" identity "/> </SupportedEncodings> </Characteristics> </HTTP>

A.2

Fichiers de journalisation de Smart-Fuzz

Les chiers de journalisation de loutil Smart-Fuzz sauvegardent les requtes HTTP envoyes au serveur et les rponses reues en consquence. La gure suivante reprsente un vnement sauvegard dans ces chiers.

157

Annexe B

B.1

Exemple de servlet

La servlet ci-dessous permet dacher du texte Bonjour lutilisateur lorsque celui-ci envoie une requte GET une adresse associe par le conteneur Web cette servlet :

Listing B.1 Exemple de Servlet

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

// Importer les packages necessaire a la creation de la servlet import javax . servlet .*; import javax . servlet . http .*; import java . io .*; // Etendue de la classe HttpServlet public class PremiereServlet extends HttpServlet { // D f i n i r la m t h o d e doGet () pour le traitement r e q u t e Get public void doGet ( Ht tp Se rvl et Re qu es t req , H t tp S e rv l e tR e s po n s e res ) throws ServletException , IOException { // D f i n i r le type text / html de la response res res . setContentType ( " text / html " ) ; // C r a t i o n d un objet PrintWriter pour format au navigateur PrintWriter out = res . getWriter () ; // Envoyer les donnees au navigateur out . println ( " < HTML > " ) ; out . println ( " < HEAD > < TITLE > Titre </ TITLE > </ HEAD > " ) ; out . println ( " < BODY > < b1 > Bonjour </ b1 > </ BODY > " ) ; l envoi de texte envoyer d une

158

B.

21 22 23 24 } }

out . println ( " </ HTML > " ) ; out . close () ;

Une servlet tend la classe HTTPServlet qui fournit un ensemble de mthodes permettant de traiter les dirents types de requtes, par exemple doGet() correspond la requte GET. Ces mthodes contiennent deux objets en paramtres, lobjet instance HttpServletRequest et lobjet instance de HttpServletResponse. Le premier contient des mthodes permettant de retourner des informations sur la requte. La mthode doGet() traite la requte et rpond au client via lobjet HttpServletResponse. Lobjet PrintWriter permet de retourner via des mthodes telle que println() des informations vers le navigateur Web.

B.2

Descripteurs de dploiement dune application Web

Les descripteurs de dploiement sont des chiers qui dcrivent la structure, la conguration et des informations de dploiement dune application. Il existe trois types de descripteurs pour une application Web : le descripteur de dploiement dune application Web, web.xml, un descripteur spcique une application Java Card javacard.xml et le runtime descriptor MANIFEST.MF.

Le descripteur web.xml
web.xml est un chier lmentaire pour le dploiement dune application Web. Il est structur en dirents lments : les paramtres dinitialisation des servlets, mapping de servlet, mapping des ltres, les listeners, conguration des sessions, scurit (les rles et la mthode dauthentication utilise). Quest ce que le mapping ? la rception dune requte par un client, le conteneur Web se charge de dterminer lapplication concerne par cette requte. Lapplication Web slectionne doit avoir le plus long chemin de contexte qui correspond au dbut de lURL dnie dans la requte. Le container Web doit ensuite localiser les servets qui se chargeront du traitement de la requte. La localisation de la servlet se fait par lintermdiaire du mapping qui associe un nom de servlet (servlet-name) aux dirents chemins daccs (url-pattern). lexemple ci-dessous prsente un simple exemple de structure dun chier web.xml

Listing B.2 Exemple de structure dun chier web.xml

1 2 3

<? xml version ="1.0" encoding =" UTF -8"? > <web - app version ="2.4"

B.2. Descripteurs de dploiement dune application Web

159

4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

xmlns =" http :// java . sun . com / xml / ns / j2ee " xmlns : xsi =" http :// www . w3 . org /2001/ XMLSchema - instance " xsi : schemaLocation =" http :// java . sun . com / xml / ns / j2ee http :// java . sun . com / xml / ns / javacard / jcweb - app_3_0 . xsd " > < display - name > MyApplication </ display - name > < servlet > < servlet - name > MyServlet </ servlet - name > < servlet - class > So urceP ackage Name . MyServlet </ servlet - class > </ servlet > < servlet - mapping > < servlet - name > MyServlet </ servlet - name > <url - pattern >/ MyServlet </ url - pattern > </ servlet - mapping > </ web - app > Il faut noter que dans Java Card, contrairement JEE, le chevauchement des valeurs url-pattern dans le servlet-mapping nest pas support. Cela permet dviter quune application puisse prendre le contrle des chemins daccs dune autre application.

Le descripteur MANIFEST.MF
Le chier MANIFEST.MF est appel runtime descriptor. Il permet de transmettre des informations de conguration et dexcution de lapplication Web entre le dveloppeur, lintgrateur et le dployeur. Il est compos dun ensemble dattributs lis la scurit et aux dirents rles daccs. Les informations contenues dans le runtime descriptor incluent : le type de lapplication (dans notre cas on sintresse au type Web) ; mapping des rles relatifs aux utilisateurs autoriss et aux clients on-card (1) : chaque rle correspond une URI dsignant les donnes dauthentication de lutilisateur ; liste des interfaces partages (SIO) auxquelles lapplication a accs. Il contient aussi des informations spciques une application Web : chemin de contexte : contexte par dfaut utilis par le conteneur Web dans lURI assigne lapplication Web ; numro de port scuris : correspond au numro de port qui devra tre utilis durant une communication HTTP scurise ; informations lies lauthentication dun client dans une session scurise. Deux types dutilisateurs sont dnis pour la Java Card 3, appels Holder et User. Holder correspond au propritaire de la carte, il a un accs direct aux ressources. User dsigne un lutilisateur distance. Il a des droits daccs distance la carte. Cet utilisateur peut tre par exemple un administrateur dune application oerte par loperateur.

Listing B.3 Exemple de structure dun chier MANIFEST.FM

1 2

Manifest - Version : 1.0 Runtime - Descriptor - Version : 3.0

160

B.

3 4 5 6

Application - Type : web Web - Context - Path : / MyApplication User - Role - List : client client - Mapped - To - Auth - URI : sio :/// standard / auth / holder / global / admin / pin

Le descripteur Javacard.xml
Le javacard.xml est un chier optionnel, structur en un ensemble dlments comportant des informations de dploiement et de conguration spciques la plateforme Java Card, savoir : informations sur lauthentication ; liste des classes charges dynamiquement ; liste des classes accessibles par lapplication ; liste des rles des utilisateurs et des clients on-card.

Listing B.4 Exemple de structure dun chier javacard.xml

1 2 3 4 5 6 7 8 9 10 11

<? xml version ="1.0" encoding =" ISO -8859 -1"? > < javacard - app version ="3.0" xmlns =" http :// java . sun . com / xml / ns / javacard " xmlns : xsi =" http :// www . w3 . org /2001/ XMLSchema - instance " http :// java . sun . com / xml / ns / jcns / javacard - app_3_0 . xsd " > <! - - --> < shareable - interface - classes > < class name =" com . sun . jchowto . sioservice . SmartShareable "/ > </ shareable - interface - classes > </ javacard - app >

161

Annexe C

C.1

Notions Web

Dans cette annexe nous prsentons quelques notions Web notamment les langages de balisages permettant de dvelopper des applications dynamiques interactives, dont laspect est facilement modiables. Souvent, les attaquants exploitent ces outils pour raliser des attaques sur les application Web. Gestion de session (les cookies). Une fois lutilisateur identi et authenti, un mcanisme de suivi de session est utilis pour viter les demandes didentication de lutilisateur chaque requte. Il existe plusieurs techniques standards de passer lidentiant en paramtre dans la requte : ajout des variables didentication lURL. passer en paramtre un champ de formulaire cach. utilisation de cookies. Le moyen le plus utilis est les cookies. Les cookies sont des headers stocks au niveau du client, permettant de stocker des paires cl/valeur. Les cookies concernant le domaine du site sur lequel un utilisateur se rend sont automatiquement envoys dans les enttes HTTP lors de chaque requte du client. La classe javax.servlet.http.Cookie permet de crer un objet Cookie. Lentte HTTP rserv lutilisation des cookies sappelle Set-Cookie. Lenvoi du cookie vers le navigateur We bse fait grce la mthode addCookie() de lobjet HttpServletResponse. Pour rcuprer les cookies provenant de la requte du client, il sut dutiliser la mthode getCookies() de lobjet HttpServletRequest. HyperText Markup Language (HTML). HTML (en franais "langage de balisage dhypertexte") est un langage de balisage utilis pour crer des pages Web. Il fournit un ensemble de balises qui permettent de mettre en forme un text qui peut inclure des lments interactifs tel que des images, des vido, des liens. Il est interprt au niveau du navigateur qui ache laspect de la page Web. En gnral, dautres langages lui sont associs tels que CSS et JavaScript. eXtensible HyperText Markup Language (XHTML). XHTML est une volution de HTML. Il se base sur la syntaxe de XML alors que on prdcesseur tait bas sur le SGML.

162

C.

Les balises utilises en XHTML sont similaires celles du HTML 4 mais leur syntaxe a t amliore an de rendre plus strictes les rgles dcriture du code (la fermeture des balises est obligatoire, le code est saisi en casse minuscule, les attributs des balises ne peuvent plus tre laisss vides et leurs valeurs doivent tre encadres par des guillemets, ...). eXtensible Markup Language (XML). XML est un langage de balisage qui drive du langage SGML. Il permet de faciliter lchange de contenus entre des systmes dinformation htrognes. Sa syntaxe est extensible permettant de dnir de nouvelles balises. Ces balises sont encadres par des chevrons (< >). JavaScript. JavaScript est un langage de programmation de scripts, qui est incorpor aux balises HTML, permettant damliorer la prsentation et linteractivit des pages Web. Ces scripts sont grs et excuts par le navigateur lui-mme sans devoir faire appel aux ressources du serveur. Ils sont donc traits en direct et surtout sans retard par le navigateur. Il existe direntes librairies JavaScript qui regroupent un ensemble de fonctionnalits courantes souvent utilises de manire rptitive. Elles orent aux dveloppeurs une programmation plus simple et plus rapide dapplications trs riches et surtout compatibles avec dirents types de navigateurs. Ces librairies contiennent notamment les fonctionnalits suivantes : le parcours des lments DOM (donc gain de place sur la carte), utiliser des thmes pour dcorer les pages web, utiliser des widgets prts lemploi (cf. DatePicker de JQuery UI). Ces librairies sont stockes soit sur le serveur (la carte), soit sur un serveur distant http ://ajax.googleapis.com/ajax/libs, ce qui apporte un gain despace sur la carte. La Google Libraires API est un rseau de distribution de contenus. Lutilisation de la mthode google.load() augmente la vitesse des applications, tout en donnant accs une liste volutives de bibliothques dont celle du JavaScript "open-source". La librairie JavaScript la plus utilise de nos jours est la JQuery. La communaut de JQuery a aussi dvelopp un ensemble de composants pour les interfaces graphiques : JQuery UI. Document Object Model (DOM). Le DOM dnit un moyen standard daccs et de modication dynamique du contenu, de la structure et du style dun document XML ou HTML, en utilisant un modle orient objet. Il permet aux programmes et scripts daccder ou de modier individuellement chaque lment dune page et de crer une partie dune page. Il fournit un ensemble dobjets, contenant des proprits, des mthodes et des vnements que le dveloppeur peut utiliser dans la manipulation dun document XML ou HTML. Cascading Style Sheets (CSS). CSS appel aussi feuille de style est un langage utilis pour dnir laspect dune application Web, ( la couleur du fond de la page ou le type de police). Il utilise un petit chier (exemple "style.css") dans lequel le dveloppeur peut dnir laspect futur de lapplication Web. Il permet de rduire le code HTML en taille et en complexit et de faciliter la modication de la prsentation des pages Web en modiant simplement le chier CSS. Asynchronous JavaScript and XML (AJAX). Larchitecture AJAX dsigne lorganisation dun ensemble dlements (JavaScript, les CSS, XML, le DOM et le XMLHttpRequest) permettant de construire des applications Web dynamiques et interactives. Elle permet de modier une partie dune page Web ache par un navigateur Web sans avoir recharger la page entire.

C.1. Notions Web

163

Le terme "Asynchronous" (asynchrone en franais), signie que lexcution de JavaScript ne sarrte pas en attente dune rponse du serveur, contrairement au mode synchrone dans lequel le navigateur serait bloqu en attendant la rponse.

164

C.

165

Bibliographie
[20007] [Ait04] [ALK+ 08] The web application hackers handbook : discovering and exploiting security aws. John Wiley & Sons, Inc., New York, NY, USA, 2007. D. Aitel. An introduction to spike, the fuzzer creation kit. immunity inc. white paper, 2004. Vasilios Almaliotis, Alexandros Loizidis, Panagiotis Katsaros, Panagiotis Louridas, and Diomidis Spinellis. Static program analysis for java card applets. In Proceedings of the 8th IFIP WG 8.8/11.2 international conference on Smart Card Research and Advanced Applications, CARDIS 08, pages 1731, Berlin, Heidelberg, 2008. SpringerVerlag. [All08a] [All08b] [All08c] [All08d] [Ant] [Apa06] [BDH11a] Open Mobile Alliance. Oma, enabler release denition for smartcard-web-server. Technical report, OMA, April 2008. Open Mobile Alliance. Oma, smartcard-web-server approved. Technical report, OMA, April 2008. Open Mobile Alliance. Oma, smartcard web server enabler architecture server approved. Technical report, OMA, April 2008. Open Mobile Alliance. Smartcard-web-server. Technical report, OMA, 2008. http ://www.openmobilealliance.org/technical/release_program/scws_v1_0.aspx. Antisamy project. https ://www.owasp.org/index.php/Category :OWASP _AntiSamy_Project. Apache. http ://jakarta.apache.org/bcel/manual.html. Apache Software Foundation, 2006. Guillaume Barbu, Guillaume Duc, and Philippe Hoogvorst. Java card operand stack : Fault attacks, combined attacks and countermeasures. In CARDIS, pages 297313, 2011. [BDH11b] Guillaume Barbu, Guillaume Duc, and Philippe Hoogvorst. Java card operand stack : fault attacks, combined attacks and countermeasures. In Proceedings of the 10th IFIP WG 8.8/11.2 international conference on Smart Card Research and Advanced Applications, CARDIS11, pages 297313, Berlin, Heidelberg, 2011. Springer-Verlag. [BGH+ 12] Bastian Braun, Patrick Gemein, Benedikt Hing, Michael Marc Maisch, and Alexander Seidl. Angrie auf openid und ihre strafrechtliche bewertung - cross site request forgery, phishing und clickjacking. Datenschutz und Datensicherheit, 36(7) :502509, 2012.

166

BIBLIOGRAPHIE

[BGLP08]

Fabrice Bouquet, Christophe Grandpierre, Bruno Legeard, and Fabien Peureux. A test generation solution to automate software testing. In Proceedings of the 3rd international workshop on Automation of software test, AST 08, pages 4548, New York, NY, USA, 2008. ACM.

[BICL11]

Guillaume Bouard, Julien Iguchi-Cartigny, and Jean-Louis Lanet. Combined software and hardware attacks on the java card control ow. In CARDIS11, pages 283296, 2011.

[BL12]

Guillaume Bouard and Jean-Louis Lanet. The next smart card nightmare logical attacks, combined attacks, mutant applications and other funny things. In David Naccache, editor, Cryptography and Security : From Theory to Applications, volume 6805 of Lecture Notes in Computer Science, chapter The Next Smart Card Nightmare Logical Attacks, Combined Attacks, Mutant Applications and other Funny Things, pages 405424. Springer, Berlin / Heidelberg, 2012.

[BLIC11] [BMV05] [Boc03] [BRlLV03]

M. Barreaud, J-L. Lanet, and J. Iguchi-Cartigny. Analyse de vulnrabilits sur cartes puce serveur web embarqu. SAR-SSI, 2011. D. Basin, S. Mdersheim, and L. Vigano. Algebraic intruder deductions. IEEE transaction on communication, pages 549-564, 2005. G. Bochmann. A general transition model for protocols and communication services. IEEE transaction on communication, pages 643650, 2003. L. Burdy, A. Requet, J. l. Lanet, and La Vigie. Java applet correctness : a developeroriented approach. In In Proc. Formal Methods Europe, pages 422439. Springer, 2003.

[CDL06]

Vronique Cortier, Stphanie Delaune, and Pascal Lafourcade. A Survey of Algebraic Properties Used in Cryptographic Protocols. Journal of Computer Security, 14(1) :1 43, 2006.

[Che]

Checkstyle 5.6. http ://checkstyle.sourceforge.net/. Van. Using temporal logics of knowledge in the formal verication of security protocols. pages 148151, 2004.

[CMcMW04] Dixon Clare, Gago Mari-carmen, Fernndez, Fisher Michael, and Der Hoek Wiebe,

[CnH02]

Nstor Catao and Marieke Huisman. Formal specication and static checking of gemplus electronic purse using esc/java. In Proceedings of the International Symposium of Formal Methods Europe on Formal Methods - Getting IT Right, FME 02, pages 272289, London, UK, UK, 2002. Springer-Verlag.

[CW09]

Erika Chin and David Wagner. Ecient character-level taint tracking for java. In Proceedings of the 2009 ACM workshop on Secure web services, SWS 09, pages 312, New York, NY, USA, 2009. ACM.

[DJ04]

R. Cok David and R. Kiniry Joseph. Esc/java2 : Uniting esc/java and jml - progress and issues in building and using esc/java2. In In Construction and Analysis of Safe, Secure and Interoperable Smart Devices : International Workshop, CASSIS 2004. SpringerVerlag, 2004.

[ECGN06]

Kirda Engin, Kruegel Christopher, Vigna Giovanni, and Jovanovic Nenad. Noxes : A client-side solution for mitigating cross-site scripting attacks. 2006.

BIBLIOGRAPHIE

167

[ED]

Vela Nava Eduardo and Lindsay David. Abusing internet explorer 8s xss lters. http ://p42.us/ie8xss/Abusing_IE8s_XSS_Filters.pdf.

[ESA] [ETS10a] [ETS10b]

Owasp enterprise security api. http ://code.google.com/p/owasp-esapi-java/. ETSI. ETSI TS 102 223 - Smart Cards : Card Application Toolkit (CAT), 2010. ETSI. ETSI TS 102 588 - Smart Cards : Application invocation Application

Programming, 2010. http ://www.etsi.org/deliver/etsi_ts/102800_102899/102835/ 07.00.00_60/ts_102835v070000p.pdf. [FGM+ 99] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. BernersLee. Rfc 2616 : Hypertext transfer protocolhttp/1.1, june 1999. Status : Standards Track, 1999. http ://www.ietf.org/rfc/rfc2616.txt. [Fin] [FNE+ 07] Findbugs project. Nentwich Florian, Jovanovic Nenad, Kirda Engin, Kruegel Christopher, and Vigna Giovanni. Cross-site scripting prevention with dynamic data tainting and static analysis. In In Proceeding of the Network and Distributed System Security Symposium (NDSS07, 2007. [Fou06] Mozilla Foundation. Javascript security : Same origin. 2006.

http ://www.mozilla.org/projects/security/components/same-origin.html. [Gar09] [GDB06] [GDS07] Pierre Gardenat. Xss : de la brise louragan. 2009. Bearer independent protocol (bip). Technical report, G&D, 2006. Smart card web server - merging the sim and the world wide web. Technical report, G&D, 2007. [Gem] Gemalto table et LG Electronics dot de la lancent technologie le premier Smart Card tlphone Web porServer.

commercial

http ://www.gemalto.com/php/pr_view.php ?id=438. [Gir07] Christophe Giraud. Attaques dcosystmes embarqus et contre-mesures associes. PhD thesis, Universit de Versailles Saint-Quentin-en-Yvelines, 2007. Dieter Gollmann. Securing web applications. Inf. Secur. Tech. Rep., 13(1) :19, January 2008. [Gri] Dan Grin. Smart card middleware fuzz testing tool. https://scfuzz.codeplex. com/. [Gui08] Hiet Guillaume. Dtection dintrusions paramtre par la politique de scurit grce au contrle collaboratif des ux dinformations au sein du systme dexploitation et des applications : mise en oeuvre sous Linux pour les programmes Java. PhD thesis, SUPELEC, 2008. [GVLB08] Hiet Guillaume, Triem Tong Valrie, Viet, M Ludovic, and Morin Benjamin. Policybased intrusion detection in web applications by monitoring java information ows. In CRiSIS, pages 5360, 2008. [Hol91] [HP04] G. Holzmann. Design and validation of computer protocols. Prentice Hall, 1991. David Hovemeyer and William Pugh. 39(12) :92106, December 2004. Finding bugs is easy. SIGPLAN Not.,

[Gol08]

168

BIBLIOGRAPHIE

[HTL+ 05]

Yao-Wen Huang, Chung-Hung Tsai, Tsung-Po Lin, Shih-Kun Huang, D. T. Lee, and Sy-Yen Kuo. A testing framework for web application security assessment. Comput. Netw., 48(5) :739761, August 2005.

[htm] [HTT] [HYH+ 04]

Php labware, htmlawed. Internet Engineering Task Force, HTTP over TLS. Yao-Wen Huang, Fang Yu, Christian Hang, Chung-Hung Tsai, Der-Tsai Lee, and SyYen Kuo. Securing web application code by static analysis and runtime protection. In Proceedings of the 13th international conference on World Wide Web, WWW 04, pages 4052, New York, NY, USA, 2004. ACM.

[IBM] [ICL10]

Findbugs, part 2 : Writing custom detectors. J. Iguchi-Cartigny and J.L. Lanet. Developing a Trojan applet in a Smart Card. Journal in Computer Virology, 6 :343351, November 2010.

[I.M]

M.Gunes I.Maceno.

The Fusil Project.

http://www.labri.fr/perso/fleury/

courses/SS08/download/memoirs/adjej-gunes-maceno-memoire.pdf. [JB01] van den Berg Joachim and Jacobs Bart. The loop compiler for java and jml. pages 299312. Springer, 2001. Martin Johns, Bastian Braun, Michael Schrank, and Joachim Posegga. Reliable protection against session xation attacks. In SAC, pages 15311537, 2011. [JC309a] Java CardTM 3.0.2 Application Programming Interface Specication, Classic Edition. SunMicrosystems, 2009. [JC309b] Java CardTM 3.0.2 Runtime Environment (JCRE) Specication, Connected Edition. SunMicrosystems, 2009. [JC309c] Java CardTM 3.0.2 Servlet Specication, Connected Edition. SunMicrosystems, 2009. [JC309d] [JC309e] Java cardtm 3.0.2 specication, classic edition. SunMicrosystems, 2009. Java CardTM 3.0.2 Virtual Machine (JCVM) Specication, Classic Edition. SunMicrosystems, 2009. [JC309f] Java CardTM 3.0.2 Virtual Machine (JCVM) Specication, Connected Edition. SunMicrosystems, 2009. [JL00] Lanet Jean-Louis. Are smart cards the ideal domain for applying formal methods ? In ZB, pages 363373, 2000. [JL04] Whaley John and Monica S. Lam. Cloning-based context-sensitive pointer alias analysis using binary decision diagrams. In In Proceedings of the ACM SIGPLAN 2004 Conference on Programming Language Design and Implementation, pages 131 144, 2004. [joi09] Joint interpretation library, application of attack potential to smartcards. February 2009. [KBBL11] Nassima Kamel, Mathieu Barreaud, Guillaume Bouard, and Jean-Louis Lanet. Fuzzing on the http protocol implementation in mobile embedded web server. C&ESAR 2011, 2011.

[JBSP11]

BIBLIOGRAPHIE

169

[KGJE09]

Adam Kieun, Philip J. Guo, Karthick Jayaraman, and Michael D. Ernst. Automatic creation of SQL injection and cross-site scripting attacks. In ICSE09, Proceedings of the 31st International Conference on Software Engineering, Vancouver, BC, Canada, May 2022, 2009.

[KICL10]

Nassima. Kamel, Julien. Iguchi-Cartigny, and Jean-Louis Lanet. Java card 3 web application developpement methodologie. 2010.

[KICLB10]

Nassima. Kamel, Julien. Iguchi-Cartigny, Jean-Louis Lanet, and Mathieu Barreaud. Perspectives dutilisation du serveur web embarqu dans la carte puce java card 3. 2010.

[Kle]

Amit

Klein.

Cross

site

scripting

explained.

http

://-

courses.csail.mit.edu/6.857/2009/handouts/ css-explained.pdf. [KLIC11] Nassima Kamel, Jean-Louis Lanet, and Julien Iguchi-Cartigny. Static analysis of java card web applications and prevention against javascript injection. ICSNA, 2011. [KMM10] [Kon] [Kse] [Lam06] L. Kyrillidis, K. Mayes, and K. Markantonakis. Web server on a sim card. July 2010. Knizhnik Konstantin. jlint. http ://jlint.sourceforge.net/. kses - php html/xhtml lter. http ://sourceforge.net/projects/kses/. Kevin Lam. Microsoft anti-cross site scripting library v1.5. 2006.

http ://msdn.microsoft.com/en-us/library/aa973813.aspx. [Lan11] J. Lancia. Un framework de fuzzing pour cartes puce : application aux protocoles emv. SSTiC, 2011. V. Benjamin Livshits and Monica S. Lam. Finding security vulnerabilities in java applications with static analysis. In Proceedings of the 14th conference on USENIX Security Symposium - Volume 14, SSYM05, pages 1818, Berkeley, CA, USA, 2005. USENIX Association. [Lud11] [MF05] Courgnaud Ludovic. Xssf : dmontrer le danger des xss. 2011. Sara Mota and Benjamin Fontan. Uml-based modeling and formal verication of security protocols. In Proceedings of the 2005 ACM conference on Emerging network experiment and technology, CoNEXT 05, pages 282283, New York, NY, USA, 2005. ACM. [Mica] Microsoft anti-cross site scripting library v1.5. us/library/aa973813.aspx. [Micb] [MICL11] Eddington Michael. Peach fuzzing platform. http://peachfuzzer.com/FrontPage. Barreaud Mathieu, Julien Iguchi-Cartigny, and Jean-Louis Lanet. Analysis vulnerabilities in smart card web server. SAR-SSI 2011 Network and Information Systems Security, 2011. [Mit] [Mod] [MOZ] [MP] MITRE. http ://cwe.mitre.org/documents/vuln-trends/index.html. Modsecurity 2.7. http ://www.modsecurity.org. MOZILA. Noscript 2.5.7. http ://noscript.net/. Wojciech Mostowski and Erik Poll. Malicious code on java card smartcards : Attacks and countermeasures. http ://msdn.microsoft.com/en-

[LL05]

170

BIBLIOGRAPHIE

[MP07]

C. Miller and Z.N.J. Peterson. Analysis of Mutation and Generation-Based Fuzzing, 2007.

[MSP11]

Backesy Michael, Gerling Sebastian, and von Styp-Rekowsky Philipp. A local crosssite scripting attack against android phones. 2011.

[MVBL05]

C. Martin Michael, Livshits V. Benjamin, and Monica S. Lam. Finding application errors and security aws using pql : a program query language. In OOPSLA, pages 365383, 2005.

[Nav10] [NCE06]

Eduardo Alberto Vela Nava. Web Application Obfuscation. 2010. Jovanovic Nenad, Kruegel Christopher, and Kirda Engin. Pixy : A static analysis tool for detecting web application vulnerabilities (short paper). In IN 2006 IEEE SYMPOSIUM ON SECURITY AND PRIVACY, pages 258263, 2006.

[NN11]

Pierre Neron and Quang-Huy Nguyen. A formal security model of a smart card web server. In Proceedings of the 10th IFIP WG 8.8/11.2 international conference on Smart Card Research and Advanced Applications, CARDIS11, pages 3449, Berlin, Heidelberg, 2011. Springer-Verlag.

[OMYS04]

Ismail Omar, Etoh Masashi, Kadobayashi Youki, and Yamaguchi Suguru. A proposal and implementation of automatic detection/collection system for cross-site scripting vulnerability. Advanced Information Networking and Applications, International Conference on, 1 :145, 2004.

[OWAa]

OWASP. CAL WEB

OWASP

TOP

10

THE SECURITY

TEN

MOST

CRITI-

APPLICATION

VULNERABILITIES.

http ://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf. [OWAb] OWASP. XSS (Cross Site Scripting) Prevention Cheat Sheet.

https ://www.owasp.org/index.php/XSS__Prevention_Cheat_Sheet. [OWAc] OWASP. XSS Filter Evasion Cheat Sheet. https ://www.owasp.org/index.php/ XSS_Filter_Evasion_Cheat_Sheet. [OWA07] [P.A07] Owasp top 10 for java ee. 2007. A.Portnoy P.Amini. Sulley : Fuzzing framework, 2007. http://www.fuzzing.org/ wp-content/SulleyManual.pdf. [PHP] [PJM+ 00] Phpids web application security 2.0. Available from : http ://phpids.org/faq/. Bieber Pierre, Cazin Jacques, A. El Marouani, Girard Pierre, Lanet Jean-Louis, Wiels Virginie, and Zanon Guy. The pacap prototype : A tool for detecting java card illegal ow. In Java Card Workshop, pages 2537, 2000. [PMD] [QJP] [Qui11] [RAF04] Qj pro project. http ://pmd.sourceforge.net. Qj pro project. http ://qjpro.sourceforge.net. D. Quisquater, J.J.and Samyde. Electromagnetic attack. pages 382385, 2011. Nick Rutar, Christian B. Almazan, and Jerey S. Foster. A comparison of bug nding tools for java. In Proceedings of the 15th International Symposium on Software Reliability Engineering, ISSRE 04, pages 245256, Washington, DC, USA, 2004. IEEE Computer Society.

BIBLIOGRAPHIE

171

[RBL12]

Tiana Razandralambo, Guillaume Bouard, and Jean-Louis Lanet. A friendly framework for hidding fault enabled virus for java based smartcard. In DBSec, pages 122128, 2012.

[RO04]

Christian Rechberger and Elisabeth Oswald. Practical template attacks. In Information Security Applications, 5th International Workshop, WISA 2004, Jeju Island, Korea, August 23-25, 2004, Revised Selected Papers, volume 3325 of Lecture Notes in Computer Science, pages 443457. Springer, 2004.

[SAP06] [SCDC 11]

+

Open source static analysis tools for security testing of java web applications. 2006. http ://www.secologic.org/downloads/testing/061219_TestToolAnalyseV1.pdf. Mathilde Soucarros, Ccile Canovas-Dumas, Jessy Cldire, Philippe Elbaz-Vincent, and Denis Ral. Inuence of the temperature on true random number generators. In HOST, pages 2427, 2011.

[Ser03] [SJCP05]

JavaTM

Servlet

Specication,

Version

2.4,

Novembre

2003.

https ://jira.sakaiproject.org/secure/attachment/16135/servlet-2_4-fr-spec.pdf. Wagner Stefan, Jrjens Jan, Koller Claudia, and Trischberger Peter. Comparing bug nding tools with reviews and tests. In IN PROC. 17TH INTERNATIONAL CONFERENCE ON TESTING OF COMMUNICATING SYSTEMS (TESTCOM05), VOLUME 3502 OF LNCS, pages 4055. Springer, 2005. [SS02] David Scott and Richard Sharp. Abstracting application-level web security. In Proceedings of the 11th international conference on World Wide Web, WWW 02, pages 396407, New York, NY, USA, 2002. ACM. [Sta] [STE 82]
+

International Organisation for Standardization. ISO7816. Rap. tech. ISO, 1987. C.A. Sunshine, D.H. Thompson, R.W. Erickson, S.L. Gerhart, and D. Schwabe. Specication and verication of communication protocols in arm using state transition models. IEEE Transactions on Software Engineering, 8 :460489, 1982.

[SWS02]

Joel Scambray, David Wong, and Mike Shema. Hacking Exposed Web Applications : Web Application Security Secrets & Solutions. Osborne/McGraw-Hill, Berkeley, CA, USA, 2002.

[TCF05] [TDM08] [Tho10] [UL07] [Wal00] [WAP] [WAP08]

David Thomas and Andrew Hunt Chad Fowler. Programming Ruby : The Pragmatic Programmers Guide. Pragmatic Bookshelf, Raleigh, NC, 2. edition, 2005. A. Takanen, J. DeMott, and C. Miller. Fuzzing for software security testing and quality assurance. Artech House Publishers, 2008. Canno Thomas. Android data stealing vulnerability. 2010. http ://thomascannon.net/blog/2010/11/android-data-stealing-vulnerability/. Mark Utting and Bruno Legeard. Practical Model-Based Testing : A Tools Approach. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2007. Larry Wall. Programming Perl. OReilly & Associates, Inc., Sebastopol, CA, USA, 3rd edition, 2000. Web application vulnerability scanner / security auditor. Halfond William, Orso Alex, and Manolios Pete. Wasp : Protecting web applications using positive tainting and syntax-aware evaluation. IEEE Transactions on Software Engineering, 34 :6581, 2008.

172

BIBLIOGRAPHIE

[WAS] [WEB] [Won] [XSSa] [XSSb] [XSSc] [YX11]

WASS. http ://www.webappsec.org/projects/statistics/. Webfuzzer. E. Wong. clinton and http ://optimalcycling.com/other-projects/notscripts/limitations/. obama xss battle develops. http ://http ://noscript.net/. news.netcraft.com/archives/2008/04/24/clinton _and_obama_xss_battle_develops.html. Xss on defense.gouv.fr. http ://www.xssed.com/mirror/66908/. Xss on paypal.com. http ://www.xssed.com/news/44/PayPal_is_now_oering _a_free_URL_redirection_service/. X. Yang and X. Xiaoyao. Modeling and analysis of security protocols using colored petri nets. Journal of computers, 2011.

BIBLIOGRAPHIE

173