Règles Semgrep Csharp¶

csharp_cors_rule-PermissiveCORSInjection-aspnetcore¶

Résumé :

Politique permissive de domaine croisé avec des domaines non fiables

Sévérité : Élevée

Description :

L'application permet à l'entrée fournie par l'utilisateur de contrôler la valeur de l'en-tête de réponse Access-Control-Allow-Origin. Cet en-tête fait partie de la spécification Cross-Origin Resource Sharing (CORS) qui détermine quels domaines externes peuvent accéder aux ressources sur ce serveur. En permettant à l'entrée de l'utilisateur de spécifier des domaines fiables, un adversaire pourrait exploiter cette faiblesse pour forcer les clients à envoyer des informations d'identification (telles que des identifiants de session ou des cookies) au serveur de l'adversaire. Cette vulnérabilité devient exploitables lorsqu'elle est combinée avec d'autres faiblesses telles que le Cross-Site Scripting (XSS), permettant aux attaquants de contourner les protections de la politique de même origine et de voler des données sensibles. Un attaquant pourrait définir l'en-tête sur son domaine malveillant et tromper les utilisateurs authentifiés en effectuant des requêtes interdomaines qui divulguent des informations sensibles.

Remédiation :

N'utilisez jamais directement l'entrée fournie par l'utilisateur dans l'en-tête Access-Control-Allow-Origin. Au lieu de cela, maintenez une liste blanche codée en dur de domaines de confiance et utilisez une logique de validation pour vérifier l'origine demandée par rapport à cette liste avant de définir l'en-tête.

Exemple de validation sécurisée de l'origine CORS :

public void ConfigureCors(HttpContext context)
{
    // Définir les domaines autorisés
    var allowedOrigins = new HashSet<string>
    {
        "https://example.com",
        "https://app.example.com",
        "https://mobile.example.com"
    };

    // Obtenir l'origine de la requête
    string requestOrigin = context.Request.Headers["Origin"];

    // Valider et définir l'en-tête uniquement si l'origine est dans la liste blanche
    if (!string.IsNullOrEmpty(requestOrigin) &&
        allowedOrigins.Contains(requestOrigin))
    {
        context.Response.Headers["Access-Control-Allow-Origin"] = requestOrigin;
    }
}

Pour une configuration plus flexible, utilisez le middleware CORS intégré d'ASP.NET Core avec SetIsOriginAllowed :

services.AddCors(options =>
{
    options.AddPolicy("DynamicPolicy", builder =>
    {
        builder.SetIsOriginAllowed(origin =>
        {
            var allowedOrigins = new[]
            {
                "https://example.com",
                "https://app.example.com"
            };
            return allowedOrigins.Contains(origin);
        })
        .AllowAnyMethod()
        .AllowAnyHeader();
    });
});

Ne construisez jamais l'origine autorisée à partir de l'entrée utilisateur en utilisant la concaténation de chaînes ou le formatage. Utilisez toujours une correspondance exacte de chaînes par rapport à une liste prédéfinie.

Pour plus d'informations sur la configuration sécurisée de CORS, voir : : cors : Access-Control-Allow-Origin

OWASP :

A05:2021-Mauvaise configuration de sécurité
A06:2017-Mauvaise configuration de sécurité

csharp_deserialization_rule-InsecureDeserialization¶

Résumé :

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

Sévérité : Élevée

CWE : CWE-502

Description :

L'application utilise une désérialisation .NET non sécurisée à travers des formatters comme BinaryFormatter.Deserialize(), SoapFormatter.Deserialize(), NetDataContractSerializer.Deserialize(), ou LosFormatter.Deserialize() avec des données provenant potentiellement de sources non fiables telles que des requêtes HTTP, des fichiers ou des variables d'environnement. Ces formatters .NET obsolètes peuvent instancier des types arbitraires durant la désérialisation et exécuter du code via des constructeurs de type, des setters de propriété, ou des callbacks de sérialisation, permettant aux attaquants d’atteindre l'exécution de code à distance en fournissant des charges utiles sérialisées spécialement conçues. Microsoft a officiellement déprécié BinaryFormatter et les formatters connexes en raison de vulnérabilités de sécurité non réparables, 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'objet via ces formatters peut également permettre des attaques par attribution massive où des propriétés inattendues sont définies sur des objets, contournant ainsi les contrôles de sécurité ou modifiant l'état de l'application.

Remédiation :

Considérez la possibilité de migrer des formatters .NET obsolètes 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 de type restreint. Pour les applications nécessitant une sérialisation binaire, envisagez Protocol Buffers (protobuf-net), MessagePack (MessagePack-CSharp), ou Bond, qui utilisent tous la 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 explicitement configurés via DataContractSerializer.KnownTypes ou ajoutez des types de manière sélective en utilisant le paramètre knownTypes. Lors de l'utilisation de JSON.NET (Newtonsoft.Json), définissez TypeNameHandling sur TypeNameHandling.None pour empêcher les informations de type d'être traitées durant la désérialisation. Ne désérialisez jamais vers des types de base comme Object ou dynamique, et effectuez toujours un cast vers des types spécifiquement attendus après validation. Implémentez des listes autorisées de types permis 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 les opérations de désérialisation avec des permissions minimales. Pour plus d'informations, consultez le guide de sécurité de Microsoft sur BinaryFormatter à https://learn.microsoft.com/en-us/dotnet/standard/serialization/binaryformatter-security-guide et la feuille de triche OWASP sur la désérialisation à https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html

OWASP :

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

csharp_deserialization_rule-InsecureDeserializationNewtonsoft¶

Résumé :

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

Gravité : Élevée

CWE : CWE-502

Description :

Les attaques de désérialisation exploitent le processus de lecture de données sérialisées et de 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 durant la désérialisation.

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

OWASP :

A08:2017-Désérialisation non sécurisée
A08:2021-Nomenclature logicielle et échecs d'intégrité des données

csharp_injection_rule-CommandInjection¶

Résumé :

Neutralisation incorrecte des éléments spéciaux utilisés dans une commande OS ('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 entraîner un compromis complet du système. Lorsque les entrées utilisateur circulent 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 natives .NET qui implémentent la même fonctionnalité, car cela élimine complètement 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 de chemins exécutables et d'arguments, 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 correspondance où l'entrée utilisateur fournit une clé plutôt que la valeur réelle. Toujours définir ProcessStartInfo.UseShellExecute sur false pour empêcher l'interprétation des métacaractères par le shell. Assurez-vous que des chemins absolus complets sont utilisés pour FileName (par exemple, "C:\App\Tool.exe") afin de prévenir les vulnérabilités de recherche de chemin non fiables (CWE-426). Pour plus d'informations, consultez la feuille de triche OWASP sur la défense contre l'injection de commande OS à l'adresse https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html

OWASP :

A01:2017-Injection
A03:2021-Injection

Updated Français translation¶

csharp_other_rule-UnsafeXSLTSettingUsed¶

Résumé :

Injection XML (également connue sous le nom d'injection XPath aveugle)

Gravité : Élevée

CWE : CWE-91

Description :

Détection de XsltSettings avec EnableScript ou EnableDocumentFunction définis sur true. Ces paramètres permettent l'exécution de code à l'intérieur 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 total du système par l'exécution de code arbitraire.

Remédiation :

Envisagez de définir à false à la fois XsltSettings.EnableScript et XsltSettings.EnableDocumentFunction pour prévenir l'exécution de code à l'intérieur 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 de lancer XslCompiledTransform.Transform() au lieu d'utiliser des scripts XSL pour exécuter des fonctions.

OWASP :

A01:2017-Injection
A03:2021-Injection

csharp_cors_rule-MissingCORS-aspnetcore¶

Résumé :

Politique de partage des ressources entre origines manquante sur un point de terminaison à risque

Gravité : Moyenne

CWE : CWE-942

Description :

Le point de terminaison accepte les requêtes HTTP POST sans aucune politique CORS configurée. Les points de terminaison POST qui sont accessibles publiquement ([AllowAnonymous]) ou acceptent des données de formulaire ([FromForm]) peuvent être ciblés par des requêtes inter-origines qui contournent les vérifications préalables CORS (requêtes simples). Sans politique CORS, le navigateur enverra la requête et le serveur la traitera, permettant potentiellement des changements d'état non autorisés provenant d'origines malveillantes. Appliquez un attribut [EnableCors] avec une politique d'origine restrictive, ou utilisez [DisableCors] pour refuser explicitement.

Remédiation :

Configurez une politique CORS sur le point de terminaison ou son contrôleur pour contrôler quelles origines peuvent émettre des requêtes inter-origines.

Option 1 — Appliquez [EnableCors] avec une politique nommée :

// Dans Program.cs / Startup.cs
builder.Services.AddCors(options =>
{
    options.AddPolicy("MyPolicy", policy =>
    {
        policy.WithOrigins("https://example.com")
              .AllowAnyMethod()
              .AllowAnyHeader();
    });
});

// Sur le contrôleur ou l'action
[EnableCors("MyPolicy")]
[AllowAnonymous]
[HttpPost]
public IActionResult Submit([FromForm] string data)
{
    return Ok();
}

Option 2 — Utilisez [DisableCors] pour rejeter explicitement les requêtes inter-origines :

[DisableCors]
[AllowAnonymous]
[HttpPost]
public IActionResult InternalOnly([FromForm] string data)
{
    return Ok();
}

Pour plus d'informations sur la sécurité CORS, voir : : cors : CORS

OWASP :

A05:2021-Mésconfiguration de la sécurité
A06:2017-Mésconfiguration de la sécurité

csharp_cors_rule-PermissiveCORS-aspnetcore¶

Résumé :

Politique inter-domaines permissive avec des domaines non fiables

Gravité : Moyenne

CWE : CWE-942

Description :

L'application configure CORS (Cross-Origin Resource Sharing) pour permettre des requêtes de n'importe quelle origine en utilisant un wildcard ('*') dans ASP.NET Core. Cette politique permissive permet à n'importe quel site web d'effectuer des requêtes inter-domaines vers cette application, exposant potentiellement des données sensibles ou des fonctionnalités à des domaines malveillants. Lorsque AllowAnyOrigin(), WithOrigins("*"), ou une assignation directe d'en-tête wildcard est utilisée, l'application perd le contrôle sur les domaines externes pouvant interagir avec elle, la rendant vulnérable à des attaques inter-site. Cela est particulièrement dangereux lorsqu'il est combiné avec AllowCredentials(), car les navigateurs rejetteront de telles configurations, mais le modèle de sécurité sous-jacent est toujours compromis.

Remédiation :

Il est recommandé de spécifier des origines de confiance explicites au lieu d'utiliser des wildcards. Maintenez une liste blanche de domaines de confiance et configurez CORS pour ne permettre des requêtes que de ces origines spécifiques. Dans ASP.NET Core, utilisez WithOrigins() avec des noms de domaine explicites plutôt que AllowAnyOrigin().

Exemple de configuration CORS sécurisée :

services.AddCors(options =>
{
    options.AddPolicy("SecurePolicy", builder =>
    {
        builder.WithOrigins(
            "https://example.com",
            "https://app.example.com"
        )
        .AllowAnyMethod()
        .AllowAnyHeader();
    });
});

Si vous devez autoriser les identifiants (cookies, en-têtes d'autorisation), n'utilisez jamais AllowAnyOrigin() car les navigateurs rejetteront cette configuration. Au lieu de cela, spécifiez des origines exactes et utilisez AllowCredentials() :

builder.WithOrigins("https://example.com")
       .AllowCredentials()
       .AllowAnyMethod()
       .AllowAnyHeader();

Pour la validation dynamique des origines, implémentez une logique personnalisée pour valider contre une liste blanche :

app.UseCors(builder =>
{
    builder.SetIsOriginAllowed(origin =>
    {
        var allowedOrigins = new[] {
            "https://example.com",
            "https://app.example.com"
        };
        return allowedOrigins.Contains(origin);
    })
    .AllowAnyMethod()
    .AllowAnyHeader();
});

Pour plus d'informations sur la sécurité CORS, voyez : : cors : CORS

OWASP :

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

csharp_cors_rule-PermissiveCORS-webapi¶

Résumé :

Politique inter-domaines permissive avec des domaines non fiables

Sévérité : Moyenne

CWE : CWE-942

Description :

L'application configure CORS (Cross-Origin Resource Sharing) pour autoriser les requêtes depuis n'importe quelle origine en utilisant un wildcard ('') dans ASP.NET Web API. Cette politique permissive permet à n'importe quel site web de faire des requêtes inter-domaines à cette application, exposant potentiellement des données sensibles ou des fonctionnalités à des domaines malveillants. Le EnableCorsAttribute avec des origines définies à "" ou une assignation directe d'en-tête avec des valeurs wildcard supprime les contrôles d'accès basés sur l'origine, permettant à n'importe quel domaine externe d'interagir avec vos points de terminaison API. Cela est particulièrement dangereux lorsque l'API traite des opérations sensibles ou retourne des données confidentielles, car les attaquants peuvent créer des sites web malveillants qui font des requêtes à votre API depuis les navigateurs des victimes. Même sans identifiants, cela peut mener à une divulgation d'informations et des actions non autorisées.

Remédiation :

Il est recommandé de spécifier des origines de confiance explicites plutôt que d'utiliser des wildcards. Maintenez une liste blanche de domaines de confiance et configurez CORS pour autoriser uniquement les requêtes de ces origines spécifiques. Dans ASP.NET Web API, utilisez EnableCorsAttribute avec des noms de domaine spécifiques.

Exemple de configuration CORS sécurisée dans Web API :

// Dans WebApiConfig.cs
public static void Register(HttpConfiguration config)
{
    var cors = new EnableCorsAttribute(
        origins: "https://example.com,https://app.example.com",
        headers: "*",
        methods: "*"
    );
    config.EnableCors(cors);
}

Pour CORS au niveau du contrôleur ou de l'action :

[EnableCors(
    origins: "https://example.com,https://app.example.com",
    headers: "*",
    methods: "*"
)]
public class SecureApiController : ApiController
{
    public IHttpActionResult Get()
    {
        return Ok("Données sécurisées");
    }
}

Pour la validation dynamique des origines, implémentez un fournisseur de politique CORS personnalisé :

public class CustomCorsPolicyProvider : ICorsPolicyProvider
{
    private readonly string[] _allowedOrigins = {
        "https://example.com",
        "https://app.example.com"
    };

    public Task<CorsPolicy> GetCorsPolicyAsync(
        HttpRequestMessage request,
        CancellationToken cancellationToken)
    {
        var policy = new CorsPolicy();
        var origin = request.Headers.GetValues("Origin").FirstOrDefault();

        if (_allowedOrigins.Contains(origin))
        {
            policy.Origins.Add(origin);
        }

        policy.AllowAnyMethod = true;
        policy.AllowAnyHeader = true;

        return Task.FromResult(policy);
    }
}

N'utilisez jamais d'origines wildcard lorsque vous traitez des données sensibles ou des points de terminaison authentifiés.

Pour plus d'informations sur la sécurité CORS dans Web API, consultez : : enabling-cross-origin-requests-in-web-api : CORS

OWASP :

A05:2021-Misconfiguration de sécurité
A06:2017-Misconfiguration de sécurité

Updated Français translation¶

csharp_crypto_rule-CertificateValidationDisabled¶

Résumé :

Validation du certificat désactivée

Gravité : Moyenne

CWE : CWE-295

Description :

L'événement ServicePointManager.ServerCertificateValidationCallback a été configuré pour toujours renvoyer true, ce qui désactive effectivement la validation des certificats de 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 par le biais d'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 d'usurpation d'identité.

Remédiation :

Envisagez de supprimer la fonction de rappel qui renvoie inconditionnellement true pour permettre à la validation normale des certificats de se poursuivre. 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 requête et que la chaîne de certificats est de confiance. Si une validation de certificat personnalisée est requise pour des scénarios spécifiques (comme l'acceptation de 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 des certificats 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 :

A02:2017-Authentification défaillante
A07:2021-Failles d'identification et d'authentification

Français translation¶

csharp_crypto_rule-InsecureCertificateValidation¶

Résumé :

Validation de certificat non sécurisée

Gravité : Moyenne

CWE : CWE-295

Description :

La validation du certificat du serveur a été désactivée ou affaiblie, ce qui permet à un adversaire de mener des attaques de type homme du milieu. L'application acceptera des certificats invalides, expirés ou non correspondants sans avertissement, rendant impossible la vérification de l'identité du serveur distant. Cela affecte HttpClientHandler.ServerCertificateCustomValidationCallback, ServicePointManager.ServerCertificateValidationCallback, ou une logique de validation personnalisée qui ignore sélectivement les erreurs de certificat.

Remédiation :

Supprimez les callbacks qui retournent inconditionnellement true ou qui ignorent sélectivement les erreurs de certificat telles que les non-correspondances de nom ou les certificats expirés. Lorsque aucun callback personnalisé n'est défini, le runtime .NET valide que le certificat du serveur est de confiance, non expiré et correspond à l'hôte demandé. Si une validation personnalisée est requise (par exemple, le pinning de certificat), implémentez des vérifications appropriées plutôt que de contourner la validation. Évitez d'utiliser HttpClientHandler.DangerousAcceptAnyServerCertificateValidator en dehors du développement local. Guide supplémentaire : system.net.http.httpclienthandler.servercertificatecustomvalidationcallback

OWASP :

A02:2017-Authentification défaillante
A07:2021-Échecs 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 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 de type sweet32 après le traitement de grandes quantités de données. RC2 souffre également d'une petite taille de clé effective 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 versions ultérieures, car il offre 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 fournit 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 de nonces entraîne des défaillances de sécurité catastrophiques. Les deux alternatives nécessitent de générer des clés et des nonces aléatoires cryptographiquement sécurisés 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 encryptées existantes sont correctement migrées ou que l'application maintient la compatibilité ascendante pour le déchiffrement tout en chiffrant de nouvelles données avec l'algorithme plus fort.

OWASP :

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

Français translation¶

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 réglages de 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 monter 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 nécessitent que les développeurs mettent en œuvre manuellement l'authentification des messages, ce qui est sujet à erreurs et souvent fait de manière incorrecte.

Remédiation :

Envisagez de migrer vers des algorithmes de chiffrement authentifié qui fournissent 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 chiffrement et authentification en une seule opération qui est à la fois plus rapide et plus facile à utiliser correctement que les anciennes alternatives. Pour les applications sur les versions plus anciennes du .NET Framework, AesGcm offre un chiffrement authentifié AES-256-GCM, bien qu'il nécessite une gestion soigneuse des nonces, car réutiliser un nonce avec la même clé entraîne des échecs de sécurité catastrophiques. Les deux alternatives éliminent le besoin de mettre en œuvre séparément HMAC ou d'autres codes d'authentification de message. Lors de la migration depuis CBC ou d'autres modes, assurez-vous que les nonces sont générés à l'aide de RandomNumberGenerator.Fill() et stockés avec le texte chiffré pour la décryption.

OWASP :

A03:2017-Exposition des données sensibles
A02:2021-Échecs cryptographiques

Français translation¶

csharp_crypto_rule-WeakHashingFunction¶

Résumé :

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

Gravité : Moyenne

CWE : CWE-327

Description :

L'application utilise des algorithmes de hachage cryptographiques cassés via MD5CryptoServiceProvider, SHA1CryptoServiceProvider, ou leurs méthodes de fabrique comme System.Security.Cryptography.MD5.Create() et System.Security.Cryptography.SHA1.Create(). MD5 est sévèrement compromis, avec des attaques par collision pratiques démontrées depuis 2004, tandis que les attaques par collision SHA1 sont devenues pratiques en 2017. Ces 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 fabriquer deux entrées différentes produisant 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 qu'à des algorithmes de hachage généralistes. 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 le salage et l'étirement de clé pour résister aux attaques par force brute. Pour le hachage cryptographique général, utilisez SHA-256 ou SHA-512 du namespace System.Security.Cryptography. Lors de la comparaison des valeurs de hachage, utilisez CryptographicOperations.FixedTimeEquals() pour prévenir les attaques par timing qui pourraient fuir des informations sur la valeur de hachage. Notez que bien que des implémentations Argon2id vérifiées puissent devenir disponibles à l'avenir, PBKDF2 reste un choix sécurisé lorsqu'il est configuré avec des paramètres appropriés. Des orientations supplémentaires sont disponibles à https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

OWASP :

A03:2017-Exposition de Données Sensibles
A02:2021-Pannes Cryptographiques

csharp_crypto_rule-WeakRNG¶

Résumé :

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

Sévérité : 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écurisées comme les jeux ou les simulations. La classe Random utilise un algorithme déterministe semé avec l'horloge système, rendant sa sortie prévisible si un attaquant peut deviner la valeur de semence. 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, d'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 des valeurs futures 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 les tableaux d'octets aléatoires, utilisez RandomNumberGenerator.Fill() pour remplir un tampon pré-alloué. Ces méthodes sont sécurisées pour les threads et ne nécessitent ni instanciation ni élimination. Réservez la classe Random exclusivement pour des fins non sécurisées où la prévisibilité est acceptable, comme la génération de contenu procédural ou la randomisation de gameplay. Documentation supplémentaire disponible à l'adresse : system.security.cryptography.randomnumbergenerator

OWASP :

A03:2017-Exposition des données sensibles
A02:2021-Échecs cryptographiques

csharp_csrf_rule-Csrf¶

Résumé :

Potentiel de falsification de requête intersite (CSRF)

Sévérité : Moyenne

CWE : CWE-352

Description :

Détection d'un gestionnaire [HttpPost] sans l'attribut [ValidateAntiForgeryToken]. Cela permet des attaques de falsification de requête intersite (CSRF) où des sites malveillants peuvent inciter des utilisateurs authentifiés à exécuter des actions de changement d'état non désirées. Les attaquants peuvent exploiter cette vulnérabilité en créant des formulaires qui soumettent des requêtes POST avec les identifiants de session de la victime.

Remédiation :

Envisagez d'ajouter l'attribut [ValidateAntiForgeryToken] à toutes les méthodes d'action [HttpPost]. Les requêtes POST sont vulnérables au CSRF car les navigateurs autorisent les soumissions de formulaires cross-origin sans vérifications préliminaires. Cela valide que les requêtes incluent un jeton anti-forgery valide, prévenant ainsi les attaques CSRF. Alternativement, activez globalement l'attribut [AutoValidateAntiforgeryTokenAttribute] pour protéger automatiquement tous les points de terminaison POST. 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 :

A05:2017-Contrôle d'accès défectueux
A01:2021–Contrôle d'accès défectueux

csharp_injection_rule-LdapInjection¶

Résumé :

Neutralisation incorrecte 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 les données contrôlées par l'utilisateur dans les requêtes LDAP pour manipuler la manière dont les données sont renvoyées des serveurs LDAP ou Active Directory. Même l'API moderne AccountManagement 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 de requête et potentiellement contourner l'authentification ou accéder à des informations d'annuaire non autorisées.

Remédiation :

Envisagez de mettre en œuvre une fonction d'encodage LDAP qui échappe les caractères spéciaux avant de transmettre les entrées utilisateur à toute méthode de requête LDAP. Il est recommandé d'encodage d'abord le caractère barre oblique inversée (comme "\5c"), suivi du nul ("\00"), de la parenthèse ouverte ("\28"), de la parenthèse fermée ("\29"), et de l'astérisque ("\2a") pour éviter l'injection de filtre. Cet encodage s'applique à la fois à l'API moderne System.DirectoryServices.AccountManagement et à l'API plus ancienne DirectorySearcher. Lorsque vous utilisez 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 OWASP sur la prévention des injections LDAP à l'adresse https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html

OWASP :

A01:2017-Injection
A03:2021-Injection

csharp_injection_rule-SQLInjection¶

Résumé :

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

Sévérité : Moyenne

CWE : CWE-89

Description :

L'application utilise des méthodes d'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 les entrées utilisateur qui s'écoulent dans les chaînes de requête. Cette vulnérabilité critique peut conduire à un accès non autorisé aux données, à la modification de données, au contournement de l'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 :

Considérez l'utilisation exclusivement de requêtes paramétrées pour toutes les opérations de base de données, où les entrées utilisateur sont passées en tant que paramètres plutôt que concaténées dans des chaînes SQL. Pour SqlCommand et des classes similaires, utilisez la méthode Parameters.Add() avec des types SQL explicites comme SqlDbType.NVarChar pour lier en toute sécurité les valeurs utilisateur. Lorsque vous utilisez Entity Framework, préférez ExecuteSqlInterpolated() ou FromSqlInterpolated() qui paramètre 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 tables ou de colonnes 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 à des identifiants de base de données valides. Pour des opérateurs dynamiques comme > ou <, envisagez de demander aux utilisateurs de fournir des valeurs symboliques comme "gt" ou "lt" qui sont ensuite mappées aux véritables opérateurs, plutôt que d'accepter les opérateurs directement. Évitez d'utiliser CommandType.Text avec des chaînes concaténées et ne faites jamais confiance aux entrées utilisateur pour les identifiants de base de données. Pour plus d'informations, consultez la feuille de triche OWASP sur la prévention des injections SQL à https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html

OWASP :

A01:2017-Injection
A03:2021-Injection

csharp_injection_rule-XPathInjection¶

Résumé :

Neutralisation incorrecte des données au sein des expressions XPath ('XPath Injection')

Sévérité : Moyenne

CWE : CWE-643

Description :

L'application utilise des méthodes de requête XPath comme 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, ce qui peut conduire à une extraction non autorisée de données, à la divulgation d'informations, ou dans de rares cas à un contournement d'authentification lorsque XPath est utilisé pour des décisions de contrôle d'accès.

Remédiation :

Envisagez de passer à LINQ to XML (System.Xml.Linq) qui offre une requête sûre par type grâce aux méthodes comme Descendants(), Elements(), et Where() qui utilisent la comparaison de chaînes .NET plutôt que l'évaluation des expressions XPath. Il est recommandé d'utiliser XDocument ou XElement avec des méthodes LINQ standard, où l'entrée de l'utilisateur est traitée comme des données dans les prédicats de filtre plutôt que comme partie de la structure de la requête. Évitez d'utiliser les méthodes d'extension XPathEvaluate(), XPathSelectElement(), et XPathSelectElements() de System.Xml.XPath même dans les requêtes LINQ, car elles évaluent toujours les expressions XPath et restent vulnérables à l'injection. Si XPath doit être utilisé, envisagez de mettre en œuvre une liste blanche de modèles de requêtes valides et d'utiliser des approches paramétrées où l'entrée de l'utilisateur n'influence que les valeurs de données, pas la structure de la requête. Notez que XDocument est également protégé par défaut contre les attaques XXE 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 :

A01:2017-Injection
A03:2021-Injection

csharp_injection_rule-XmlDocumentXXEInjection¶

Résumé :

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

Gravité : 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 sur null. Les attaques d'entité externe XML (XXE) exploitent les parseurs XML qui résolvent les références d'entités externes, permettant aux attaquants de lire des fichiers arbitraires à partir du système de fichiers du serveur, d'effectuer des attaques de falsification de requêtes côté serveur (SSRF) vers des ressources réseau internes, d'exfiltrer des données sensibles vers des hôtes externes ou de provoquer des dénis de service par des attaques de milliard de rires. Par défaut, XmlDocument.Load() et XmlDocument.LoadXml() dans les anciennes versions du .NET Framework permettent la résolution d'entités externes, rendant les applications vulnérables lors du traitement d'entrées XML non dignes de confiance.

Remédiation :

Envisagez de migrer vers System.Xml.Linq.XDocument qui désactive la résolution d'entités externes par défaut et fournit une API plus moderne et plus sûre pour le traitement XML avec une protection intégrée contre les attaques XXE et DoS. Si XmlDocument doit être utilisé pour des raisons de compatibilité héritée, il est recommandé de définir explicitement XmlDocument.XmlResolver = null immédiatement après l'instanciation et avant d'appeler les méthodes Load() ou LoadXml(). Assurez-vous que votre application cible .NET Framework 4.5.2 ou 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 dignes de confiance provenant de sources externes, envisagez de valider la structure et la taille du XML avant l'analyse afin de prévenir les attaques d'épuisement des ressources. Évitez d'utiliser la syntaxe d'initialisation des objets sans définir explicitement XmlResolver = null dans le bloc d'initialisation. Pour plus d'informations, consultez le Cheat Sheet sur la prévention des entités externes XML d'OWASP à l'adresse suivante :
https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#net

OWASP :

A04:2017-Entités externes XML (XXE)
A06:2017-Mauvaise configuration de sécurité
A05:2021–Mauvaise configuration de sécurité

csharp_injection_rule-XmlReaderXXEInjection¶

Résumé :

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

Gravité : Moyenne

CWE : CWE-611

Description :

L'application utilise System.Xml.XmlReader.Create() avec XmlReaderSettings configuré pour permettre le traitement 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 des attaques de contournement de demande côté serveur (SSRF), exfiltrer des données ou provoquer une déni de service par des attaques d'expansion d'entité. Lorsque le traitement DTD est activé, les attaquants peuvent inclure des déclarations d'entité externe malveillantes dans des documents XML qui référencent 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 DTD et prévenir 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 DTD, bien que la migration vers la propriété DtdProcessing soit préférable pour les applications modernes. Assurez-vous que votre application cible .NET Framework 4.5.2 ou version ultérieure (publiée en 2014) qui fournit des valeurs par défaut de parsing XML plus sûres. Si la validation DTD est réellement nécessaire pour votre cas d'utilisation, envisagez d'utiliser DtdProcessing.Ignore, qui ignore le traitement DTD mais permet au document de contenir une déclaration 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 des ressources externes même si le traitement DTD est accidentellement activé. Pour plus d'informations, consultez la feuille de triche OWASP sur la prévention des entités externes XML à l'adresse suivante :
https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#net

OWASP :

A04:2017-Entités externes XML (XXE)
A06:2017-Configuration de sécurité incorrecte
A05:2021–Configuration de sécurité incorrecte

csharp_path_rule-PathTraversal¶

Résumé :

Limitation incorrecte d'un chemin d'accès à un répertoire restreint ('Path Traversal')

Gravité : Moyenne

CWE : CWE-22

Description :

L'application utilise des entrées utilisateur dans les 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 viennent de l'entrée utilisateur, les attaquants peuvent utiliser des séquences de parcours 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 :

Envisagez de ne jamais utiliser directement les entrées utilisateur dans les opérations du système de fichiers. Il est recommandé de remplacer les noms de fichiers fournis par l'utilisateur par des identifiants contrôlés tels que des GUIDs. 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 sur les fichiers. Cela garantit que les chemins restent dans des répertoires restreints et prévient les attaques de traversée.

OWASP :

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

csharp_xss_rule-HtmlElementXss¶

Résumé :

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

Gravité : 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 terminaison 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ù des attaquants peuvent injecter du JavaScript malveillant qui s'exécute dans les navigateurs des victimes. La règle détecte le flux de dégradé des propriétés de requête ASP.NET vers des méthodes de rendu qui contournent l'encodage HTML automatique de Razor. Sans 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 peut potentiellement conduire à des détournements de session, au vol d'identifiants ou à des attaques de dégradation.

Remédiation :

Envisagez d'utiliser l'encodage HTML automatique de Razor en rendant les données utilisateur via la syntaxe Razor standard @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 les entrées utilisateur si nécessaire. Si vous devez utiliser HtmlHelper.Raw(), assurez-vous que les données ont été assainies avec un assainisseur HTML basé sur une liste blanche comme le paquet NuGet HtmlSanitizer avant de les passer. 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 comme défense en profondeur. Consultez les recommandations de Microsoft pour la prévention XSS à l'adresse https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting pour des recommandations d'encodage spécifiques au contexte supplémentaires.

OWASP :

A03:2017-Cross-Site Scripting (XSS)
A01:2017-Injection
A03:2021-Injection

Français translation¶

csharp_xss_rule-ScriptXss¶

Résumé :

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

Sévérité : Moyenne

CWE : CWE-79

Description :

L'application injecte des données fournies par l'utilisateur à partir des objets de requête ASP.NET directement dans JavaScript côté client en les passant aux méthodes ScriptManager.RegisterStartupScript(), ScriptManager.RegisterClientScriptBlock(), ou aux méthodes héritées RegisterStartupScript() / RegisterClientScriptBlock(). Cela crée une vulnérabilité de Cross-Site Scripting (XSS) dans le contexte JavaScript, ce qui est particulièrement dangereux car les attaquants peuvent exécuter un code JavaScript arbitraire sans avoir besoin de sortir de l'encodage HTML. La règle détecte le flux de données contaminées à partir des propriétés de requête (Formulaire, QueryString, Cookies, En-têtes, etc.) vers les méthodes d'enregistrement de script ASP.NET. Sans encodage spécifique à JavaScript, une entrée malveillante peut manipuler le comportement des scripts, accéder à des données sensibles, modifier le DOM ou effectuer des actions au nom de l'utilisateur.

Remédiation :

Envisagez d'utiliser System.Text.Encodings.Web.JavaScriptEncoder.Default.Encode() pour correctement échapper les entrées utilisateur avant de les intégrer dans JavaScript enregistré via les méthodes ScriptManager. Pour les applications ASP.NET Web Forms, assurez-vous que les données utilisateur sont sérialisées au format JSON avec un échappement approprié en utilisant System.Web.Script.Serialization.JavaScriptSerializer ou Newtonsoft.Json avec les paramètres adéquats. Évitez la concaténation de chaînes lors de la construction de JavaScript - de préférence, passez les données sous forme d'objets JSON et parsez-les côté client. Pour les applications modernes ASP.NET Core, envisagez de transmettre les données via des attributs de données sur des éléments HTML et de les lire avec JavaScript, permettant à l'encodage automatique de Razor de protéger les valeurs. Implémentez des en-têtes de politique de sécurité de contenu (CSP) avec script-src 'self' pour prévenir l'exécution de scripts en ligne en tant que défense en profondeur. Consultez les recommandations de Microsoft sur l'encodage JavaScript à https://learn.microsoft.com/en-us/aspnet/core/security/cross-site-scripting pour des recommandations supplémentaires.

OWASP :

A03:2017-Cross-Site Scripting (XSS)
A01:2017-Injection
A03:2021-Injection

csharp-dotnet-missing-authorization¶

Résumé :

Aucun

Gravité : Avertissement

CWE : ['CWE-862 : Autorisation manquante']

Description :

Le contrôleur ou la méthode d'action manque d'attribut d'autorisation. Cela pourrait permettre un accès non autorisé à des fonctionnalités sensibles. Ajoutez l'attribut [Authorize], [Authorize(Roles = "...")] ou [Authorize(Policy = "...")] à la classe de contrôleur ou aux méthodes d'action individuelles. Si l'accès public est intentionnel, marquez-le explicitement avec [AllowAnonymous]. OWASP :

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

csharp_cookies_rule-CookieWithoutHttpOnlyFlag¶

Résumé :

Cookie sensible sans le drapeau 'HttpOnly'

Sévérité : Faible

CWE : CWE-1004

Description :

Détection d'un HttpCookie ou d'un Cookie créé sans que la propriété HttpOnly soit définie sur true. Sans ce drapeau, le JavaScript côté client peut accéder à la valeur du cookie via document.cookie, permettant ainsi aux attaquants de voler des données de session par le biais d’attaques Cross-Site Scripting (XSS). Cela expose des informations de session sensibles à des scripts malveillants exécutés dans le navigateur de l'utilisateur.

Remédiation :

Envisagez de définir la propriété HttpOnly sur true pour tous les cookies afin d'empêcher l'accès du JavaScript côté client. Cela protège les cookies de session contre les attaques XSS en bloquant l'accès des scripts aux valeurs de cookies via document.cookie. Par exemple, définissez someCookie.HttpOnly = true; lors de la création d'instances de HttpCookie. De plus, il est recommandé de définir également le drapeau Secure (transmission uniquement HTTPS) et l’attribut SameSite (protection CSRF) pour une sécurité complète des cookies.

OWASP :

A06:2017-Misconfiguration de la sécurité
A05:2021–Misconfiguration de la sécurité

csharp_cookies_rule-CookieWithoutSSLFlag¶

Résumé :

Cookie sensible dans une session HTTPS sans attribut 'Secure'

Sévérité : Faible

CWE : CWE-614

Description :

Détection d'un HttpCookie créé sans que la propriété Secure soit définie sur true. Sans ce drapeau, le cookie peut être transmis sur des connexions HTTP non chiffrées, exposant des données de session sensibles aux attaquants sur le réseau via des attaques de type homme du milieu. Cela permet aux écouteurs d'intercepter et de voler des valeurs de cookie transmises par des canaux non sécurisés.

Remédiation :

Envisagez de définir la propriété Secure sur true pour tous les cookies afin de forcer la transmission uniquement via HTTPS. Cela garantit que les cookies ne sont envoyés que sur des connexions chiffrées, les protégeant contre l'interception sur des réseaux non sécurisés. Par exemple, définissez someCookie.Secure = true; lors de la création d'instances de HttpCookie. Cette protection est essentielle pour toute application traitant des données sensibles ou des jetons d'authentification sur HTTPS.

OWASP :

A06:2017-Mésconfiguration de sécurité
A05:2021–Mésconfiguration de sécurité

csharp_endpoint_rule-UnvalidatedRedirect¶

Résumé :

Redirection d'URL vers un site non fiable 'redirection ouverte'

Sévérité : Info

CWE : CWE-601

Description :

Méthodes de redirection détectées (Redirect(), RedirectPermanent(), RedirectToRoute(), RedirectToRoutePermanent(), ou RedirectResult) utilisant des entrées fournies par l'utilisateur. Les redirections ouvertes sont souvent abusées dans les attaques de phishing où une URL ayant l'apparence légitime redirige les utilisateurs vers des sites malveillants. Cela permet aux attaquants de tirer parti de la réputation du domaine de confiance pour tromper les victimes.

Remédiation :

Envisagez de valider les URLs de redirection en utilisant Url.IsLocalUrl() pour assurer qu'elles ciblent uniquement l'application locale. Il est recommandé de mettre en œuvre une approche de redirection basée sur un index où l'entrée de l'utilisateur fournit un ID numérique qui correspond à une liste maintenue côté serveur des URLs de redirection autorisées. Envisagez de maintenir une liste blanche de domaines externes approuvés si des redirections externes sont nécessaires. Ne redirigez jamais les clients en fonction de URLs brutes fournies par l'utilisateur.

OWASP :

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

csharp_password_rule-PasswordComplexity¶

Résumé :

Exigences de mot de passe faibles

Gravité : Info

CWE : CWE-521

Description :

L'application configure des exigences de mot de passe faibles en définissant des propriétés telles que RequiredLength à moins de 8 caractères, ou en désactivant les exigences de complexité telles que RequireDigit, RequireLowercase, RequireUppercase ou RequireNonAlphanumeric. Des politiques de mot de passe faibles rendent les comptes vulnérables aux attaques par brute force et aux attaques par dictionnaire.

Remédiation :

Envisagez de renforcer les politiques de mot de passe dans la configuration d'ASP.NET Core Identity. Il est recommandé de définir options.Password.RequiredLength à au moins 8 caractères et d'activer toutes les exigences de complexité : RequireDigit = true, RequireLowercase = true, RequireUppercase = true, et RequireNonAlphanumeric = true. De plus, définissez RequiredUniqueChars à au moins 1 pour assurer la diversité des mots de passe.

OWASP :

A02:2017-Authentification rompue
A07:2021-Échecs d'identification et d'authentification

csharp_validation_rule-InputValidation¶

Résumé :

Validation des entrées ASP.NET désactivée

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 d'ASP.NET. Cela empêche le framework d'examiner les requêtes pour 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 explicitement celui-ci 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 veiller à ce qu'un encodage de sortie approprié soit appliqué avant de rendre l'entrée utilisateur dans les vues. Ne jamais afficher directement des entrées utilisateur non validées pour prévenir les vulnérabilités XSS.