Regex sécurisé : valider les formats sans ReDoS
Apprenez à écrire un regex sécurisé pour valider vos entrées et bloquer les attaques ReDoS. Essayez notre testeur de regex sécurisé dès maintenant.
L'utilisation d'un regex sécurisé est essentielle pour valider les données d'entrée des utilisateurs tout en évitant des pannes logicielles critiques. Les expressions régulières (regex) sont des outils formidables pour valider divers formats de données comme les adresses e-mail, les numéros de téléphone ou les codes postaux. Cependant, une mauvaise conception de ces expressions peut exposer vos applications web à des attaques par déni de service (ReDoS ou Regular Expression Denial of Service).
Dans ce guide détaillé, nous analyserons le fonctionnement du ReDoS, la nature du backtracking catastrophique, comment détecter les vulnérabilités de vos patterns et comment les corriger pour sécuriser votre infrastructure.
Qu'est-ce que le Backtracking Catastrophique ?
Pour comprendre les vulnérabilités liées aux expressions régulières, il faut examiner la façon dont fonctionnent la plupart des moteurs de regex. Les langages populaires (comme JavaScript, Python, PHP et C#) utilisent des moteurs basés sur des Automates Finis Non Déterministes (NFA). Ces moteurs évaluent les correspondances à l'aide d'un algorithme de recherche en profondeur appelé backtracking (retour sur trace).
Lorsqu'un moteur NFA tente de faire correspondre un motif à une chaîne et rencontre plusieurs embranchements possibles, il choisit un chemin et continue. Si ce chemin échoue plus loin dans la chaîne, le moteur revient en arrière pour essayer une autre branche. Si le motif est mal configuré et que la chaîne d'entrée est malveillante, le nombre de combinaisons possibles croît de façon exponentielle. C'est ce que l'on appelle le backtracking catastrophique.
// Exemple classique de motif JavaScript vulnérable
const regexVulnerable = /^([a-zA-Z0-9]+)*$/;
const entreeMalveillante = "a".repeat(30) + "!";
console.time("Execution Regex");
regexVulnerable.test(entreeMalveillante);
console.timeEnd("Execution Regex");
// L'évaluation prendra plusieurs secondes ou minutes,
// bloquant le thread principal de Node.js.
Si un pirate découvre ce type de regex dans un formulaire d'inscription ou un paramètre d'API, il lui suffit d'envoyer une chaîne similaire. Sur un serveur Node.js, ce traitement monopolisera le thread d'exécution principal, entraînant une surcharge de la CPU à 100 % et empêchant les requêtes légitimes d'aboutir.
Anatomie d'un Regex Vulnérable au ReDoS
Les regex exposées aux attaques ReDoS partagent des caractéristiques structurelles communes. Le problème provient généralement de quantificateurs imbriqués ou de groupes qui se chevauchent, compliquant la tâche du moteur pour valider chaque caractère de façon unique.
Voici les trois principaux motifs à éviter absolument :
- Quantificateurs imbriqués : Des expressions comme
(a+)+ou([a-zA-Z0-9]+)*où un groupe déjà quantifié est soumis à une autre quantification externe. - Alternatives qui se chevauchent : Des motifs comme
(a|a)+ou(\w+|[a-zA-Z]+)+où le moteur peut valider le même caractère via différentes branches. - Chevauchement de préfixes et de suffixes : Des structures telles que
\w+\d+\w+appliquées à des entrées très longues qui ne se terminent pas par le délimiteur attendu.
Comparatif des Moteurs de Regex : Backtracking vs Temps Linéaire
Tous les moteurs de regex ne sont pas vulnérables au ReDoS. Tout dépend de la technologie de traitement choisie : NFA (temps exponentiel mais fonctionnalités avancées comme les références arrière) ou DFA (Automates Finis Déterministes, temps de calcul linéaire mais fonctionnalités plus restreintes).
| Moteur / Bibliothèque | Type d'Algorithme | Temps d'Exécution | Vulnérable au ReDoS | Cas d'Utilisation Recommandé |
|---|---|---|---|---|
| V8 (JS / Node.js) | NFA | Exponentiel | Oui | Validations standard avec contrôle strict de la taille. |
Python re |
NFA | Exponentiel | Oui | Analyse de texte dans un environnement de confiance. |
Go regexp (RE2) |
DFA | Linéaire | Non | Services hautement concurrents traitant des données non fiables. |
Rust regex |
DFA / Hybride | Linéaire | Non | Systèmes critiques exigeant des garanties de performance absolues. |
| .NET Regex Engine | NFA (avec Timeouts) | Exponentiel (configurable) | Oui (Atténué par timeout) | Applications d'entreprise avec gestion du temps de calcul. |
Comme l'indique ce tableau, les moteurs comme RE2 de Google (intégré dans Go et disponible pour Node.js ou Python) assurent un temps d'exécution linéaire $O(N)$ en éliminant les retours sur trace, éliminant tout risque de ReDoS.
Stratégies de Mitigation et Bonnes Pratiques
Protéger vos applications contre les attaques ReDoS nécessite une approche combinant une écriture rigoureuse et des limites de sécurité.
1. Éviter les chevauchements et l'imbrication
Concevez vos expressions régulières de manière à ce qu'un caractère d'entrée ne puisse être validé que par un seul chemin logique. Par exemple, au lieu d'utiliser ^(\w+\s*)+$, utilisez un motif limitant la structure : ^\w+(?:\s+\w+)*$.
2. Valider la longueur de la chaîne avant d'appliquer la Regex
Le backtracking catastrophique nécessite des entrées volumineuses pour paralyser un système. Si vous vérifiez un code postal ou un e-mail, contrôlez d'abord la longueur de la variable. Si celle-ci dépasse la taille maximale attendue, rejetez-la immédiatement sans exécuter le regex.
function validerEntree(entree: string): boolean {
// 1. Limite stricte de la longueur
if (entree.length > 50) {
return false;
}
// 2. Application de la regex sécurisée
const regexSecurise = /^[a-zA-Z0-9.-]+$/;
return regexSecurise.test(entree);
}
3. Configurer un délai d'attente (Timeout)
Si votre framework supporte la configuration de timeouts de regex (comme .NET), activez-les systématiquement (par exemple, 100 ms max). Si l'évaluation prend trop de temps, le moteur s'arrêtera et lèvera une exception, protégeant vos ressources CPU.
Outils d'Audit et de Coder Segue
La recherche de failles ReDoS doit faire partie intégrante de votre cycle de développement (SDLC). De même que vous réalisez des audits de vulnérabilités par IA ou par pentesting humain pour cartographier vos risques globaux, vous devez utiliser des analyseurs de code pour examiner vos expressions régulières.
Tandis que des vulnérabilités logicielles complexes — à l'instar de la récente faille d'exécution de code de Cursor IDE liée à un dépôt Git malveillant — nécessitent des vérifications dynamiques poussées, les erreurs de regex se préviennent facilement à l'aide de linters.
Pour tester et analyser vos motifs en direct, nous vous conseillons d'utiliser notre outil de Testeur de Regex en ligne. Il vous aidera à évaluer vos formats en toute sécurité.
Conclusion
L'écriture d'un regex sécurisé implique de comprendre le moteur d'exécution sous-jacent. Omettre le risque de ReDoS offre à des attaquants une méthode simple pour faire tomber vos serveurs web en envoyant seulement quelques octets mal formés.
Il est tout aussi capital de vulgariser ces notions auprès de vos équipes ; découvrez par exemple notre guide pour savoir comment partager des mots de passe en toute sécurité sur Internet afin de renforcer l'ensemble de votre sécurité numérique. Surveillez la taille de vos données, restez simple dans vos motifs et auditez vos projets régulièrement.
Sources et documents officiels :
- OWASP: Regular Expression Denial of Service - ReDoS — Fiche technique officielle d'OWASP sur les attaques ReDoS.
- Google RE2 Repository — Documentation et code du moteur de regex linéaire RE2 de Google.
- Article lié sur TecnoCrypter : Audit de vulnérabilités : IA vs Pentesting Humain.
