Quand les expressions régulières se retournent contre les performances
Une simple ligne d'expression régulière en C# peut paralyser une API en production. Des expressions mal conçues peuvent provoquer des retours en arrière catastrophiques, une consommation excessive de ressources CPU et le blocage de threads. C'est le cas classique. Déni de service par expression régulière (ReDoS), un vecteur d'attaque subtil mais dangereux caché dans votre code.
⚠️Exemple non sécurisé, à des fins pédagogiques uniquement. Ne pas utiliser en production.
string pattern = @"(a+)+$"; // Vulnerable regex c#
Regex regex = new Regex(pattern);
bool isMatch = regex.IsMatch("aaaaaaaaaaaaaaaaaaaaaaaa!");
Cette expression régulière pour C# souffre de quantificateurs imbriqués qui provoquent un retour arrière exponentiel. Une longue chaîne malveillante peut bloquer un point de terminaison ou un microservice.
Version sécurisée :
string pattern = @"^a+$"; // Safe simplified regex for C#
Regex regex = new Regex(pattern, RegexOptions.Compiled, TimeSpan.FromMilliseconds(200));
bool isMatch = regex.IsMatch("aaaaaaaaaaa");
Note pédagogique : Utilisez toujours des délais d'attente (Options d'expression régulière + Duréeet simplifier les groupes imbriqués. En C# avec expressions régulières, la validation des performances est une exigence de sécurité, et non une optimisation.
Pourquoi les expressions régulières en C# deviennent-elles vulnérables ?
Quantificateurs ambigus (.*, .+, ou (a+)+) et la répétition illimitée font des expressions régulières une cible fréquente des attaques par déni de service (DoS).
Lorsque ces éléments apparaissent dans des contextes pilotés par l'utilisateur, comme la validation des entrées ou l'analyse des journaux, une seule charge utile spécialement conçue peut monopoliser le processeur.
⚠️Exemple non sécurisé, à des fins pédagogiques uniquement. Ne pas utiliser en production.
// Vulnerable email validation regex for C#
var pattern = @"^([a-zA-Z0-9_\-\.]+)@([\w\-]+\.)+([a-zA-Z]{2,4})$";
var input = "a".PadLeft(10000, 'a') + "@example.com";
Regex.IsMatch(input, pattern); // May hang or cause ReDoS
Version sécurisée :
// Safer regex c# pattern
var pattern = @"^[^@\s]+@[^@\s]+\.[^@\s]+$";
Regex regex = new Regex(pattern, RegexOptions.Compiled, TimeSpan.FromMilliseconds(300));
bool isValid = regex.IsMatch("user@example.com");
Note pédagogique : Évitez les répétitions ambiguës, limitez la taille des entrées et évaluez toujours les performances des expressions régulières en situation de charge. Extrait de code fonctionnel : imposer des délais d’attente et une longueur maximale d’entrée comme gardes en production.
Impact réel dans les API et CI/CD Les flux de travail
Les expressions régulières non sécurisées en C# ne se limitent pas aux formulaires de validation. Les développeurs intègrent des modèles dans les filtres de journalisation, les correspondances de webhooks et les analyses automatisées. CI/CDUn seul schéma non sécurisé peut bloquer l'ensemble du processus. pipeline.
⚠️Exemple non sécurisé, à des fins pédagogiques uniquement. Ne pas utiliser en production.
// Regex used to match commit messages in a CI job
var regex = new Regex(userInputPattern);
if (regex.IsMatch(commitMessage)) { /* process */ }
If userInputPattern contains (a+)+$, it can freeze the build agent.Ne jamais traiter une expression régulière fournie par l'utilisateur sans validation ni contrôle de délai d'expiration.
Version sécurisée :
// Safe usage in CI/CD context
if (userInputPattern.Length < 100 && !userInputPattern.Contains("++"))
{
Regex regex = new Regex(userInputPattern, RegexOptions.Compiled, TimeSpan.FromMilliseconds(100));
if (regex.IsMatch(commitMessage)) { /* safely process */ }
}
Note pédagogique : Validez les entrées d'expressions régulières externes avant leur exécution. Ajoutez des vérifications de longueur explicites et imposez des délais d'expiration. pipelines.
Bonnes pratiques pour prévenir les attaques par déni de service (DoS) avec les expressions régulières en C#
La prévention des attaques ReDoS dans les expressions régulières C# doit être intégrée à votre processus de développement et Flux de travail DevSecOps. Voici comment le rendre sûr par défaut :
Pratiques d'excellence
- Définissez toujours des délais d'expiration. sur toutes les évaluations d'expressions régulières.
- Évitez les schémas catastrophiques, pas de quantificateurs imbriqués ni de groupes ambigus.
- Limiter la taille de l'entrée avant de passer à l'expression régulière.
- Précompiler des modèles de confiance au Options d'expressions régulières.Compilé.
- Nettoyer les expressions fournies par l'utilisateur ou autoriser les modèles sur une liste blanche.
Mini liste de contrôle préventive
- Vérifiez chaque expression régulière utilisée en C# dans votre code source.
- Appliquer Durée Délais d'attente dépassés de manière constante.
- Limiter la longueur des entrées pour les API et les CI.
- Tester les performances des expressions régulières avant la publication.
- Automatisation des expressions régulières statiques numérisation CI/CD.
Note pédagogique : Considérez les expressions régulières comme du code non fiable. Elles méritent le même examen minutieux que les requêtes SQL ou l'exécution de commandes.
Comment Xygeni détecte l'utilisation risquée des expressions régulières en C#
Xygéni Code Security Détecte automatiquement les modèles C# regex non sécurisés lors de l'analyse statique. Il identifie les retours en arrière catastrophiques, les délais d'attente non respectés et les schémas susceptibles de bloquer les services. In CI/CD, Xygéni agit comme un Porte DevSecOps, en bloquant les expressions régulières non sécurisées pour C# avant leur fusion ou leur déploiement.
# Never expose real tokens, credentials, or internal URLs in pipelines
- name: Regex Safety Scan
run: dotnet xygeni validate --rules regex ,performance --fail-on-riskNote pédagogique : L'intégration de Xygeni garantit une gestion sécurisée des expressions régulières dans toutes les versions et tous les environnements, empêchant ainsi les régressions et les attaques par déni de service avant le déploiement.
Votre expression régulière est puissante, assurez-vous qu'elle ne soit pas utilisée à des fins malveillantes.
Les vulnérabilités ReDoS transforment des expressions régulières C# d'apparence innocente en une arme de déni de service. L'utilisation d'expressions régulières non sécurisées dans les modèles C# est une négligence courante, jusqu'à ce qu'elles bloquent la production ou provoquent des dysfonctionnements. CI/CD.
Intégrez la sécurité des expressions régulières à vos bonnes pratiques de programmation :
- Utilisez toujours des délais d'attente.
- Évitez les quantificateurs imbriqués.
- Limiter la saisie de l'utilisateur.
- Automatisez les contrôles à l'aide de Xygeni Code Security.
Les expressions régulières resteront toujours puissantes, mais avec une conception soignée, vos modèles C# d'expressions régulières ne deviendront pas votre prochain rapport d'incident.
