• Aucun résultat trouvé

3.2 Description des applications Java

4.1.6 La recherche de motifs de code ( pattern matching)

Lepattern matching est un terme très générique. Il consiste à reconnaître des contextes et des configurations prédéfinies. À ne pas confondre avecpattern recognition qui a pour but de faire de la classification à partir d’apprentissages. Dans notre contexte, les patterns sont des motifs de code qui peuvent se décrire de manière plus ou moins précise avec l’aide éventuelle d’élémentsjokers. Les éléments jokers sont utiles pour introduire des degrés de liberté sur des variables, des contextes, des types ou d’autres éléments lors de la détection du pattern. Dans le cadre de l’analyse statique de code, cette technique est massivement utilisée pour trouver des schémas connus comme étant indésirables. Les motifs de code simples les plus basiques sont descriptibles par des expressions régulières. Pour des cas moins triviaux, ils s’appuient sur une représentation intermédiaire (AST/CFG/DFA voir fig 4.8 ). Cette représentation abstraite est pertinente pour des applications mono langages mais peut s’avérer être un obstacle dans le 4. par exemple, le contenu d’une variable appellée à être affichée dans une page html ne doit pas contenir de balise <script . . .> mais peut contenir une balise <b>.

cas contraire. Effectivement le modèle ne pourra s’appliquer que sur les éléments représentés sous forme abstraite. Un exemple d’utilisation depattern matching dans le but de trouver des refactorings destinés à favoriser l’utilisation d’instructions multimédia dans un code en langage C peut être consulté dans [PBSB04]. Il existe aussi des applications dynamiques de cette approche, comme la reconnaissance de signatures d’attaques dans les paquets réseau par les IDS (Intrusion Detection System) ou dans le fonctionnement des antivirus.

4.1.6.1 Nature des motifs de code

Un motif de code s’identifie à partir d’un modèle (pattern). Ce modèle vise à décrire des caractéristiques et des propriétés particulières plus ou moins complexes de morceaux de code qui peuvent être répartis dans l’application analysée. La recherche de motif de code s’apparente aux problèmes de tri en intelligence artificielle et est parfois confrontée aux mêmes compromis lorsqu’elle n’est pas triviale. Ce point est développé dans la section 4.1.7

La façon dont sont représentés les modèles de motif de code et les techniques utilisées pour les identifier peut radicalement modifier le pouvoir de généralisation qui en résulte. Plus le mo- dèle est abstrait, éloigné du code, et plus il va pouvoir englober un ensemble de configurations important.

Il est possible de représenter le code d’un programme sous forme d’arbre syntaxique abs- trait (AST cf §G). Cet arbre peut être plus ou moins riche en fonction de l’exhaustivité des types d’informations qu’il permet de stocker. Effectivement, pour certaines analyses, certains éléments du code sont facultatifs, comme les commentaires par exemple. Lorsque on isole un nœud de cet arbre avec ses descendants, cela correspond à isoler un morceau du code original. De cette façon on peut agir et manipuler des parties du code de manière très précise. Les mo- tifs recherchés lors d’une analyse de code peuvent se concrétiser sous cette forme en précisant les caractéristiques recherchées des nœuds de l’arbre comme expliqué dans [AK08, TKB03] : les concrete syntax pattern. Il est courant de voir dans la formulation de ces modèles des caractères jokers pour conserver certains éléments indéfinis.

4.1.6.2 Exemple :

Le langage XPath5étant un langage de requêtes destiné aux structures de données XML ; si l’AST est représenté sous forme de structure XML, une requête Xpath pour ce dernier permet de décrire des motifs de code à rechercher car il permet d’y retrouver facilement un ensemble de nœuds avec toutes les instructions de parcours d’arbre nécessaires6. Cette méthode est utilisée par de nombreux outils d’audit. Un exemple d’utilisation des requêtes Xpath :

Une structure de données XML et son arbre de données correspondant fig 4.2 : 1 <?xml v e r s i o n=' 1 . 0 ' ?> 2 <root> 3 <x>v e r t</x> 4 <y> 5 <x>bleu</x> 5. http://www.w3.org/TR/xpath 6. http://msdn2.microsoft.com/en-us/library/ms256086.aspx

6 <x>bleu</x> 7 </y> 8 <z> 9 <x>rouge</x> 10 <x>rouge</x> 11 </ z> 12 <x>v e r t</x> 13 </ root> 14 }

FIGURE4.2 – Représentation des données XML. et enfin, une requête :

Valeurs des éléments  x à la racine du n÷ud  root ou bien sous un élément  y  : 1 <?xml v e r s i o n=' 1 . 0 ' ?>

2 <x s l : t e m p l a t e match=" root "> // pour l e n\ oe ud " root " 3 <x s l : f o r −each s e l e c t="x | y/x"> // s e l e c t i o n l e s éléments x à

4 // l a r a c i n e ou sous un élément y

5 <x s l : v a l u e −o f s e l e c t=" . "/> // donne l a v a l e u r des éléments

6 < x s l : i f t e s t=" not ( p o s i t i o n ()= l a s t ( ) ) "> ,</ x s l : i f> // s i ce n ' e s t pas l e derni er , a j o u t e une v i r g u l e 7 </ x s l : f o r −each>

8 </x s l : t e m p l a t e >

Pour la structure représentée en fig 4.2, avec comme valeur la couleur des nœuds, la ré- ponse sera : « vert, bleu, bleu, vert ».

Un autre exemple basique de recherche de motif de code et son résultat sont illustrés en figure 4.3 avec le code suivant. On remarque le caractère joker " ?".

1 c l a s s C{ 2 void x ( ){

FIGURE4.3 – Représentation du motif, Résultats sur AST du code de la classe « C »[AK08]. 3 A. a (42 , 4 3 ) ; 4 t h i s . y ( ) ; 5 y ( ) . y ( ) ; 6 } 7 C y ( ) { 8 return t h i s ; 9 } 10 }

Il est possible d’utiliser ou de créer d’autres langages pour effectuer des recherches dans un arbre syntaxique, comme dans tout arbre de données. Ces deux exemples ne sont pas concernés par la problématique de faux positifs, ou de faux négatifs, car les informations utiles sont sûres et complètes.