Notes de sécurité : RegEx

Les expressions régulières peuvent‑elles être vulnérables ?

Photo by Markus Spiske on Unsplash

Rejet de service par expression régulière : ReDOS

L’une des vulnérabilités les plus surprenantes, et pourtant difficiles à repérer, que j’ai rencontrées concerne les expressions régulières.
Qu’elles soient mal écrites ou mal implémentées, elles peuvent épuiser la mémoire ou le CPU avec des entrées utilisateur volumineuses ou spécialement conçues.

Il s’agit d’une vulnérabilité de déni de service, pas seulement d’un indice de performance. Si une entrée hostile peut monopoliser le CPU suffisamment longtemps pour priver les utilisateurs légitimes de ressources, elle doit figurer dans votre modèle de menace de sécurité.

Signaux d’alerte

1. Quantificateurs imbriqués, groupes répétés ou alternances qui se chevauchent
2. Moteurs à forte rétro‑exploration sans délai d’attente ni limite de longueur d’entrée
3. L’expression est appliquée à des données utilisateur non validées
4. La validation par regex s’exécute sur un chemin de requête critique

Atténuation / Résolution

1. Les expressions régulières sont difficiles.
   1. Par exemple, voici comment les experts de [OWASP recommandent la validation d’IP][owasp] : ^(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$
   2. C’est plus long qu’un tweet (à l’ancienne), pour une adresse IP de 4 octets !!!
2. Limiter la longueur d’entrée avant l’évaluation de l’expression régulière.
3. Ajouter des délais d’attente, de l’analyse statique, ou un moteur non rétro‑explorateur lorsque la plateforme le permet.
4. Cela concerne presque tous les langages et plateformes : .NET, Node, Python, PERL, Java.

Référence

• OWASP ReDoS