Avec une approche statique, des problème qui peuvent survenir lors de l’exécution restent inabordables. Avoir un code qui respecte toutes les règles de codage et dépourvu de failles connues n’apporte par de garantie sur son bon fonctionnement. L’utilisation de tests reste in- dispensable.
Certains patterns ne pourront jamais être corrigés automatiquement. Par exemple, lorsque dans un fichier de configuration le type d’un champ n’est pas respecté, on ne peut pas choisir au hasard une instance de classe qui corresponde au type du champ pour le mettre à la place. D’autres problèmes ne pourront même pas être détectés.
Par exemple, une application est considérée consistante, non porteuse de code malicieux et sans faille de sécurité connue si :
– Tous les fichiers qui la composent sont conformes à une grammaire ou à un format prédéfini7.
– Le contenu des fichiers et des flux de données est adapté à l’utilisation qui en est prévue dans le code en respectant un type8prédéfini.
– L’absence de failles connues a été contrôlée à l’aide de règles spécifiques. Un exemple de mauvaise pratique qui introduit une faille de sécurité est montré dans les résultats §2.3.5.
7. Pour les fichiers de codes compilables, cette opération est effectuée par le compilateur du langage. Cependant, certains fichiers ne sont compilés qu’à la demande, lors de l’exécution.
Il y a exploitation d’une faille de sécurité lorsque l’exécution sort du périmètre défini par la politique de sécurité. Pour certains cas ce n’est qu’à l’exécution que l’ambiguïté peut être levée, car ce périmètre fluctue avec le contexte (rôle de l’utilisateur, état du système,. . .). C’est donc en fonction du contexte de l’utilisation d’une donnée qu’il est possible de juger de sa nocivité et de sa correction. La validation de flux construits lors de l’exécution peut se faire à l’aide de filtres dont la permissivité varie en fonction d’informations contextuelles. Concevoir une règle qui vérifie l’adéquation entre le contexte d’utilisation et l’espace de valeurs permis pour une variable peut s’avérer particulièrement ardu.
L’ajout de méta données sur les variables peut servir pour les typer [CVM07, CLM+09]. Ainsi, leur contenu et leur utilisation peuvent être contrôlés, ce qui limite les possibilités d’in- jections. Cependant, lorsqu’il n’est pas possible de déterminer précisément le rôle que peut jouer une donnée dans l’application finale, il est impossible de savoir si elle est correctement typée. Par conséquent on ne peut savoir si son contenu est dans un domaine de valeur correct non malicieux, et utilisé à bon escient.
Le fait d’envelopper un fichiers non java dans une classe fictive pour la faire abstraire par un parseur java rend son analyse superficielle car elle reste au niveau textuel. Cela est une solution rapide mais ne peut pas convenir pour des motifs de code polymorphes. L’ideal est d’avoir un parseur pour chaque language utilisé par l’application.
Le chapitre suivant apporte des conclusions sur les résultats vus dans ce chapitre et propose des perspectives possibles d’autres utilisations d’un outil comme le nôtre.
Conclusions et perspectives
3.1
Synthèse
Les limites des outils d’analyse statique de code Java existants ne permettent pas d’ap- préhender correctement la complexité des applications actuelles toujours plus volumineuses et qui utilisent plusieurs langages. Ils sont par exemple de plus en plus incapables de déceler les failles de sécurité qui sont exploitées actuellement dans des frameworks massivement utilisés comme Spring pour des applications Web grand public1 2.
Les propriétés que nous avons considérées comme indispensables pour un outil d’analyse et de transformations d’application web performants sont, par ordre croissant d’importance, les suivantes :
– Réusabilité et configurabilité et ouverture du système de règles, ergonomie de l’environ- nement de développement des règles, souplesse s’utilisation : l’ensemble des règles est évolutif car il est lié à des technologies en constante évolution. Un outil d’analyse doit pouvoir intégrer facilement ce phénomène pour rester compétitif en permettant le déve- loppement de nouvelles règles. La configurabilité est importante pour pouvoir s’adapter à l’utilisateur. Enfin l’intégration efficace de l’outil dans divers contextes de développe- ment est également un atout indéniable.
– Parallélisation des traitements et transformation automatique du code : cette approche permet de gérer la taille grandissante des applications. Cette exigence correspond de plus à la tendance du fonctionnement matériel sous jacent qui s’oriente vers le multi et many core. Les performances des applications séquentielles seront par conséquent vite distancées par celles des applications parallèles. De plus, l’automatisation des correc- tions permet de faire face au volume très important de problèmes pouvant survenir sur ce type d’applications.
– Diversification des langages accessibles par l’analyse et la transformation de code. La nature même des applications Web est multilingue. Le comportement des applications 1. CVE-2009-2907 : Multiple XSS vulnerabilities, http://www.springsource.com/security/ cve-2009-2907
2. CVE-2010-1622 : Spring Framework execution of arbitrary code, http://www.springsource.com/ security/cve-2010-1622
est extrêmement dépendant du contenu de fichiers rédigés dans divers langages. Nous avons montré que pour aborder le plus grand nombre de motifs de code pathogènes, les outils doivent prendre en compte cet aspect.
L’outil développé pour défendre cette thèse intègre toutes ces contraintes. Il permet ainsi d’implémenter facilement toute opération de transformation de code automatisable. Les pre- miers résultats d’analyse s’appuyant sur plusieurs formes de données ouvrent des perspectives d’analyse et de transformation plus poussées que celles disponibles à l’heure actuelle avec des techniques bien éprouvées (pattern matching sur AST).
Des cas de faux positifs ont été résolus grâce à l’ajout d’informations en provenance de contenus non Java dans l’analyse statique. De plus, certaines règles s’appliquent également pour les contenus non-java directement. Par exemple, des règles de sécurité reposent sur des fichiers de configuration XML.
Les premiers résultats montrent qu’une approche holistique permet d’avoir des réponses à certains problèmes de sécurité jusqu’alors non abordés. Il n’a pas été expérimenté de vérifica- tion d’intégrité de fichiers de données multimédia par manque de temps mais cette perspective rendue maintenant possible pourrait également éviter des attaques liées à la vulnérabilité d’ap- plications tierces.
Ces propriétés donnent accès à plus de possibilités de contrôles, et plus de productivité, mais des éléments resteront toujours à détecter et à corriger manuellement parce que le coût nécessaire à leur détection n’est pas compensé par la fréquence de leurs occurrences.
Lorsque l’on lit la spécification d’HTML5 par le W3C3, on peut constater que les pages vont devenir de plus en plus complexes avec une quantité de nouvelles balises. Les navigateurs n’auront par exemple plus besoin de faire appel à des plugins pour lire les contenus vidéo, audio, ou faire de la 3D. Il y a fort à parier que ces nouvelles fonctionnalités vont ouvrir de nouveaux problèmes de sécurité qui deviendront très difficilement abordables sans pouvoir analyser le contenu interprété par le navigateur client aussi bien que le contenu compilé coté serveur.