Règles Semgrep Csharp¶

csharp_deserialization_rule-InsecureDeserialization¶

Résumé :

Désérialisation de données potentiellement non fiables

Sévérité : Élevée

Description :

L'application utilise une désérialisation .NET non sécurisée à travers des formateurs tels que BinaryFormatter.Deserialize(), SoapFormatter.Deserialize(), NetDataContractSerializer.Deserialize(), ou LosFormatter.Deserialize() avec des données provenant de sources non fiables, telles que des requêtes HTTP, des fichiers ou des variables d'environnement. Ces formateurs .NET hérités peuvent instancier des types arbitraires lors de la désérialisation et exécuter du code via des constructeurs de type, des setters de propriété, ou des rappels de sérialisation, permettant aux attaquants d'obtenir une exécution de code à distance en fournissant des payloads sérialisés spécialement conçus. Microsoft a officiellement déprécié BinaryFormatter et les formateurs associés en raison de vulnérabilités de sécurité irrémédiables, et des outils d'exploitation automatisés comme ysoserial.net peuvent générer des exploits fonctionnels pour ces vulnérabilités de désérialisation avec un minimum d'effort. L'injection d'objets à travers ces formateurs peut également permettre des attaques de masse où des propriétés inattendues sont définies sur des objets, contournant des contrôles de sécurité ou modifiant l'état de l'application.

Remédiation :

Envisagez de migrer loin des formateurs .NET hérités vers des alternatives plus sûres qui ne supportent pas l'instanciation de types arbitraires. Utilisez System.Text.Json avec JsonSerializer pour la sérialisation JSON, qui est l'approche recommandée pour les nouvelles applications .NET et fournit une sécurité intégrée grâce à un traitement restreint des types. Pour les applications nécessitant une sérialisation binaire, envisagez les Protocol Buffers (protobuf-net), MessagePack (MessagePack-CSharp), ou Bond, qui utilisent tous une sérialisation basée sur des schémas sans risques d'exécution de code. Si vous devez désérialiser des types complexes, utilisez DataContractSerializer ou DataContractJsonSerializer avec des types connus configurés explicitement via DataContractSerializer.KnownTypes ou ajoutez des types de manière sélective à l'aide du paramètre knownTypes. Lorsque vous utilisez JSON.NET (Newtonsoft.Json), réglez TypeNameHandling sur TypeNameHandling.None pour empêcher le traitement des informations de type lors de la désérialisation. Ne désérialisez jamais vers des types de base comme Object ou dynamique, et effectuez toujours une conversion vers des types spécifiques attendus après validation. Implémentez des listes de contrôle des types autorisés si une désérialisation personnalisée est requise, et envisagez d'utiliser SerializationBinder pour contrôler la résolution des types. Appliquez le principe du moindre privilège en exécutant des opérations de désérialisation avec des permissions minimales. Pour plus d'informations, voir le guide de sécurité de BinaryFormatter de Microsoft à https://learn.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-security-guide et la feuille de triche sur la désérialisation d'OWASP à https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html

OWASP :

A8:2017-Désérialisation non sécurisée
A08:2021-Failles d'intégrité des logiciels et des données

csharp_deserialization_rule-InsecureDeserializationNewtonsoft¶

Résumé :

Désérialisation de données potentiellement non fiables

Sévérité : Élevée

CWE : CWE-502

Description :

Les attaques par désérialisation exploitent le processus de lecture de données sérialisées et leur conversion en un objet. En construisant des objets malveillants et en les sérialisant, un adversaire peut tenter de :

Injecter du code qui est exécuté lors de la construction de l'objet, ce qui se produit durant le processus de désérialisation.
Exploiter l'attribution massive en incluant des champs qui ne font normalement pas partie des données sérialisées mais qui sont lus lors de la désérialisation.

Lors de l'utilisation de la désérialisation Newtonsoft, vous devez vous assurer que la propriété TypeNameHandling est définie sur None ou utiliser ISerializationBinder pour restreindre les types pouvant être désérialisés.

OWASP :

A8:2017-Désérialisation Non Sécurisée
A08:2021-Échecs d'Intégrité des Logiciels et des Données

csharp_injection_rule-CommandInjection¶

Résumé :

Neutralisation incorrecte des éléments spéciaux utilisés dans une commande système ('Injection de commande OS')

Gravité : Élevée

CWE : CWE-78

Description :

L'application utilise System.Diagnostics.Process.Start() ou ProcessStartInfo avec des commandes construites dynamiquement, ce qui peut conduire à une injection de commande OS. Cette vulnérabilité critique permet aux adversaires de passer des commandes ou des arguments arbitraires à exécuter avec les privilèges de l'application, ce qui peut mener à une compromission totale du système. Lorsque les entrées utilisateur pénètrent dans ProcessStartInfo.FileName, ProcessStartInfo.Arguments ou Process.Start() sans validation appropriée, les attaquants peuvent injecter des métacaractères de shell ou modifier le flux d'exécution de la commande prévue.

Remédiation :

Envisagez de remplacer l'exécution de commandes OS par des bibliothèques .NET natives qui mettent en œuvre la même fonctionnalité, car cela élimine entièrement le risque d'injection de commande. Si des commandes OS doivent être exécutées, il est recommandé d'utiliser une liste d'autorisation codée en dur des chemins et arguments exécutables, sans jamais permettre à l'entrée utilisateur d'influencer le nom du processus ou la structure de la commande. Lors du passage de données aux commandes, envisagez d'utiliser des références indirectes telles que la génération d'un nom de fichier aléatoire avec Guid.NewGuid() ou l'utilisation d'une table de recherche où l'entrée utilisateur fournit une clé plutôt que la valeur réelle. Assurez-vous toujours de définir ProcessStartInfo.UseShellExecute à false pour prévenir l'interprétation des métacaractères par le shell. Assurez-vous d'utiliser des chemins absolus complets pour FileName (par exemple, "C:\App\Tool.exe") afin de prévenir les vulnérabilités liées aux chemins de recherche non fiables (CWE-426). Pour plus d'informations, consultez la feuille de triche OWASP sur la défense contre l'injection de commandes OS à l'adresse suivante : https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html

OWASP :

A1:2017-Injection
A03:2021-Injection

csharp_other_rule-UnsafeXSLTSettingUsed¶

Résumé :

Injection XML (également appelée injection XPath aveugle)

Gravité : Élevée

CWE : CWE-91

Description :

XsltSettings détecté avec EnableScript ou EnableDocumentFunction défini sur vrai. Ces paramètres permettent l'exécution de code au sein des feuilles de style XSL, permettant aux adversaires qui peuvent influencer le document XSL chargé d'injecter et d'exécuter directement du code malveillant. Cela peut conduire à un compromis complet du système par l'exécution de code arbitraire.

Remédiation :

Envisagez de définir XsltSettings.EnableScript et XsltSettings.EnableDocumentFunction sur faux pour prévenir l'exécution de code au sein des feuilles de style XSL. Il est recommandé de ne jamais traiter les feuilles de style XSL fournies par les utilisateurs. Si l'application doit calculer des valeurs à partir d'une entrée XML, envisagez de modifier le document XML avant d'exécuter XslCompiledTransform.Transform() au lieu d'utiliser des scripts XSL pour exécuter des fonctions.

OWASP :

A1:2017-Injection
A03:2021-Injection

csharp_crypto_rule-CertificateValidationDisabled¶

Résumé :

Validation des certificats désactivée

Gravité : Moyenne

CWE : CWE-295

Description :

L'événement ServicePointManager.ServerCertificateValidationCallback a été configuré pour toujours retourner true, ce qui désactive effectivement la validation des certificats du serveur. Cela permet à un adversaire positionné entre l'application et l'hôte cible d'intercepter des informations potentiellement sensibles ou de transmettre des données malveillantes via des attaques de type homme du milieu. Lorsque la validation des certificats est désactivée, l'application ne peut pas vérifier l'identité du serveur avec lequel elle communique, la rendant vulnérable aux attaques par usurpation d'identité.

Remédiation :

Envisagez de supprimer la fonction de rappel qui retourne inconditionnellement true pour permettre la validation normale des certificats. Lorsqu'aucun rappel n'est fourni, le framework .NET validera que le nom du certificat correspond au nom d'hôte utilisé lors de la création de la demande, et que la chaîne de certificats est de confiance. Si une validation de certificat personnalisée est nécessaire pour des scénarios spécifiques (comme accepter des certificats auto-signés dans des environnements de développement), mettez en œuvre une logique de validation appropriée qui vérifie les propriétés du certificat telles que l'émetteur, le sujet et la date d'expiration plutôt que d'accepter aveuglément tous les certificats. Pour les environnements de production, assurez-vous que seuls les certificats signés par des autorités de certification de confiance sont acceptés. Des conseils supplémentaires sont disponibles à : system.net.servicepointmanager.servercertificatevalidationcallback

OWASP :

A2:2017-Authentification brisée
A07:2021-Défauts d'identification et d'authentification

csharp_crypto_rule-WeakCipherAlgorithm¶

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Gravité : Moyenne

CWE : CWE-327

Description :

L'application utilise des algorithmes cryptographiques faibles via les classes DESCryptoServiceProvider, TripleDESCryptoServiceProvider ou RC2CryptoServiceProvider, ou leurs méthodes de fabrication. DES utilise une clé de 56 bits qui peut être brute-forcée avec des ressources informatiques modernes, tandis que TripleDES (3DES) est obsolète en raison de sa petite taille de bloc de 64 bits, le rendant vulnérable aux attaques birthday sweet32 après le traitement de grandes quantités de données. RC2 souffre également d'une petite taille de clé efficace et présente des faiblesses cryptanalytiques connues. Ces algorithmes ne devraient pas être utilisés pour protéger des données sensibles dans des applications modernes.

Remédiation :

Envisagez de migrer vers ChaCha20Poly1305 pour .NET 6.0 et ultérieur, car il fournit un chiffrement authentifié qui est plus rapide et plus facile à utiliser correctement que des alternatives comme AesGcm. ChaCha20Poly1305 élimine le besoin de configuration manuelle du mode de chiffrement et offre une authentification de message intégrée. Pour les applications ciblant des versions plus anciennes du .NET Framework, AesGcm (AES-256-GCM) est recommandé, bien qu'il nécessite une gestion soigneuse des nonces, car la réutilisation des nonces entraîne des échecs de sécurité catastrophiques. Les deux alternatives nécessitent la génération de clés et de nonces aléatoires cryptographiquement sécurisées en utilisant RandomNumberGenerator.Fill() plutôt que des générateurs de nombres aléatoires plus faibles. Lors de la migration de code hérité, assurez-vous que les données chiffrées existantes sont correctement migrées ou que l'application maintient la compatibilité descendante pour le déchiffrement tout en chiffrant de nouvelles données avec l'algorithme plus robuste.

OWASP :

A3:2017-Exposition des données sensibles
A02:2021-Failles cryptographiques

csharp_crypto_rule-WeakCipherMode¶

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Gravité : Moyenne

CWE : CWE-327

Description :

L'application configure des opérations cryptographiques en utilisant des paramètres CipherMode faibles (ECB, CBC, OFB, CFB ou CTS) qui ne fournissent pas de chiffrement authentifié. Sans intégrité de message intégrée, un adversaire peut potentiellement altérer le texte chiffré pour manipuler le texte en clair résultant ou effectuer des attaques par oracle de remplissage, en particulier contre le mode CBC. Le mode ECB est particulièrement problématique, car il chiffre des blocs de texte en clair identiques en blocs de texte chiffré identiques, révélant des motifs dans les données chiffrées. Ces modes de chiffrement obligent les développeurs à implémenter manuellement l'authentification des messages, ce qui est sujet à erreurs et souvent mal réalisé.

Remédiation :

Envisagez de migrer vers des algorithmes de chiffrement authentifié qui offrent une intégrité de message intégrée plutôt que de configurer manuellement CipherMode. Pour .NET 6.0 et versions ultérieures, ChaCha20Poly1305 est recommandé car il combine le chiffrement et l'authentification en une seule opération qui est à la fois plus rapide et plus facile à utiliser correctement que les alternatives plus anciennes. Pour les applications sur des versions plus anciennes de .NET Framework, AesGcm fournit un chiffrement authentifié AES-256-GCM, bien qu'il nécessite une gestion soigneuse des nonces, car la réutilisation d'une nonce avec la même clé entraîne des échecs de sécurité catastrophiques. Les deux alternatives éliminent le besoin d'implémenter séparément HMAC ou d'autres codes d'authentification de messages. Lors de la migration à partir de CBC ou d'autres modes, assurez-vous que les nonces sont générées en utilisant RandomNumberGenerator.Fill() et stockées avec le texte chiffré pour le déchiffrement.

OWASP :

A3:2017-Exposition de données sensibles
A02:2021-Failles cryptographiques

csharp_crypto_rule-FonctionDeHachageFaible¶

Résumé :

Utilisation d'un algorithme cryptographique brisé ou risqué (SHA1/MD5)

Sévérité : Moyenne

CWE : CWE-327

Description :

L'application utilise des algorithmes de hachage cryptographiquement brisés via MD5CryptoServiceProvider, SHA1CryptoServiceProvider, ou leurs méthodes de fabrique comme System.Security.Cryptography.MD5.Create() et System.Security.Cryptography.SHA1.Create(). MD5 est gravement compromis avec des attaques de collision pratiques démontrées depuis 2004, tandis que les attaques de collision SHA1 sont devenues pratiques en 2017. Les deux algorithmes ne devraient jamais être utilisés à des fins de sécurité, y compris le stockage de mots de passe, les signatures numériques, la génération de certificats, ou la vérification d'intégrité. Un attaquant peut créer deux entrées différentes qui produisent la même sortie de hachage, permettant des falsifications et des attaques de contournement d'intégrité.

Remédiation :

Envisagez de migrer vers des fonctions cryptographiques spécifiques plutôt que des algorithmes de hachage à usage général. Pour le stockage de mots de passe, utilisez Rfc2898DeriveBytes (PBKDF2) avec un nombre d'itérations élevé (au moins 600 000 itérations pour HMAC-SHA1, ou 210 000 pour HMAC-SHA256/SHA512) plutôt que de hacher directement les mots de passe. PBKDF2 applique un salage et un étirement de clé pour résister aux attaques par force brute. Pour le hachage cryptographique à usage général, utilisez SHA-256 ou SHA-512 du espace de noms System.Security.Cryptography. Lors de la comparaison des valeurs de hachage, utilisez CryptographicOperations.FixedTimeEquals() pour prévenir les attaques temporelles qui pourraient divulguer des informations sur la valeur de hachage. Notez que bien que des implémentations vérifiées de Argon2id puissent devenir disponibles à l'avenir, PBKDF2 reste un choix sécurisé lorsqu'il est configuré avec des paramètres appropriés. Des conseils supplémentaires sont disponibles à l'adresse https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

OWASP :

A3:2017-Exposition de données sensibles
A02:2021-Faiblesses cryptographiques

csharp_crypto_rule-WeakRNG¶

Résumé :

Utilisation d'un générateur de nombres pseudo-aléatoires (PRNG) cryptographiquement faible

Gravité : Moyenne

CWE : CWE-338

Description :

L'application utilise la classe Random pour générer des valeurs aléatoires, qui est un générateur de nombres pseudo-aléatoires (PRNG) adapté uniquement à des fins non sécuritaires comme les jeux ou les simulations. La classe Random utilise un algorithme déterministe initialisé avec l'horloge système, rendant sa sortie prévisible si un attaquant peut deviner la valeur de la graine. Lorsque ces valeurs prévisibles sont utilisées pour des opérations sensibles à la sécurité comme la génération de clés cryptographiques, de vecteurs d'initialisation, de nonces, de jetons de session ou de jetons de réinitialisation de mot de passe, un attaquant peut être en mesure de prédire de futures valeurs et de compromettre la sécurité de l'application.

Remédiation :

Envisagez d'utiliser RandomNumberGenerator de System.Security.Cryptography pour toute génération de valeurs aléatoires sensibles à la sécurité. La classe RandomNumberGenerator fournit des nombres aléatoires cryptographiquement sécurisés en utilisant des sources d'entropie du système d'exploitation qui sont adaptées à la génération de clés cryptographiques, de nonces, de jetons et d'autres valeurs critiques pour la sécurité. Pour générer des entiers aléatoires, utilisez RandomNumberGenerator.GetInt32(), et pour des tableaux de bytes aléatoires, utilisez RandomNumberGenerator.Fill() pour remplir un tampon pré-alloué. Ces méthodes sont thread-safe et ne nécessitent pas d'instanciation ou de nettoyage. Réservez la classe Random exclusivement à des fins non sécuritaires où la prévisibilité est acceptable, comme la génération de contenu procédural ou la randomisation du gameplay. Documentation supplémentaire disponible à : system.security.cryptography.randomnumbergenerator

OWASP :

A3:2017-Exposition de données sensibles
A02:2021-Échecs cryptographiques

csharp_csrf_rule-Csrf¶

Résumé :

Potentiel Cross-Site Request Forgery (CSRF)

Gravité : Moyenne

CWE : CWE-352

Description :

Gestionnaire de méthode HTTP détecté ([HttpPost], [HttpPut], [HttpDelete] ou [HttpPatch]) sans l'attribut [ValidateAntiForgeryToken]. Cela permet des attaques de Cross-Site Request Forgery (CSRF) où des sites malveillants peuvent tromper des utilisateurs authentifiés en réalisant des actions non désirées qui modifient l'état. Les attaquants peuvent exploiter cela en créant des formulaires ou des liens qui soumettent des requêtes avec les informations d'identification de session de la victime.

Remédiation :

Envisagez d'ajouter l'attribut [ValidateAntiForgeryToken] à toutes les méthodes d'action qui traitent des opérations modifiant l'état (POST, PUT, DELETE, PATCH). Cela valide que les requêtes incluent un token anti-forgery valide, empêchant ainsi les attaques CSRF. Alternativement, activez [AutoValidateAntiforgeryTokenAttribute] globalement pour protéger automatiquement tous les points de terminaison modifiant l'état. Pour une défense en profondeur, envisagez également de configurer les cookies de session avec l'attribut SameSite pour restreindre la soumission de requêtes intersites.

OWASP :

A5:2017-Contrôle d'accès défaillant
A01:2021-Contrôle d'accès défaillant

csharp_injection_rule-LdapInjection¶

Résumé :

Neutralisation inadéquate des éléments spéciaux utilisés dans une requête LDAP ('Injection LDAP')

Gravité : Moyenne

CWE : CWE-90

Description :

L'application utilise System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(), DirectoryEntry, DirectorySearcher ou SearchRequest avec des entrées contaminées provenant des paramètres de méthode. Les attaques par injection LDAP exploitent des données contrôlées par l'utilisateur dans les requêtes LDAP pour manipuler la manière dont les données sont retournées des serveurs LDAP ou Active Directory. Même l'API AccountManagement moderne reste vulnérable lorsque les entrées utilisateur contiennent des métacaractères de filtre LDAP tels que *, (, ) ou des octets nuls, ce qui peut altérer la logique des requêtes et potentiellement contourner l'authentification ou accéder à des informations de répertoire non autorisées.

Remédiation :

Envisagez de mettre en œuvre une fonction d'encodage LDAP qui échappe aux caractères spéciaux avant de passer les entrées utilisateur à n'importe quelle méthode de requête LDAP. Il est recommandé d'encoder d'abord le caractère de barre oblique inversée (comme "\5c"), suivi du nul ("\00"), de la parenthèse ouvrante ("\28"), de la parenthèse fermante ("\29") et de l'astérisque ("\2a") pour empêcher l'injection de filtre. Cet encodage s'applique à la fois à l'API moderne System.DirectoryServices.AccountManagement et à l'ancienne API DirectorySearcher. Lors de l'utilisation de UserPrincipal, appliquez l'encodage avant de définir des propriétés comme SamAccountName ou DisplayName qui seront utilisées dans les opérations de recherche. Pour DirectorySearcher.Filter ou SearchRequest.Filter, encodez toutes les portions contrôlées par l'utilisateur de la chaîne de filtre LDAP. Envisagez d'utiliser FindOne() au lieu de FindAll() lorsque cela est approprié pour limiter les ensembles de résultats et réduire l'exposition des informations. Pour plus d'informations, consultez la feuille de triche d'OWASP sur la prévention de l'injection LDAP à l'adresse https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html

OWASP :

A1:2017-Injection
A03:2021-Injection

csharp_injection_rule-SQLInjection¶

Résumé :

Neutralisation incorrecte des éléments spéciaux utilisés dans une commande SQL ('Injection SQL')

Gravité : Moyenne

CWE : CWE-89

Description :

L'application utilise des méthodes de l'Entity Framework telles que ExecuteSqlRaw(), ExecuteSqlCommand(), FromSqlRaw(), ou des objets de commande de base de données comme SqlCommand, OracleCommand, MySqlCommand, ou NpgsqlCommand avec des requêtes SQL construites dynamiquement. L'injection SQL permet aux adversaires d'influencer la logique des instructions SQL en manipulant l'entrée utilisateur qui passe dans les chaînes de requête. Cette vulnérabilité critique peut entraîner un accès non autorisé aux données, une modification des données, un contournement d'authentification, et dans certains cas l'exécution de commandes du système d'exploitation via des fonctionnalités du serveur de base de données comme xp_cmdshell dans SQL Server.

Remédiation :

Envisagez d'utiliser exclusivement des requêtes paramétrées pour toutes les opérations sur la base de données, où l'entrée utilisateur est transmise en tant que paramètres plutôt que concaténée dans des chaînes SQL. Pour SqlCommand et des classes similaires, utilisez la méthode Parameters.Add() avec des types SQL explicites tels que SqlDbType.NVarChar pour lier en toute sécurité les valeurs utilisateur. Lors de l'utilisation de l'Entity Framework, préférez ExecuteSqlInterpolated() ou FromSqlInterpolated() qui paramètrent automatiquement les chaînes interpolées, ou utilisez ExecuteSqlRaw() avec des objets de paramètres explicites. Pour les scénarios nécessitant des noms de table ou de colonne dynamiques qui ne peuvent pas être paramétrés, il est recommandé d'utiliser une approche de liste blanche avec un dictionnaire mappant les clés fournies par l'utilisateur aux identifiants de base de données valides. Pour des opérateurs dynamiques comme > ou <, envisagez de faire fournir aux utilisateurs des valeurs symboliques comme "gt" ou "lt" qui sont ensuite mappées aux véritables opérateurs, plutôt que d'accepter directement les opérateurs. Évitez d'utiliser CommandType.Text avec des chaînes concaténées et ne faites jamais confiance à l'entrée utilisateur pour les identifiants de base de données. Pour plus d'informations, consultez la feuille de triche de prévention d'injection SQL de l'OWASP à https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

OWASP :

A1:2017-Injection
A03:2021-Injection

csharp_injection_rule-XPathInjection¶

Résumé :

Neutralisation incorrecte des données dans les expressions XPath ('Injection XPath')

Gravité : Moyenne

CWE : CWE-643

Description :

L'application utilise des méthodes de requête XPath telles que XPathNavigator.SelectNodes(), XmlDocument.SelectSingleNode(), XPathExpression.Compile(), ou des méthodes d'extension LINQ comme XPathEvaluate(), XPathSelectElement(), et XPathSelectElements() avec des expressions XPath construites dynamiquement. L'injection XPath permet aux adversaires de modifier la structure des requêtes XML en injectant des caractères spéciaux ou de la syntaxe XPath, pouvant potentiellement mener à une extraction non autorisée de données, à une divulgation d'informations, ou dans de rares cas, à un contournement de l'authentification lorsque XPath est utilisé pour des décisions de contrôle d'accès.

Remédiation :

Envisagez de migrer vers LINQ to XML (System.Xml.Linq) qui offre une requête sécurisée par type grâce à des méthodes comme Descendants(), Elements(), et Where() qui utilisent la comparaison de chaînes .NET plutôt que l'évaluation d'expressions XPath. Il est recommandé d'utiliser XDocument ou XElement avec des méthodes LINQ standard, où l'entrée utilisateur est traitée comme des données dans des prédicats de filtre plutôt que comme une partie de la structure de la requête. Évitez d'utiliser XPathEvaluate(), XPathSelectElement(), et XPathSelectElements() des méthodes d'extension de System.Xml.XPath même dans les requêtes LINQ, car celles-ci évaluent toujours des expressions XPath et restent vulnérables à l'injection. Si XPath doit être utilisé, envisagez de mettre en œuvre une liste blanche de motifs de requête valides et d'utiliser des approches paramétrées où l'entrée utilisateur n'influence que les valeurs de données, pas la structure de la requête. Notez que XDocument est également sûr contre les attaques XXE par défaut, car le résolveur est désactivé. Pour plus d'informations, consultez la documentation sur la sécurité de LINQ to XML de Microsoft à l'adresse https://learn.microsoft.com/en-us/dotnet/standard/linq/linq-xml-security et le guide de sécurité XML d'OWASP à l'adresse https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#net

OWASP :

A1:2017-Injection
A03:2021-Injection

csharp_injection_rule-XmlDocumentXXEInjection¶

Résumé :

Restriction incorrecte de la référence d'entité externe XML ('XXE')

Sévérité : Moyenne

CWE : CWE-611

Description :

L'application utilise System.Xml.XmlDocument pour charger ou analyser des données XML sans définir explicitement la propriété XmlResolver à null. Les attaques par entité externe XML (XXE) exploitent les analyseurs XML qui résolvent les références d'entités externes, permettant aux attaquants de lire des fichiers arbitraires depuis le système de fichiers du serveur, d'effectuer du Server-Side Request Forgery (SSRF) vers des ressources de réseau interne, d'exfiltrer des données sensibles vers des hôtes externes, ou de provoquer une déni de service par le biais d'attaques de billions de rires. Par défaut, XmlDocument.Load() et XmlDocument.LoadXml() dans les anciennes versions de .NET Framework activent la résolution d'entités externes, rendant les applications vulnérables lors du traitement d'entrées XML non fiables.

Remédiation :

Envisagez de migrer vers System.Xml.Linq.XDocument qui désactive la résolution des entités externes par défaut et fournit une API plus moderne et plus sûre pour le traitement XML avec protection intégrée contre les attaques XXE et DoS. Si XmlDocument doit être utilisé pour des raisons de compatibilité avec les versions précédentes, il est recommandé de définir explicitement XmlDocument.XmlResolver = null immédiatement après l'instantiation et avant d'appeler les méthodes Load() ou LoadXml(). Assurez-vous que votre application cible .NET Framework 4.5.2 ou une version ultérieure (publiée en 2014) qui fournit des paramètres par défaut plus sûrs, bien qu'une configuration explicite soit toujours recommandée pour une défense en profondeur. Pour les applications traitant des XML non fiables provenant de sources externes, envisagez de valider la structure et la taille du XML avant l'analyse pour prévenir les attaques d'épuisement des ressources. Évitez d'utiliser la syntaxe d'initialisation d'objet sans définir explicitement XmlResolver = null dans le bloc d'initialisation. Pour plus d'informations, consultez la feuille de triche OWASP sur la prévention des entités externes XML à l'adresse
https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#net

OWASP :

A1:2017-Injection
A03:2021-Injection

csharp_injection_rule-XmlReaderXXEInjection¶

Résumé :

Restriction incorrecte de la référence d'entité externe XML ('XXE')

Sévérité : Moyenne

CWE : CWE-611

Description :

L'application utilise System.Xml.XmlReader.Create() avec XmlReaderSettings configuré pour activer le traitement des DTD en définissant ProhibitDtd = false ou DtdProcessing = DtdProcessing.Parse. Cette configuration permet des attaques par entité externe XML (XXE) qui peuvent lire des fichiers arbitraires, effectuer une falsification de requête côté serveur (SSRF), exfiltrer des données ou provoquer des dénis de service par le biais d'attaques par expansion d'entité. Lorsque le traitement des DTD est activé, les attaquants peuvent inclure des déclarations d'entités externes malveillantes dans des documents XML qui font référence à des fichiers locaux ou des URL distantes, que le parseur tentera de résoudre lors du traitement du document.

Remédiation :

Envisagez de définir XmlReaderSettings.DtdProcessing sur DtdProcessing.Prohibit au lieu de DtdProcessing.Parse pour désactiver complètement le traitement des DTD et éviter les attaques XXE. Pour le code hérité utilisant la propriété obsolète ProhibitDtd, il est recommandé de la définir sur true pour bloquer le traitement des DTD, bien que la migration vers la propriété DtdProcessing soit préférée pour les applications modernes. Assurez-vous que votre application cible .NET Framework 4.5.2 ou ultérieure (publiée en 2014), qui fournit des paramètres par défaut de parsing XML plus sûrs. Si la validation du DTD est réellement nécessaire pour votre cas d'utilisation, envisagez d’utiliser DtdProcessing.Ignore qui saute le traitement des DTD mais permet au document de contenir une déclaration de DTD, bien que cela comporte toujours un certain risque. Pour une sécurité maximale lors du traitement de XML non fiable, il est également recommandé de définir XmlReaderSettings.XmlResolver = null pour empêcher la résolution de ressources externes même si le traitement des DTD est accidentellement activé. Pour plus d'informations, consultez la feuille de triche sur la prévention des entités externes XML de l'OWASP à l'adresse suivante :
https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#net

OWASP :

A1:2017-Injection
A03:2021-Injection

csharp_path_rule-PathTraversal¶

Résumé :

Limitation incorrecte d'un chemin d'accès à un répertoire restreint ('Traversée de chemin')

Gravité : Moyenne

CWE : CWE-22

Description :

L'application utilise des entrées utilisateur dans des opérations de fichiers System.IO telles que File.Open(), File.ReadAllText(), Directory.GetFiles(), ou d'autres méthodes du système de fichiers. Si les informations de chemin proviennent d'entrées utilisateur, les attaquants peuvent utiliser des séquences de traversée de chemin comme ../ pour accéder à des fichiers sensibles, lire les données d'autres utilisateurs ou obtenir un accès non autorisé au système.

Remédiation :

Évitez d'utiliser directement les entrées utilisateur dans les opérations de fichiers. Il est recommandé de remplacer les noms de fichiers fournis par l'utilisateur par des identifiants contrôlés tels que des GUID. Utilisez Path.GetFullPath() pour résoudre le chemin complet et le valider avec StartsWith() par rapport à un répertoire de base autorisé avant toute opération de fichier. Cela garantit que les chemins restent dans des répertoires restreints et empêche les attaques de traversée.

OWASP :

A5:2017-Contrôle d'accès rompu
A01:2021-Contrôle d'accès rompu

csharp_xss_rule-HtmlElementXss¶

Résumé :

Neutralisation inappropriée des données d'entrée lors de la génération de pages web ('Cross-site Scripting')

Sévérité : Moyenne

CWE : CWE-79

Description :

L'application écrit des données fournies par l'utilisateur à partir d'objets de requête ASP.NET (Request.Form, Request.QueryString, Request.Cookies, Request.Headers, etc.) directement dans la sortie HTML en utilisant des points de sortie dangereux comme HtmlHelper.Raw(), IHtmlHelper.Raw(), Response.Write(), ou les méthodes HtmlTextWriter (Write, WriteAttribute, AddAttribute, etc.). Cela crée une vulnérabilité de Cross-Site Scripting (XSS) où les attaquants peuvent injecter du JavaScript malveillant qui s'exécute dans les navigateurs des victimes. La règle détecte le flux de contamination des propriétés de requête ASP.NET vers les méthodes de rendu qui contournent l'encodage HTML automatique de Razor. Sans un encodage de sortie approprié, des scripts malveillants intégrés dans les paramètres de requête, les cookies ou les en-têtes seront rendus directement dans le HTML, ce qui pourrait mener à un détournement de session, au vol de données d'identification ou à des attaques de défiguration.

Remédiation :

Considérez l'utilisation de l'encodage HTML automatique de Razor en rendant les données utilisateur à travers la syntaxe standard Razor @Model.UserInput au lieu de @Html.Raw() ou Response.Write(). Pour les applications ASP.NET Core, utilisez System.Text.Encodings.Web.HtmlEncoder.Default.Encode() pour encoder manuellement l'entrée utilisateur si nécessaire. Si vous devez utiliser HtmlHelper.Raw(), assurez-vous que les données ont été assainies à l'aide d'un désinfectant HTML basé sur une liste blanche, comme le package NuGet HtmlSanitizer, avant de les transmettre. Pour les contextes JavaScript, utilisez JavaScriptEncoder.Default.Encode(), pour les URL utilisez UrlEncoder.Default.Encode(), et pour les attributs HTML utilisez HtmlEncoder.Default.Encode(). Implémentez des en-têtes de politique de sécurité de contenu (CSP) avec des directives restrictives en tant que défense en profondeur. Consultez les recommandations de Microsoft sur la prévention des XSS à l'adresse https://learn.microsoft.com/fr-fr/aspnet/core/security/cross-site-scripting pour des recommandations d'encodage spécifiques au contexte supplémentaires.

OWASP :

A1:2017-Injection
A03:2021-Injection

csharp_xss_rule-ScriptXss¶

Sévérité : Info

CWE : CWE-554

Description :

L'application utilise l'attribut [ValidateInput(false)] sur une méthode de contrôleur, ce qui désactive la validation des requêtes intégrée à ASP.NET. Cela empêche le cadre d'examiner les requêtes pour déceler des attaques par injection telles que le Cross-Site Scripting (XSS), laissant l'application vulnérable à des entrées malveillantes.

Remédiation :

Envisagez de supprimer l'attribut [ValidateInput(false)] pour réactiver la validation des requêtes ASP.NET, ou définissez-le explicitement sur true. Si la désactivation de la validation est inévitable pour des scénarios légitimes, il est recommandé de mettre en œuvre une validation manuelle des entrées et de s'assurer qu'un encodage de sortie approprié est appliqué avant de rendre les entrées utilisateur dans les vues. Ne jamais afficher directement des entrées utilisateur non validées pour prévenir les vulnérabilités XSS.

OWASP :

A6:2017-Misconfiguration de la sécurité
A05:2021-Misconfiguration de la sécurité