Regex en rétrograde

« Certaines personnes, lorsqu'elles sont confrontées à un problème, pensent : “Je sais, je vais utiliser les expressions régulières.” Maintenant, elles ont deux problèmes. » – Jamie Zawinski

Les expressions régulières sont un moyen concis de décrire comment faire correspondre des motifs spécifiques ou des séquences de jetons, généralement du texte. Mais l'approche consistant à faire correspondre des séquences de texte est-elle efficace pour détecter les logiciels malveillants ou les attaques d'applications web ? Plus précisément, pour quels types d'attaques d'applications web l'approche par expressions régulières (regex) est-elle efficace ? Nous ne voulons pas succomber au biais du statu quo et saboter nos résultats en matière de sécurité en nous en tenant à quelque chose d’inefficace, après tout.

Regex est utile pour les copier-coller prisés par les hackers novices — lorsque le hacker ne comprend pas comment l'attaque fonctionne parce que quelqu'un d'autre l'a créée pour lui. Le « hacker novice » (c'est-à-dire amateur) l'opérationnalise simplement et maraude sur Internet grâce à un outil comme Shodan. Mais le plus simple, c'est que l'efficacité de Regex cesse d'être efficace.

Les personnes qui créent les éléments réutilisables de l’attaque savent qu’elles pourraient transformer n’importe lequel d’entre eux pour contourner le mécanisme de correspondance de modèles simpliste offert par regex. En fait, la séquence précise des jetons n'est pas vraiment significative – c'est l'expression complète de ces jetons qui importe. 

Ce qui importe, c’est le comportement de l’attaque — comment les actions se déroulent dans l’espace-temps. Les bits ou le texte spécifiques sont un détail de l’implémentation plutôt qu'une description de la manière dont l'attaque fonctionne. 

Prenons l’exemple d’un téléviseur retiré du mur. Est-il utile pour nous de savoir quel type spécifique de tournevis est utilisé ? Peut-être que c’est nous qui utilisons le tournevis pour ajuster la hauteur du téléviseur, plutôt qu’un cambrioleur qui le dérobe. Mais si la fenêtre du salon est brisée et que quelqu'un arrache le téléviseur du mur, ce comportement suinte la malveillance.

En essence, les modèles de texte dans différents contextes signifient des choses différentes et produisent des résultats différents. Le contexte est important. Une description textuelle d'un exploit d'injection SQL (SQLi) dans un article de blog est très différente de celle d'une personne lançant une attaque SQLi contre l'hébergeur de ce blog. Les deux contiendront le modèle de texte représentatif de cette classe d'attaque, mais une seule instance reflète une attaque réelle.

Cela ne veut pas dire que les expressions régulières sont toujours inutiles partout. Les regex sont des représentations économes pour la correspondance de modèles : elles sont idiomatiques et relativement lisibles. Le problème est la correspondance de modèles — les jetons de correspondance de modèles, tels que le texte dans les paramètres de requête ou les champs du corps POST, ne capturent que les attaques les plus rudimentaires. Il en va de même en dehors du domaine des applications web ; une expression régulière pour un hachage de fichier spécifique suppose que l'attaquant est si peu motivé et négligent qu'il renonce à l'effort de transformer le fichier pour échapper à une détection aussi simple. Parfois, cela sera vrai ; la plupart du temps, cela ne le sera pas.

Même si l'on met de côté la précision, les regex peuvent entraîner des frais généraux écrasants pour les défenseurs. Regex est souvent inflexible, peu maniable et difficile à maintenir, surtout lorsque vous essayez d’y intégrer plus de contexte. Par exemple, tenter de capturer une liste de commandes Linux/Windows valides pour détecter une injection de commandes serait illisible, voire impossible à réaliser correctement avec des expressions régulières – et il en va de même pour les injections SQL. Le modèle résultant serait illisible pour un humain, ce qui n'est pas durable (même si vous construisez des grammaires regex). 

Considérez cette expression régulière « simple » pour valider les adresses e-mail:

`(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9]))\.){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9])|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])`

Prenez-vous plaisir à l'analyser avec vos yeux ou cela vous paraît-il un peu barbare ?

Source de l'image

Lorsque vous souhaitez suivre les techniques et schémas d'attaque émergents ou évolutifs, les frais généraux impliqués (temps, effort, caféine, etc.) font que les changements se produisent moins fréquemment, ce qui réduit l'efficacité de la solution. Les expressions régulières peuvent également être lentes et gourmandes en ressources, surtout lorsqu'il s'agit d'expressions complexes difficiles à optimiser. Qu’il s’agisse de frais généraux humains ou de frais généraux de performance, le retour sur investissement des expressions régulières pour la détection des attaques n’en vaut souvent pas la peine.

Regex a sa place, mais pas la détection des attaques. De nombreux fournisseurs ne souhaitent pas que les acheteurs le découvrent, car il est bien moins coûteux de maintenir la technologie existante que d'investir dans l'innovation. Néanmoins, les regex n'inquiètent pas les hackers et ne rendent pas leurs attaques plus coûteuses. 

Des techniques telles que l'analyse des requêtes HTTP peuvent offrir un investissement plus économique, permettant aux défenseurs d'intégrer davantage de contexte pour commencer à faire correspondre les comportements d'attaque, tout en réduisant l'effort requis par les humains et les machines. La dissection du comportement des attaques permettra de détecter à la fois les attaques rudimentaires et celles plus complexes – ainsi que toutes leurs variantes – sans qu'il soit nécessaire d'élaborer une nouvelle règle pour chaque nouvelle vulnérabilité qui apparaît (ce qui est souvent le cas). Si nous examinons le contexte de l'attaque et la manière dont une requête est traitée à la durée d'exécution, nous pouvons prendre des décisions plus précises qu'avec les expressions régulières.

Ainsi, nous arrivons aujourd’hui à la distorsion du marché : les listes de contrôle des acheteurs de sécurité incluent toujours la « correspondance regex » comme une fonctionnalité clé dans leurs produits de sécurité des applications web (et souvent dans d’autres produits, comme les règles YARA dans les outils de point de terminaison) malgré son inadéquation. Cette exigence a bien servi les clients pendant un certain temps, à une époque où les produits de la plupart des fournisseurs reposaient sur des regex – quand il n'y avait pas de meilleures idées. Nous ne sommes plus dans ce monde-là.

Enlevez vos œillères et corrigez vos listes de contrôle

Imaginez la scène suivante à des fins d’illustration : un client entre dans un concessionnaire automobile et demande si la voiture est équipée de stores. 

« Non », répond le vendeur, confus « Vous n'avez pas besoin d'œillères sur une voiture. » Le client secoue la tête avec désapprobation, tapotant sa liste de contrôle.

« Et les fouets de buggy ? », demande le client

« Vous n'avez pas non plus besoin de fouets pour calèches. » « Nous ne pratiquons plus les flagellations. »

« Je suppose que vous allez me dire ensuite qu'il n'y a ni harnais ni bride non plus ! »

« C'est exact. » « C'est une voiture. » Le vendeur se pince l’arête du nez en soupirant et demande : « Que devez-vous accomplir exactement ? »

« Pour voyager du point A au point B en toute hâte », répond le client confiant

« C’est vrai, une voiture est bien meilleure pour cela qu’une calèche. » C'est conçu de cette manière pour une raison. « C'est de l'innovation pour améliorer votre vie. »

« Et pourtant, toutes ces fonctionnalités sont absentes ! »

Cet exemple est évidemment absurde et pourtant il n’est pas sans rappeler les conversations entendues aujourd’hui dans le domaine de la cybersécurité. Il est compréhensible que nous puissions nous accrocher à notre liste familière de caractéristiques en tant qu'acheteurs ; les questions sur les œillères, les fouets d'attelage et les brides sont toutes des questions très judicieuses lors de l'achat d'une calèche. Mais ces listes de contrôle sont intrinsèquement statiques, nous ancrant dans un passé souvent obsolescent.

Nous déplorons la rapidité et l'évolution constante des hackers et pourtant, trop souvent, nous choisissons des produits en fonction de caractéristiques technologiques qui n'étaient acceptables qu'autrefois. Les hackers gardent leurs options ouvertes et choisissent les bons outils pour atteindre leurs objectifs ; nous devrions faire de même en tant que défenseurs. Bien que ce ne soit pas la seule option, nous pouvons envisager des techniques défensives plus récentes mais bien éprouvées, comme l'analyse des paramètres de requête pour analyser les résultats d'une requête à la durée d’exécution, ce qui permet de gagner en rapidité, en précision et en flexibilité.

Il est difficile de réaliser que nos modèles mentaux concernant une problématique sont incorrects et dépassés – que la réalité a évolué plus vite que notre conception, même si nous avons investi tant de ressources dans ces pâturages finalement infructueux. C’est précisément cette obsolescence, ces hypothèses incontestées, que les hackers exploitent. Si nous voulons réussir à atteindre notre objectif de déjouer les hackers, nous devons aller au-delà des regex pour entrer dans une ère de détection plus moderne.

Pour en savoir plus sur la manière dont Fastly aide les défenseurs à dépasser les regex grâce à l'analyse syntaxique, consultez notre feuille de données sur la détection SmartParse ou notre blog sur la manière dont nous avons exploité l'analyse syntaxique pour l'attaque Log4Shell. Ou requête une démo – nous serions ravis de vous montrer comment cela fonctionne.