Les attaques par déni de service par expression régulière (ReDoS) représentent un risque croissant au sein de sécurité des applications modernesÀ mesure que de plus en plus d'équipes s'appuient sur la validation des entrées et la correspondance de modèles, une expression régulière mal conçue peut introduire des vulnérabilités de performance que les attaquants peuvent exploiter pour ralentir les services ou provoquer des interruptions de service. En effet, OWASP ReDoS est décrit comme une attaque par déni de service qui exploite le fait que de nombreuses implémentations d'expressions régulières peuvent devenir extrêmement lentes, parfois avec un temps d'exécution qui augmente de façon exponentielle avec la taille de l'entrée.
Parallèlement, les attaques ReDoS sont particulièrement dangereuses dans les environnements cloud-native et CI/CDDans les environnements pilotés par les systèmes, une simple expression régulière vulnérable dans une API, une passerelle ou un flux d'authentification peut impacter la disponibilité à grande échelle. C'est pourquoi les équipes doivent considérer les attaques ReDoS comme un véritable risque de disponibilité, et non comme un cas particulier.
Plus important encore, ces vulnérabilités passent souvent inaperçues lors du développement, car les approches traditionnelles se concentrent sur la syntaxe plutôt que sur le comportement d'exécution. Par conséquent, des expressions régulières inefficaces peuvent facilement se retrouver en production sans déclencher la moindre alerte.
C’est là qu’interviennent les plateformes de sécurité applicative modernes comme Xygeni. En intégrant des contrôles de sécurité directement dans les flux de développement, elles permettent de détecter ces problèmes plus tôt et de prioriser les risques réellement accessibles et importants, au lieu de générer inutilement des alertes.
Qu'est-ce que ReDoS (Regular Expression DoS) ?
ReDoS (Regular Expression Denial of Service) est une vulnérabilité qui se produit lorsqu'un modèle d'expression régulière provoque un retour en arrière excessif, conduisant à un temps d'exécution exponentiel.
En termes simples, une entrée malveillante peut contraindre votre application à consacrer un temps considérable à l'évaluation d'une expression régulière, bloquant ainsi le système et dégradant ses performances.
Par exemple, des modèles avec des quantificateurs imbriqués comme :
(a+)+peut devenir très inefficace lors du traitement de certaines entrées, en particulier lorsqu'elles sont conçues intentionnellement par un attaquant.
Bien que cela puisse paraître un cas particulier, c'est étonnamment courant dans les applications du monde réel, notamment dans la logique de validation, les entrées de formulaire et la gestion des requêtes API.
Comment fonctionnent les attaques ReDoS
Une attaque ReDoS ne nécessite pas d'exploitation avancée. Elle exploite plutôt le comportement prévisible des moteurs d'expressions régulières.
Retournement catastrophique
L'attaquant cible une expression régulière pouvant correspondre à plusieurs chemins. Il fournit ensuite des données d'entrée forçant le moteur à explorer la plupart, voire la totalité, de ces chemins.
Entrée conçue par les attaquants
Les attaquants envoient généralement :
- Longues chaînes de caractères répétées.
- Des entrées qui correspondent presque, puis qui échouent à la fin.
- Des charges utiles qui se concentrent sur la partie la plus ambiguë du modèle.
Dégradation de la performance
Comme chaque requête peut consommer beaucoup de ressources du processeur, l'effet s'accumule rapidement :
- Latence plus élevée sur l'ensemble des points de terminaison.
- Épuisement du pool de threads.
- La boucle d'événements se bloque dans les environnements d'exécution monothread.
Ces attaques ne nécessitent pas d'exploits complexes. Elles tirent plutôt parti de la correspondance de motifs inefficace, ce qui les rend difficiles à détecter si vos outils ne vérifient que la syntaxe ou les vulnérabilités connues (CVE).
Impact concret des vulnérabilités ReDoS
ReDoS touche le premier point du modèle CIA : la disponibilité. Cela peut ressembler à un problème de stabilité plutôt qu’à un incident de sécurité, jusqu’à ce que l’on fasse le lien.
Ralentissement de l'API
Un seul point de terminaison utilisant une expression régulière vulnérable peut provoquer une surconsommation du processeur lors de la validation des entrées, du routage des requêtes ou des contrôles d'authentification.
Panne de service
En cas de forte charge, un point d'accès ReDoS peut provoquer le redémarrage des pods, dégrader la mise à l'échelle automatique et déclencher des défaillances en cascade.
Épuisement des ressources
ReDoS peut consommer :
- Processeur sur les nœuds d'application.
- Mémoire due à l'état de retour en arrière.
- Des processus de travail qui bloquent les autres requêtes.
Comme les attaques ReDoS ciblent les performances plutôt que l'exposition des données, de nombreuses équipes sous-estiment leur impact. Or, la disponibilité est un élément essentiel de la sécurité des applications, et les interruptions peuvent rapidement engendrer des risques pour l'entreprise.
Les changements radicaux sont le véritable problème de confiance.
Lorsque les développeurs disent qu'ils ne font pas confiance à la correction automatique, ils veulent souvent dire une chose très précise : ils craignent qu'elle ne casse quelque chose.
Ce problème de confiance est particulièrement visible dans la résolution des dépendances.
Un package vulnérable peut avoir une version corrigée disponible, mais cela ne signifie pas que la mise à jour est sûre. La version corrigée peut supprimer une méthode utilisée par votre application, renommer une API, restreindre un contrat de type ou modifier le comportement de manière à réussir les tests unitaires, mais à provoquer des régressions en production. Dans de nombreuses équipes, le véritable coût de la correction ne réside pas dans l'application du correctif, mais dans l'analyse des conséquences de l'incident.
Prenons un exemple simple en Java. Un code source dépend d'une bibliothèque où une méthode courante existe dans la version 1.x mais est supprimée dans la version 2.x.
Attaques ReDoS et incidents de sécurité dans le monde réel
ReDoS n'est pas qu'une vulnérabilité théorique. Elle a été exploitée dans des applications réelles, affectant des bibliothèques largement utilisées et des systèmes de production.
Voici quelques exemples notables qui mettent en évidence l'impact des modèles d'expressions régulières inefficaces :
Vulnérabilité ReDoS de Moment.js
L'une des vulnérabilités ReDoS les plus connues a été affectée. Moment.js, une bibliothèque de gestion de données JavaScript largement utilisée.
- Un modèle d'expression régulière mal conçu a provoqué un retour arrière excessif.
- Les attaquants pourraient déclencher une utilisation élevée du processeur avec des entrées spécialement conçues.
- Les applications utilisant Moment.js sont devenues vulnérables aux attaques par déni de service.
Ce problème a démontré comment même des bibliothèques de confiance peuvent introduire des vulnérabilités liées aux performances dans des milliers d'applications.
Bibliothèque de validation Node.js (validator.js)
Un autre exemple impliquait validateur.js, couramment utilisé pour la validation des entrées.
- Certaines fonctions de validation reposaient sur des expressions régulières inefficaces.
- Des entrées malveillantes pourraient considérablement retarder l'exécution
- Cela a affecté les API et les services backend reposant sur la validation des entrées utilisateur.
Étant donné que validateur.js est largement utilisé, son impact s'est étendu à de nombreuses applications et services.
Panne de Cloudflare (Défaillance basée sur une expression régulière)
Un incident très médiatisé s'est produit Cloudflare, où un modèle d'expression régulière défectueux a provoqué une panne majeure.
- Une expression régulière déployée en production a déclenché une utilisation excessive du processeur.
- Les systèmes sont devenus globalement non réactifs
- De larges portions d'Internet ont été temporairement affectées.
Bien qu'il ne s'agisse pas d'une attaque malveillante, cet incident montre clairement comment les inefficacités des expressions régulières peuvent avoir des conséquences concrètes à grande échelle.
Pourquoi les outils de sécurité traditionnels passent à côté de ReDoS
Cette section est consacrée à la conversion car elle explique le fossé que ressentent la plupart des équipes : les scanners fonctionnent, dashboardet pourtant ReDoS parvient encore à passer.
Les outils statiques se concentrent sur la syntaxe
De nombreux scanners peuvent signaler les « modèles d'expressions régulières dangereux », mais ils manquent souvent de certitude quant à la possibilité d'exploiter réellement le modèle dans votre contexte.
Aucun contexte d'exécution
ReDoS concerne le comportement à l'exécution. OWASP note que de nombreuses implémentations d'expressions régulières peuvent atteindre des situations extrêmes et fonctionner très lentement, parfois de manière exponentielle en fonction de la taille de l'entrée.
Si un outil ne tient jamais compte de la forme des données d'entrée, des conditions d'échec de la correspondance ou des chemins d'exécution, il passera à côté du risque ou vous submergera de faux positifs.
Aucune analyse d'exploitabilité
Une expression régulière peut être « théoriquement risquée » mais inexploitable en pratique. Inversement, un validateur « mineur » sur un point de terminaison public peut constituer un véritable incident. Sans contexte, les équipes ignorent les alertes ou, au contraire, les corrigent de manière excessive.
Les scanners traditionnels échouent souvent à détecter les attaques ReDoS car ils n'évaluent pas le comportement des expressions régulières lors de l'exécution ou dans des conditions d'entrée malveillantes. C'est là que des plateformes comme Xygeni font la différence en combinant l'analyse avec évaluation des risques contextuels, aidant les équipes à comprendre si une faiblesse est réellement surmontable et a un impact.
Comment détecter les vulnérabilités ReDoS
Il est possible de détecter les attaques ReDoS grâce à une combinaison de rigueur dans la conception et de tests. De plus, il est important d'effectuer des contrôles en continu, et pas seulement lors d'un audit de sécurité.
Conception d'expressions régulières sécurisées
Privilégiez les modèles qui minimisent l'ambiguïté. Évitez les quantificateurs imbriqués et les alternatives qui se chevauchent.
Fuzzing et tests
Tester les modèles d'expressions régulières avec :
- Entrées très longues.
- Entrées quasi-faillite qui échouent tardivement.
- Jetons répétés conçus pour déclencher un retour en arrière.
Analyse statique
Utilisez une analyse qui signale les constructions et les schémas à risque connus, alignés sur CWE-1333.
Validation d'exécution
Appliquez des limites de longueur d'entrée et des délais d'expiration autour de l'évaluation des expressions régulières lorsque cela est possible. Guide de validation des entrées d'OWASPe met explicitement en garde contre les attaques ReDoS et souligne l'importance de définir une longueur d'entrée minimale et maximale.
Les solutions AppSec avancées telles que Xygeni vont au-delà de la simple détection de modèles. analyser le code dans le contexte du flux de travail et en aidant les équipes à se concentrer sur les problèmes les plus susceptibles d'avoir une incidence dans des scénarios réels, ce qui réduit les faux positifs et accélère la résolution des problèmes.
Comment prévenir les attaques ReDoS
La prévention repose sur une combinaison de comportements plus sûrs, d'entrées plus sûres et de choix d'exécution plus sûrs.
Évitez les quantificateurs imbriqués
Les répétitions imbriquées sont souvent à l'origine des pires explosions de retour en arrière.
Limiter la taille de l'entrée
Il s'agit de la solution la plus simple et la plus fiable : définir des limites de longueur maximales pour les entrées soumises à la validation par expression régulière. OWASP souligne l'importance de ces limites pour une validation sécurisée des entrées.
Utilisez des moteurs d'expressions régulières sûrs lorsque cela est possible.
Lorsque vous avez le choix du moteur, privilégiez un modèle conçu pour éviter les retours en arrière catastrophiques. RE2 de Google se positionne comme une alternative sûre aux moteurs d'expressions régulières avec retour arrière.
Validez les entrées à l'aide de contrôles à plusieurs niveaux.
Ne vous fiez pas à une seule expression régulière pour toutes les validations. Combinez :
- listes de caractères autorisés,
- contrôles stricts de longueur,
- et des motifs plus simples par champ.
La prévention des attaques ReDoS nécessite des pratiques de codage sécurisées et validation continue tout au long du cycle de développement, notamment à mesure que les applications prennent de l'ampleur et que les dépendances se multiplient.
Comment Xygeni aide à détecter et à prévenir les attaques ReDoS
Xygeni aide les équipes DevSecOps à détecter et à prévenir les vulnérabilités ReDoS en combinant plusieurs niveaux d'analyse.
Les fonctionnalités clés incluent :
- Détection des modèles d'expressions régulières vulnérables pendant le développement
- Analyse des flux de données et des chemins d'exécution
- Identification des vulnérabilités exploitables, et pas seulement théoriques.
- Intégration dans CI/CD pipelines pour la numérisation continue
- Conseils pratiques pour les développeurs en matière de correction des problèmes
Au lieu de submerger les équipes d'alertes, Xygeni privilégie les vulnérabilités qui sont réellement accessibles et impactant.
Cela permet aux équipes de corriger plus rapidement les problèmes réels, sans ralentir le développement.
Meilleures pratiques pour les équipes DevSecOps
Sécurité Shift-gauche
Intégrez les vérifications ReDoS à la même routine que la revue de code et les tests unitaires.
Automatiser la numérisation
Effectuez des vérifications sur chaque pull request Le risque lié aux expressions régulières ne dépend donc pas des examens périodiques.
Surveiller les dépendances
Les vulnérabilités liées aux expressions régulières apparaissent également dans les dépendances et les bibliothèques d'analyse syntaxique des entrées ; il est donc essentiel de maintenir une hygiène rigoureuse des dépendances.
Valider les entrées en continu
Appliquez des limites de longueur et des règles de saisie aux limites, puis validez à nouveau au sein des services critiques.
En intégrant la sécurité directement dans les flux de travail de développement, les équipes peuvent prévenir les vulnérabilités liées aux performances, comme les attaques ReDoS, avant qu'elles n'atteignent la production.
La prévention des attaques ReDoS commence par une visibilité sans faille
Les attaques ReDoS sont souvent négligées, pourtant elles peuvent avoir un impact considérable sur les performances et la disponibilité des applications. L'OWASP les définit comme un risque de déni de service lié à un comportement extrême des expressions régulières lors de l'exécution.
Cela signifie qu'il vous faut plus qu'une simple analyse. Il vous faut du contexte, une priorisation et une automatisation.
Si vous considérez les expressions régulières comme du code susceptible de dysfonctionner face à des entrées contrôlées par un attaquant, vous détecterez plus tôt les attaques ReDoS et déploierez des systèmes plus sûrs. Avec Xygeni, les équipes peuvent réduire le bruit, prioriser les risques réels et renforcer les contrôles de sécurité applicative en interne. CI/CD workflows.
Conclusion
Les vulnérabilités ReDoS sont faciles à introduire et difficiles à détecter sans le contexte approprié.
Alors que les outils traditionnels se concentrent sur l'identification des problèmes, la sécurité des applications modernes exige de comprendre quelles vulnérabilités sont réellement importantes.
Par conséquent, pour garder une longueur d'avance, les équipes ont besoin de visibilité, de priorisation et d'automatisation fonctionnant de concert tout au long du cycle de développement.
C’est là que Xygeni fait la différence. En se concentrant sur les risques exploitables, il aide les équipes à détecter les problèmes plus tôt, à réduire le bruit et à sécuriser les applications du développement au déploiement.
En définitive, concevoir aujourd'hui des logiciels sécurisés implique d'aller au-delà de la simple analyse et d'adopter une approche contextuelle et en temps réel de la sécurité.
Commencez à créer des applications sécurisées et résilientes avec Détection en temps réel et sécurité contextuelle.
Foire Aux Questions (FAQ)
Qu'est-ce qu'une attaque ReDoS ?
Une attaque ReDoS (Regular Expression Denial of Service) est un type de vulnérabilité où des modèles d'expressions régulières inefficaces peuvent être exploités pour provoquer un temps de traitement excessif, entraînant une dégradation des performances ou des plantages d'application.
Pourquoi les attaques ReDoS sont-elles dangereuses dans les applications modernes ?
Les attaques ReDoS peuvent impacter la disponibilité des applications en consommant des ressources CPU et en ralentissant les services. Dans les environnements cloud natifs, cela peut rapidement dégénérer en problèmes de performance à l'échelle du système.
Comment les développeurs peuvent-ils prévenir les vulnérabilités ReDoS ?
Les développeurs peuvent prévenir les attaques ReDoS en évitant les expressions régulières complexes, en limitant la taille des entrées, en utilisant des moteurs d'expressions régulières sécurisés et en intégrant des contrôles de sécurité. CI/CD pipelines.
Les outils de sécurité traditionnels peuvent-ils détecter les attaques par déni de service (ReDoS) ?
La plupart des outils traditionnels peinent à détecter les attaques ReDoS car ils n'analysent ni le comportement du code lors de son exécution, ni son exploitabilité. Les solutions AppSec avancées offrent une meilleure détection en évaluant la manière dont le code s'exécute dans des scénarios réels.
Comment Xygeni contribue-t-il à prévenir les attaques ReDoS ?
Xygeni détecte les modèles d'expressions régulières vulnérables, analyse les chemins d'exécution et hiérarchise les risques exploitables. Il s'intègre à CI/CD pipelineet fournit aux développeurs des conseils pratiques en matière de correction.
À propos de l’auteur
Cofondateur et directeur technique
Fatima Said se spécialise dans le contenu destiné aux développeurs pour la sécurité des applications, le DevSecOps et software supply chain securityElle transforme des signaux de sécurité complexes en indications claires et exploitables qui aident les équipes à prioriser plus rapidement, à réduire le bruit et à livrer un code plus sûr.
