Règles Semgrep pour Go¶

go_sql_rule-concat-sqli¶

Résumé :

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

Gravité : Élevée

CWE : CWE-89

Description :

Vulnérabilité d'injection SQL détectée lors de la construction dynamique de requêtes utilisant fmt.Sprintf(), la concaténation de chaînes, ou strings.Builder avec db.Exec(), db.Query(), ou db.QueryRow(). L'entrée utilisateur peut manipuler la logique SQL, ce qui conduit à un accès non autorisé aux données, à une modification des données, ou dans les cas graves, à l'exécution de commandes.

Remédiation :

Envisagez d'utiliser des requêtes paramétrées avec des espaces réservés ? pour passer en toute sécurité l'entrée utilisateur : db.Query("SELECT * FROM users WHERE userName = ?", userName). Pour les noms de tables ou de colonnes dynamiques qui ne peuvent pas être paramétrés, utilisez une approche de liste autorisée avec une carte de valeurs valides (par exemple, mapper l'entrée utilisateur "recent" à "created_at DESC"). Ne concaténez jamais directement l'entrée utilisateur dans des chaînes SQL. Pour des conseils complets, consultez : SQL_Injection_Prevention_Cheat_Sheet.html

OWASP :

A1:2017-Injection
A03:2021-Injection

go_subproc_rule-subproc¶

Résumé :

Neutralisation inadéquate des éléments spéciaux utilisés dans une commande OS ('Injection de commande OS')

Gravité : Élevée

CWE : CWE-78

Description :

Injection de commande OS détectée dans exec.Command(), exec.CommandContext(), syscall.ForkExec() ou syscall.StartProcess(). Les entrées contrôlées par l'utilisateur passées à ces fonctions peuvent permettre aux attaquants d'exécuter des commandes système arbitraires, entraînant un compromis complet du système. Les entrées utilisateur ne devraient jamais être utilisées pour construire des commandes ou des arguments, y compris les noms de fichiers provenant de téléchargements ou d'uploads par les utilisateurs.

Remédiation :

Envisagez d'utiliser un ensemble codé en dur de commandes et d'arguments au lieu d'accepter les entrées utilisateur. Si des noms de fichiers doivent être passés, il est recommandé d'utiliser un hachage ou un identifiant unique plutôt que des noms de fichiers fournis par l'utilisateur. Il est fortement recommandé d'utiliser des bibliothèques Go natives qui implémentent la même fonctionnalité au lieu d'exécuter des commandes OS, car cela élimine entièrement le risque d'injection de commande. Si l'entrée utilisateur est inévitable, mettez en œuvre une validation stricte en utilisant une liste d'autorisation des valeurs permises.

OWASP :

A1:2017-Injection
A03:2021-Injection

go_unsafe_rule-unsafe¶

Résumé :

Utilisation de fonctions intrinsèquement dangereuses (package unsafe)

Gravité : Élevée

CWE : CWE-242

Description :

L'utilisation des fonctions du package unsafe (unsafe.Alignof(), unsafe.Offsetof(), unsafe.Sizeof(), unsafe.Pointer()) contourne les garanties de sécurité des types de Go et permet une manipulation directe de la mémoire. Cela peut entraîner des débordements de tampon, des vulnérabilités de type use-after-free, des fuites de mémoire et l'exécution de code arbitraire.

Remède :

Envisagez de supprimer tous les appels au package unsafe à moins qu'ils ne soient absolument nécessaires pour des opérations critiques en termes de performance ou pour interfacer avec du code C. Il est recommandé d'utiliser les alternatives intégrées de Go, sûres pour les types, et les fonctions de la bibliothèque standard à la place. Si les opérations unsafe sont réellement nécessaires, isolez-les dans des fonctions bien documentées, soigneusement examinées avec des contrats clairs et des tests approfondis. Examinez chaque utilisation pour vous assurer qu'elle est vraiment nécessaire et ne peut pas être remplacée par des alternatives sûres.

OWASP :

A9:2017-Utilisation de composants avec des vulnérabilités connues
A06:2021-Composants vulnérables et obsolètes

go_blocklist_rule-blocklist-des¶

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Sévérité : Moyenne

CWE : CWE-327

Description :

L'application importe crypto/des qui fournit l'algorithme Data Encryption Standard (DES). Le DES utilise une taille de clé de 56 bits et a été cassé cryptographiquement par des attaques de recherche exhaustive depuis la fin des années 1990. Le DES a été officiellement retiré en tant que norme par le NIST (FIPS 46-3) en 2005 et ne devrait pas être utilisé dans aucune application moderne. Utiliser des.NewCipher() ou des.NewTripleDESCipher() expose les données chiffrées à des attaques par force brute pratiques.

Remédiation :

Envisagez de migrer vers des algorithmes de chiffrement authentifiés qui fournissent à la fois confidentialité et intégrité. L'approche recommandée est d'utiliser chacha20poly1305.NewX() du package golang.org/x/crypto/chacha20poly1305, qui offre de meilleures performances, des tailles de nonce plus importantes (192 bits) et une meilleure résistance aux abus de nonce par rapport aux alternatives. Pour les applications nécessitant une compatibilité avec l'AES, cipher.NewGCM() avec une clé de 32 octets fournit 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 défaillances de sécurité catastrophiques. Lors de l'utilisation d'AES-GCM, assurez-vous que les nonces sont générés avec io.ReadFull(rand.Reader, nonce) et que les clés sont renouvelées après 2^32 opérations. Des exemples d'implémentation complets sont disponibles à https://pkg.go.dev/golang.org/x/crypto/chacha20poly1305#NewX et https://pkg.go.dev/crypto/cipher#NewGCM pour les deux schémas de chiffrement.

OWASP :

A3:2017-Exposition de Données Sensibles
A02:2021-Failles Cryptographiques

go_blocklist_rule-blocklist-md5¶

Résumé :

Utilisation d'un algorithme cryptographique défaillant ou risqué

Gravité : Moyenne

CWE : CWE-327

Description :

L'application importe crypto/md5 qui fournit l'algorithme de hachage MD5. MD5 est considéré comme cryptographiquement défaillant depuis 2004, avec des attaques de collision pratiques démontrées par Wang et al., permettant aux attaquants de créer deux entrées différentes produisant des sorties de hachage identiques. L'utilisation de md5.New() ou md5.Sum() pour tout but critique en matière de sécurité, tel que les signatures numériques, la vérification de l'intégrité ou la validation des certificats, crée de sérieuses vulnérabilités. MD5 ne devrait pas être utilisé dans un contexte où la résistance aux collisions est requise.

Remédiation :

Envisagez d'utiliser des algorithmes de hachage modernes des familles BLAKE2 ou SHA-3 pour le hachage cryptographique général. Pour l'intégrité des fichiers ou les données non sensibles aux mots de passe, il est recommandé d'utiliser blake2b.New512() de golang.org/x/crypto/blake2b, qui offre une meilleure sécurité et performance que les anciens algorithmes SHA-2. Pour le hachage des mots de passe en particulier, envisagez d'utiliser argon2.IDKey() de golang.org/x/crypto/argon2 ou bcrypt.GenerateFromPassword() de golang.org/x/crypto/bcrypt, car ce sont des fonctions résistantes aux attaques par force brute. Lors de l'implémentation d'Argon2id, les paramètres recommandés sont mémoire=64Mo, itérations=3 et parallélisme=2 pour un équilibre entre la sécurité et la performance. Utilisez toujours subtle.ConstantTimeCompare() lors de la comparaison de hachages de mots de passe afin de prévenir les attaques par temporisation. Voir https://pkg.go.dev/golang.org/x/crypto/blake2b et la feuille de triche de l'OWASP sur le stockage des mots de passe à https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

OWASP :

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

go_blocklist_rule-blocklist-rc4¶

Résumé :

Utilisation d'un algorithme cryptographique brisé ou risqué

Gravité : Moyenne

CWE : CWE-327

Description :

L'application importe crypto/rc4 qui fournit l'algorithme de chiffrement de flux RC4. RC4 présente plusieurs faiblesses cryptographiques, y compris des biais dans son flux de clés qui permettent des attaques pratiques, en particulier dans des protocoles comme WEP et les premières versions de TLS. L'algorithme a été prohibé pour une utilisation dans TLS par la RFC 7465 en 2015 en raison de ces vulnérabilités. L'utilisation de rc4.NewCipher() expose les données chiffrées à des attaques statistiques pouvant récupérer le texte en clair, surtout lorsque de grandes quantités de données sont chiffrées avec la même clé.

Remédiation :

Envisagez de remplacer RC4 par des algorithmes de chiffrement authentifiés modernes qui offrent à la fois protection de la confidentialité et intégrité. L'approche recommandée est d'utiliser chacha20poly1305.NewX() de golang.org/x/crypto/chacha20poly1305, qui offre une performance supérieure sur la plupart des plateformes et utilise des nonces de 192 bits, réduisant considérablement le risque de réutilisation des nonces. Pour les environnements nécessitant une compatibilité AES, cipher.NewGCM() avec une clé de 32 octets fournit AES-256-GCM, bien que cela nécessite une gestion stricte des nonces, car la réutilisation d'un nonce même une seule fois avec la même clé compromet complètement la sécurité. Lors de la migration depuis RC4, assurez-vous d'une génération de clés appropriée en utilisant io.ReadFull(rand.Reader, key) et ne réutilisez jamais les nonces au cours des opérations de chiffrement. Des exemples complets de migration sont disponibles sur https://pkg.go.dev/golang.org/x/crypto/chacha20poly1305#NewX et https://pkg.go.dev/crypto/cipher#NewGCM pour les deux alternatives recommandées.

OWASP :

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

go_blocklist_rule-blocklist-sha1¶

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Gravité : Moyenne

CWE : CWE-327

Description :

L'application importe crypto/sha1 qui fournit l'algorithme de hachage SHA-1.
SHA-1 a été cryptographiquement compromis avec des attaques par collision pratiques démontrées publiquement par Google et CWI Amsterdam en 2017 (attaque SHAttered), permettant la création de deux entrées différentes produisant le même résultat de hachage. Utiliser sha1.New() ou sha1.Sum() pour tout objectif de sécurité tel que les signatures numériques, la validation de certificats ou les vérifications d'intégrité est dangereux. SHA-1 a été déprécié par le NIST en 2011 et devrait être remplacé dans toutes les applications cryptographiques.

Remédiation :

Envisagez de migrer vers des algorithmes de hachage résistants aux collisions des familles SHA-3 ou BLAKE2. Pour le hachage cryptographique général de fichiers ou l'intégrité des données, il est recommandé d'utiliser blake2b.New512() de golang.org/x/crypto/blake2b, qui offre de meilleures marges de sécurité et des performances supérieures par rapport au SHA-2. Pour les signatures numériques, SHA-256 du paquet de la bibliothèque standard crypto/sha256 offre une sécurité adéquate, bien que BLAKE2 soit préféré pour les nouvelles implémentations. Pour le hachage de mots de passe spécifiquement, envisagez d'utiliser argon2.IDKey() de golang.org/x/crypto/argon2 ou bcrypt.GenerateFromPassword() de golang.org/x/crypto/bcrypt, car ces fonctions de dérivation de clé nécessitant de la mémoire résistent aux attaques par force brute basées sur le GPU. Lors de l’implémentation d'Argon2id, les paramètres recommandés sont mémoire=64Mo, itérations=3 et parallélisme=2. Utilisez toujours subtle.ConstantTimeCompare() lors de la vérification des hachages de mots de passe pour éviter les canaux de temps. Voir https://pkg.go.dev/golang.org/x/crypto/blake2b et la feuille de triche de stockage des mots de passe d'OWASP à https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

OWASP :

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

go_crypto_rule-badtlssettings¶

Résumé :

Utilisation d'un algorithme cryptographique défectueux ou risqué

Gravité : Moyenne

CWE : CWE-327

Description :

L'application configure tls.Config ou tls.CipherSuite avec des suites de chiffrement cryptographiquement faibles qui n'apparaissent pas dans la liste recommandée de ciphers sécurisés par Go. Les suites de chiffrement faibles sont vulnérables à diverses attaques, y compris celles qui compromettent la confidentialité ou permettent des attaques de rétrogradation vers des protocoles plus faibles. Les suites de chiffrement modernes doivent prendre en charge la confidentialité parfaite des transmissions futures (PFS) pour garantir que les transmissions cryptées passées ne peuvent pas être décryptées même si le certificat TLS est compromis. Sans PFS, la compromission de la clé privée d'un serveur permettrait aux attaquants de déchiffrer tout le trafic capturé précédemment.

Remédiation :

Envisagez de mettre à niveau toutes les connexions TLS pour utiliser TLS 1.3 en définissant MinVersion: tls.VersionTLS13 dans votre tls.Config. En utilisant TLS 1.3, Go sélectionne automatiquement la suite de chiffrement la plus sécurisée lors de l'établissement de la connexion, et toutes les suites de chiffrement TLS 1.3 prennent intrinsèquement en charge la confidentialité parfaite des transmissions futures. Si vous devez prendre en charge TLS 1.0-1.2 pour des clients hérités, configurez explicitement le champ CipherSuites pour n'inclure que des ciphers activés PFS : tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, et tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305. Définissez MinVersion: tls.VersionTLS12 au minimum pour désactiver les versions dépréciées TLS 1.0 et 1.1. Pour plus d'informations sur les suites de chiffrement dans Go, consultez https://go.dev/blog/tls-cipher-suites

OWASP :

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

go_crypto_rule-insecure-ignore-host-key¶

Résumé :

Échange de clés sans authentification d'entité

Sévérité : Moyenne

CWE : CWE-322

Description :

L'application utilise ssh.InsecureIgnoreHostKey() du paquet golang.org/x/crypto/ssh, ce qui désactive la vérification des clés hôtes SSH. La vérification des clés hôtes est un mécanisme de sécurité essentiel qui authentifie l'identité du serveur SSH et prévient les attaques de type « homme du milieu ». Lorsque les clés hôtes sont ignorées, les clients ne peuvent pas valider qu'ils se connectent au serveur prévu, permettant ainsi aux attaquants d'intercepter la connexion et de capturer des informations d'identification ou d'injecter des commandes malveillantes. Cela équivaut à ignorer la validation des certificats dans les connexions HTTPS et compromet totalement les garanties de sécurité de SSH.

Remédiation :

Envisagez d'utiliser le paquet golang.org/x/crypto/ssh/knownhosts pour la propriété HostKeyCallback dans votre ssh.ClientConfig. La fonction knownhosts.New() analyse le format de fichier standard known_hosts d'OpenSSH et fournit un callback qui valide les clés hôtes du serveur par rapport à des entrées de confiance. Cette approche maintient la compatibilité avec les outils SSH standard et offre les mêmes garanties de sécurité que les clients OpenSSH. Lors de la connexion à des serveurs pour la première fois, utilisez knownhosts.New() associé à une vérification correcte des clés hôtes via un canal hors bande plutôt que d'accepter aveuglément des clés inconnues. Pour les systèmes automatisés, pré-remplissez le fichier known_hosts avec des clés hôtes vérifiées lors du déploiement. Plus de détails disponibles sur https://pkg.go.dev/golang.org/x/crypto/ssh/knownhosts

OWASP :

A2:2017-Autentification Brisée
A07:2021-Failles d'Identification et d'Authentification

go_crypto_rule-tlsversion¶

Résumé :

Utilisation d'une version TLS obsolète

Sévérité : Moyenne

CWE : CWE-310

Description :

L'application configure tls.Config avec MinVersion défini sur tls.VersionTLS10 ou tls.VersionTLS11, ou définit MaxVersion sans spécifier une version minimale. Les versions TLS 1.0 et 1.1 ont été formellement dépréciées par l'IETF dans le RFC 8996 (mars 2021) en raison de nombreuses faiblesses cryptographiques, y compris des vulnérabilités aux attaques BEAST, CRIME et POODLE. Les principaux navigateurs et les normes de sécurité comme le PCI DSS ont interdit ces versions depuis 2020. L'utilisation de versions TLS dépréciées expose les connexions chiffrées aux attaques de dégradation et permet aux adversaires d'exploiter des vulnérabilités connues au niveau du protocole, ce qui peut conduire à un accès non autorisé à des données sensibles transmises sur la connexion.

Remédiation :

Envisagez de configurer toutes les instances de tls.Config avec MinVersion: tls.VersionTLS13 pour imposer TLS 1.3, qui offre les meilleures garanties de sécurité et sélectionne automatiquement des suites de chiffrement sécurisées avec Perfect Forward Secrecy. TLS 1.3 améliore également les performances en réduisant le nombre d'allers-retours lors de l'établissement de la connexion. Si vous devez prendre en charge des clients hérités qui ne supportent pas TLS 1.3, définissez MinVersion: tls.VersionTLS12 comme un minimum absolu, car TLS 1.2 est actuellement la plus ancienne version acceptable. Évitez de définir MaxVersion sauf si vous avez une exigence spécifique de compatibilité, car cela empêche la mise à niveau vers des versions de protocole plus récentes et plus sécurisées. Lors de l'utilisation de TLS 1.2, assurez-vous également de configurer des suites de chiffrement sécurisées qui supportent Perfect Forward Secrecy. Pour plus d'informations, consultez https://go.dev/blog/tls-cipher-suites

OWASP :

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

go_crypto_rule-weakkeystrength¶

Résumé :

Force de chiffrement inadéquate

Gravité : Moyenne

CWE : CWE-326

Description :

L'application appelle rsa.GenerateKey() du paquet crypto/rsa avec une taille de clé inférieure à 2048 bits. Le NIST a déprécié les clés RSA de 1024 bits pour les signatures numériques en décembre 2010, et des normes de sécurité telles que PCI DSS exigent une taille minimum de 2048 bits. Bien que les clés de 1024 bits n'aient pas encore été publiquement factorisées, les avancées continues en puissance de calcul et en techniques cryptanalytiques rendent la factorisation de plus en plus réalisable. La factorisation réussie d'une clé privée RSA permet aux attaquants de falsifier des signatures, de déchiffrer des données chiffrées et de compromettre complètement les systèmes reposant sur cette paire de clés pour l'authentification ou la confidentialité.

Remédiation :

Envisagez de générer des clés RSA d'une taille minimale de 2048 bits en passant 2048 ou plus comme deuxième paramètre à rsa.GenerateKey(). Pour les nouvelles applications avec des exigences de sécurité élevées, utilisez des clés de 3072 bits ou 4096 bits pour une sécurité à long terme, bien que notez que des clés plus grandes augmentent la surcharge computationnelle pour les opérations de signature et de vérification. Alternativement, envisagez de migrer vers la cryptographie par courbes elliptiques en utilisant le paquet crypto/ecdsa avec les courbes P-256 ou P-384, qui fournissent une sécurité équivalente à celle des clés RSA de 3072 bits et 7680 bits respectivement, tout en nécessitant des tailles de clé significativement plus petites et des opérations plus rapides. Lors de la génération de clés, utilisez toujours crypto/rand comme source aléatoire, jamais math/rand.

OWASP :

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

go_crypto_rule-weakrandsource¶

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 le paquet math/rand pour générer des nombres aléatoires dans un contexte où crypto/rand n'est pas également importé. Le paquet math/rand implémente un générateur de nombres pseudo-aléatoires (PRNG) déterministe qui n'est pas sécurisé sur le plan cryptographique. Les valeurs aléatoires générées par math/rand sont prévisibles si un attaquant peut observer ou deviner la valeur de la graine, et le paquet documente explicitement qu'il ne doit pas être utilisé pour des applications sensibles à la sécurité. Utiliser math/rand pour des jetons de session, des clés cryptographiques, des jetons de réinitialisation de mot de passe ou tout identifiant critique pour la sécurité peut permettre aux attaquants de prédire des valeurs futures et de compromettre les mécanismes d'authentification ou d'autorisation.

Remédiation :

Envisagez de remplacer tous les imports de math/rand par crypto/rand pour toute génération de nombres aléatoires sensible à la sécurité. Le paquet crypto/rand fournit des nombres aléatoires sécurisés sur le plan cryptographique en lisant à partir de la source aléatoire sécurisée du système d'exploitation (par exemple, /dev/urandom sur les systèmes Unix). Utilisez crypto/rand.Read() pour remplir des tranches d'octets avec des données aléatoires, ou crypto/rand.Int() pour des entiers aléatoires dans une plage spécifique. Notez que crypto/rand a une API différente de celle de math/rand et nécessite un traitement d'erreurs explicite car elle peut échouer si la source d'entropie du système est indisponible. Il est acceptable d'utiliser math/rand pour des fins non liées à la sécurité, comme les simulations statistiques ou la logique de jeu, mais dans ces cas, assurez-vous que le code documente clairement pourquoi la randomité cryptographique n'est pas nécessaire.

OWASP :

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

go_file-permissions_rule-fileperm¶

Résumé :

Attribution incorrecte des permissions pour une ressource critique

Sévérité : Moyenne

CWE : CWE-732

Description :

Les permissions de fichiers définies à l'aide de os.Chmod(), os.OpenFile(), ou os.WriteFile() sont trop permissives (supérieures à 0640). Cela permet à des utilisateurs ou processus non autorisés de lire, modifier ou exécuter des fichiers sensibles, ce qui peut conduire à des divulgations d'informations, à des falsifications de données ou à une élévation de privilèges.

Remédiation :

Envisagez d'utiliser des permissions de fichiers restrictives qui limitent l'accès uniquement à l'utilisateur de l'application lorsque cela est possible : 0400 pour un accès en lecture seule, 0200 pour un accès en écriture seule, ou 0600 pour un accès lecture/écriture. Il est recommandé d'éviter des permissions comme 0777 ou 0666 qui accordent l'accès à tous les utilisateurs. Si l'accès au groupe ou au monde est requis, évaluez soigneusement les implications de sécurité et utilisez les permissions minimales nécessaires telles que 0640 (propriétaire lecture/écriture, groupe lecture) ou 0440 (propriétaire et groupe en lecture seule).

OWASP :

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

go_file-permissions_rule-mkdir¶

Résumé :

Attribution incorrecte des permissions pour une ressource critique

Gravité : Moyenne

CWE : CWE-732

Description :

Des permissions de répertoire trop permissives ont été détectées dans les appels à os.Mkdir() ou os.MkdirAll(). Définir des permissions supérieures à 0750 permet à des utilisateurs non autorisés d'accéder, de modifier ou de supprimer le contenu du répertoire. Cela peut entraîner une violation de la confidentialité, une élévation de privilèges ou une altération des données par des attaquants locaux.

Remédiation :

Envisagez de restreindre les permissions de répertoire pour limiter l'accès. Utilisez 0700 (octal) pour un accès en lecture/écriture/exécution uniquement pour le propriétaire lorsque l'utilisateur de l'application est le seul à y accéder. Utilisez 0750 pour accorder au propriétaire un accès complet tout en permettant aux membres du groupe des permissions de lecture et d'exécution. Approche recommandée : err := os.Mkdir("directory", 0700) ou err := os.MkdirAll("path/to/directory", 0700). Pour plus de détails sur les valeurs de permissions, consultez : File-system_permissions

OWASP :

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

go_filesystem_rule-decompression-bomb¶

Résumé :

Gestion inappropriée des données fortement compressées

Sévérité : Moyenne

CWE : CWE-409

Description :

L'application utilise des fonctions de décompression telles que gzip.NewReader(), zlib.NewReader(), bzip2.NewReader(), flate.NewReader(), lzw.NewReader(), tar.NewReader(), ou zip.NewReader() de la bibliothèque standard sans imposer de limites sur la taille de la sortie décompressée. Cela crée une vulnérabilité aux attaques par bombes de décompression où des fichiers compressés malveillamment conçus s'étendent à des tailles extrêmement grandes, pouvant potentiellement entraîner l'épuisement de la mémoire ou le remplissage de l'espace disque, entraînant un déni de service (DoS).

Remédiation :

Envisagez d'encapsuler les lecteurs de décompression avec io.LimitReader() pour imposer une limite maximale sur la taille de la sortie décompressée avant de copier ou de traiter les données. La limite devrait être basée sur les exigences de taille de fichier maximale attendue de votre application. Par exemple, si vous traitez des journaux compressés téléchargés par des utilisateurs qui ne devraient jamais dépasser 10 Mo une fois décompressés, définissez la limite en conséquence. La règle détecte les utilisations non protégées de io.Copy() et io.CopyBuffer() avec des lecteurs de décompression de paquets tels que compress/gzip, compress/zlib, compress/bzip2, compress/flate, compress/lzw, et archive/tar ou archive/zip. Il est recommandé de valider à la fois les tailles compressées et décompressées, et d'envisager la mise en œuvre de safeguard additionnels tels que des délais d'attente pour les opérations de décompression afin de prévenir les attaques par épuisement de ressources.

OWASP :

A1:2017-Injection
A03:2021-Injection

go_filesystem_rule-fileread¶

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 construit dynamiquement des chemins de fichiers et les transmet à des fonctions d'E/S de fichiers telles que os.Open(), os.OpenFile(), os.ReadFile(), ou ioutil.ReadFile(). Lorsque les informations de chemin proviennent de sources contrôlées par l'utilisateur, comme les paramètres de requête HTTP (http.Request.FormValue(), http.Request.URL), les variables d'environnement (os.Getenv()), ou la concaténation de chaînes avec des données non fiables, cela crée des vulnérabilités de traversée de chemin (CWE-22). Les attaquants peuvent exploiter cela en injectant des séquences comme ../ pour accéder à des fichiers en dehors du répertoire prévu, pouvant potentiellement lire des fichiers de configuration sensibles, des identifiants ou des données d'autres utilisateurs.

Remédiation :

Envisagez de mettre en œuvre une approche de défense en profondeur pour prévenir les attaques de traversée de chemin. Il est conseillé d'éviter complètement d'utiliser les entrées utilisateur dans les chemins de fichiers en mappant les noms de fichiers fournis par les utilisateurs à des identifiants générés aléatoirement stockés dans une base de données. Lorsque l'entrée utilisateur doit être incorporée, utilisez filepath.Base() pour extraire uniquement le composant du nom de fichier sans informations sur le répertoire, puis joignez-le avec un répertoire de base codé en dur en utilisant filepath.Join(). Validez toujours que le chemin résolu commence avec votre répertoire de base prévu en utilisant strings.HasPrefix() après avoir appelé filepath.Clean() pour normaliser le chemin. La règle détecte les flux de contamination provenant de sources telles que les champs http.Request, os.Getenv(), et les opérations de chaînes vers des puits d'E/S de fichiers, et reconnaît l'assainissement par le biais de filepath.Clean() combiné avec la validation de préfixe. Pour une sécurité supplémentaire, envisagez d'utiliser des prisons chroot ou la conteneurisation pour limiter l'accès au système de fichiers au niveau du système d'exploitation.

OWASP :

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

go_filesystem_rule-httprootdir¶

Résumé :

Fichiers ou répertoires accessibles aux parties externes

Gravité : Moyenne

CWE : CWE-552

Description :

L'application utilise http.Dir("/") pour créer un gestionnaire de serveur de fichiers qui monte le répertoire racine du système de fichiers. Combinée avec http.FileServer() et servie via HTTP, cette configuration expose l'ensemble du système de fichiers à tout client capable d'atteindre le point de terminaison HTTP. Les attaquants peuvent potentiellement accéder à tout fichier que le processus du serveur HTTP a la permission de lire, y compris des fichiers système sensibles comme /etc/passwd, /etc/shadow, des fichiers de configuration d'application contenant des identifiants, des clés privées ou des chaînes de connexion à la base de données.

Remédiation :

Envisagez de restreindre http.Dir() pour ne servir que des fichiers d'un répertoire d'application spécifique contenant uniquement des ressources publiques destinées à être servies sur le web, telles que /var/www/html/public ou /app/static. Il est recommandé de créer une structure de répertoire dédiée qui isole le contenu web public du code d'application, des fichiers de configuration et des données sensibles. Lors de l'utilisation de http.FileServer() avec http.Dir(), assurez-vous que le chemin pointe vers un sous-répertoire restreint et non des répertoires système. De plus, envisagez de mettre en œuvre un middleware d'authentification et d'autorisation avant le gestionnaire de serveur de fichiers pour contrôler l'accès aux fichiers statiques. Pour les déploiements en production, il est recommandé d'utiliser un proxy inverse comme nginx ou un CDN pour servir des fichiers statiques plutôt que de les servir directement depuis votre application Go, ce qui offre de meilleures performances et une isolation de sécurité.

OWASP :

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

go_filesystem_rule-poorwritepermissions¶

Résumé :

Permissions par défaut incorrectes

Gravité : Moyenne

CWE : CWE-276

Description :

L'application utilise ioutil.WriteFile() avec des modes de permission de fichier supérieurs à 0600 (octal), accordant des permissions excessives aux fichiers créés. Lorsque les permissions dépassent 0600, le fichier devient lisible ou modifiable par les membres du groupe ou d'autres utilisateurs du système au-delà du propriétaire du fichier. Cela viole le principe du moindre privilège et peut exposer des données sensibles à des utilisateurs locaux non autorisés, en particulier dans des environnements d'hébergement partagé ou des systèmes multi-tenant où différentes applications s'exécutent sous différents comptes d'utilisateurs sur le même serveur.

Remédiation :

Envisagez d'utiliser des permissions de fichier restrictives qui limitent l'accès uniquement au propriétaire du fichier lors de l'écriture de fichiers avec os.WriteFile() ou ioutil.WriteFile(). Les valeurs de permission recommandées sont 0400 (lecture seule), 0200 (écriture seule) ou 0600 (lecture-écriture) pour les fichiers qui ne devraient être accessibles que par l'utilisateur de l'application. Pour les fichiers qui doivent être partagés avec un groupe spécifique, utilisez 0640 (propriétaire lecture-écriture, groupe lecture seule) plutôt que des permissions lisibles par tous. La règle détecte les modes de permission supérieurs à 0o600 en notation octale passés à ioutil.WriteFile(). Lors du stockage de données sensibles telles que des informations d'identification, des clés privées, des jetons de session ou des clés API, utilisez toujours 0600 ou des permissions plus restrictives. Pour les fichiers de configuration, envisagez 0640 s'ils nécessitent un accès de groupe, mais n'utilisez jamais de modes lisibles par tous comme 0644 ou 0666 pour du contenu sensible.

OWASP :

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

go_filesystem_rule-tempfiles¶

Résumé :

Création de fichiers temporaires avec des permissions non sécurisées

Sévérité : Moyenne

CWE : CWE-378

Description :

L'application crée des fichiers dans des répertoires temporaires système partagés (/tmp ou /var/tmp) en utilisant des chemins prévisibles avec os.WriteFile(), ioutil.WriteFile(), os.OpenFile() avec os.O_CREATE, ou os.Create() au lieu d'utiliser os.CreateTemp(). Cela crée une vulnérabilité de condition de course de type time-of-check-time-of-use (TOCTOU) où un attaquant ayant un accès local peut prédire le chemin du fichier et créer un lien symbolique à cet emplacement avant que l'application n'y écrive. Cela peut entraîner des écrasements de fichiers arbitraires avec les privilèges de l'application, ce qui peut potentiellement mener à une élévation de privilèges ou à des attaques par déni de service.

Remédiation :

Envisagez d'utiliser os.CreateTemp() qui crée des fichiers temporaires avec des noms imprévisibles et des permissions sécurisées (0600) qui ne sont accessibles qu'au propriétaire du fichier. Il est recommandé de créer des fichiers temporaires dans un répertoire spécifique à l'application plutôt que dans des répertoires système partagés comme /tmp ou /var/tmp. Par exemple, créez un répertoire sous /opt/appdir/temp avec des permissions restrictives (0700) détenu par l'utilisateur de l'application, puis passez ce chemin comme premier argument à os.CreateTemp(). La fonction génère automatiquement des noms de fichiers uniques en utilisant des suffixes aléatoires cryptographiquement, éliminant ainsi les conditions de course TOCTOU. N'oubliez pas de différer os.Remove() après la création du fichier pour garantir le nettoyage. La règle détecte les chemins codés en dur correspondant aux motifs /tmp/ ou /var/tmp/ passés aux fonctions de création de fichiers. Pour une sécurité supplémentaire dans les environnements conteneurisés, envisagez de monter des répertoires temporaires sur des systèmes de fichiers séparés avec les drapeaux noexec et nosuid.

OWASP :

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

go_filesystem_rule-ziparchive¶

Résumé :

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

Sévérité : Moyenne

CWE : CWE-22

Description :

L'application extrait des fichiers d'archive en utilisant zip.OpenReader() ou tar.OpenReader() et transmet les chemins de fichiers de l'archive à filepath.Join() sans validation appropriée. Cela crée une vulnérabilité "Zip Slip" où des archives malicieusement conçues peuvent inclure des entrées de fichiers avec des séquences de traversal de chemin comme ../../etc/passwd qui, lorsqu'elles sont extraites, écrivent des fichiers en dehors du répertoire de destination prévu. Les attaquants peuvent en profiter pour écraser des fichiers système critiques, des configurations d'application ou du code exécutable, menant potentiellement à une exécution de code à distance ou à une élévation de privilèges. La vulnérabilité est particulièrement dangereuse car les noms de fichiers d'archive sont entièrement contrôlés par l'attaquant et filepath.Join() à lui seul ne prévient pas le traversal de répertoire.

Remédiation :

Envisagez d'implémenter plusieurs couches de validation lors de l'extraction de fichiers d'archive. Il est recommandé d'utiliser filepath.Clean() pour normaliser les chemins de l'archive, puis de les combiner avec votre répertoire de base en utilisant filepath.Join(), et enfin de valider que le chemin résolu commence par votre répertoire de base prévu en utilisant strings.HasPrefix(). De plus, utilisez filepath.Base() pour extraire uniquement le nom de fichier sans composants de répertoire si vous n'avez pas besoin de conserver la structure des répertoires. La règle reconnaît ce modèle de désinfection lorsque filepath.Clean() ou path.Clean() est combiné avec la validation de préfixe. Au-delà de la validation des chemins, envisagez de limiter la taille non compressée des fichiers pour prévenir les bombes de décompression, de valider les limites de nombre de fichiers et d'utiliser file.Mode().IsRegular() pour ignorer les liens symboliques qui pourraient pointer vers des fichiers système arbitraires. Pour une sécurité maximale, il est recommandé de générer des noms de fichiers aléatoires au lieu d'utiliser les noms fournis par l'archive, et d'extraire dans un répertoire spécifique à l'application avec des permissions restreintes plutôt que dans des répertoires système.

OWASP :

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

go_injection_rule-ssrf¶

Résumé :

Falsification de requête côté serveur (SSRF)

Sévérité : Moyenne

CWE : CWE-918

Description :

Cette règle a détecté des entrées contrôlées par l'utilisateur provenant des paramètres de requête HTTP, des variables d'environnement ou de l'entrée standard, circulant vers les fonctions clients HTTP de Go, y compris http.Get(), http.Post(), http.Head(), http.PostForm(), http.NewRequest(), http.NewRequestWithContext(), et des bibliothèques tierces comme ftp.Dial(), ldap.DialURL(), smtp.Dial(), et retryablehttp.NewRequest(). L'analyse de la contamination suit les sources de données non fiables à travers les décodeurs et désérialiseurs jusqu'aux points de demande réseau. Lorsque l'entrée utilisateur contrôle les URLs ou les paramètres de connexion sans validation, des vulnérabilités de Falsification de requête côté serveur (SSRF) émergent, permettant aux attaquants de forcer le serveur à accéder à des ressources internes, à des points d'accès de métadonnées cloud (169.254.169.254) ou à des systèmes arbitraires, exposant potentiellement des APIs sensibles, réalisant des reconnaissances réseau, ou contournant des règles de pare-feu et de segmentation réseau.

Remédiation :

Envisagez de mettre en œuvre une liste blanche stricte d'URLs qui valide l'entrée utilisateur par rapport à des domaines approuvés en utilisant url.Parse() de Go pour extraire et valider les composants de schéma, d'hôte et de port avant d'effectuer des requêtes. Restreignez les protocoles autorisés uniquement à http:// et https://, en rejetant explicitement les schémas dangereux. Implémentez une protection contre le rebinding DNS en créant un http.Transport personnalisé avec une fonction DialContext qui résout les noms d'hôtes en utilisant net.LookupIP() et bloque les connexions aux plages d'IP privées (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) et aux adresses de métadonnées cloud (169.254.169.254) en vérifiant si les IP résolues sont privées, de boucle locale, multicast ou non spécifiées, en utilisant des méthodes comme ip.IsPrivate() et ip.IsLoopback(). Configurez les clients HTTP avec des transports personnalisés qui appliquent ces restrictions au niveau du réseau. Désactivez ou validez strictement les redirections HTTP en utilisant http.Client.CheckRedirect pour empêcher les contournements SSRF basés sur les redirections. Les défenses au niveau réseau peuvent inclure l'exécution de l'application avec des privilèges utilisateurs restreints ou dans des segments de réseau isolés avec des règles iptables ou de pare-feu. Envisagez de diriger toutes les requêtes sortantes à travers un proxy de sortie surveillé. Utilisez une approche de mappage côté serveur où l'entrée utilisateur fournit des clés qui correspondent à des URLs sûres préconfigurées. Pour plus d'informations, consultez OWASP : Falsification_de_Requête_Côté_Serveur

OWASP :

A1:2017-Injection
A10:2021-Falsification de requête côté serveur

go_injection_rule-template-injection¶

Résumé :

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

Gravité : Moyenne

CWE : CWE-79

Description :

Vulnérabilité d'injection de template détectée dans template.HTML(), template.JS(), template.URL(), ou template.HTMLAttr() avec une entrée non constante. Ces fonctions contournent l'échappement HTML automatique de Go, permettant à l'entrée utilisateur d'être interprétée comme une balise ou du code script. Cela peut conduire à des attaques de Cross-Site Scripting (XSS) où les attaquants injectent du JavaScript malveillant qui s'exécute dans les navigateurs des victimes.

Remédiation :

Envisagez d'éviter complètement template.HTML(), template.JS(), template.URL(), et template.HTMLAttr() avec des entrées contrôlées par l'utilisateur. Si ces types doivent être utilisés, il est recommandé de ne passer que des chaînes constantes codées en dur qui sont définies au moment de la compilation. Le package html/template de Go échappe automatiquement les valeurs, donc le rendu normal de template sans ces fonctions de contournement fournit une sortie sécurisée. Si un contenu dynamique est nécessaire, validez et assainissez l'entrée utilisateur en utilisant des listes d'autorisation strictes.

OWASP :

A1:2017-Injection
A03:2021-Injection

go_leak_rule-pprof-endpoint¶

Résumé :

Code de débogage actif (pprof activé)

Gravité : Moyenne

CWE : CWE-489

Description :

Point de profilage /debug/pprof exposé via l'importation net/http/pprof. Ce point de terminaison ne nécessite pas d'authentification et peut être accessible par des utilisateurs anonymes, pouvant fuir des informations sensibles sur l'application, des contenus en mémoire, des informations sur les goroutines, et des données de performance. Cela ne devrait pas être activé dans les environnements de production.

Remédiation :

Envisagez de supprimer l'importation net/http/pprof du code de production pour désactiver complètement le point de profilage. Si le profilage est nécessaire en production pour le débogage, il est recommandé de mettre en œuvre des contrôles d'authentification et d'autorisation avant de permettre l'accès aux points de terminaison /debug/pprof. Alternativement, envisagez de servir pprof sur un port interne séparé qui n'est pas exposé à l'extérieur et est uniquement accessible depuis des réseaux de confiance.

OWASP :

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

go_memory_rule-integer-overflow¶

Résumé :

Dépassement d'entier ou retour arrière

Sévérité : Moyenne

CWE : CWE-190

Description :

Un dépassement d'entier a été détecté lors de la conversion de la valeur de retour de strconv.Atoi() en types plus petits (int32 ou int16). Le type int de Go dépend de l'architecture (32 bits ou 64 bits), mais la conversion en types de taille fixe sans validation peut entraîner un débordement. Cela peut conduire à un comportement inattendu de l'application, tel que des calculs incorrects, des erreurs logiques ou des vulnérabilités de sécurité.

Remédiation :

Envisagez de valider la valeur retournée par strconv.Atoi() avant d'effectuer la conversion de type vers des types entiers plus petits. Vérifiez que la valeur s'inscrit dans la plage du type cible en la comparant aux constantes math.MaxInt16 ou math.MaxInt32. Si la valeur dépasse le maximum (ou est en dessous du minimum), gérez l'erreur de manière appropriée plutôt que de tronquer silencieusement. Pour plus d'informations, voir : math

OWASP :

A1:2017-Injection
A03:2021-Injection

go_http_rule-http-serve¶

Résumé :

Allocation de ressources sans limites ni limitation

Sévérité : Faible

CWE : CWE-770

Description :

Un serveur HTTP créé en utilisant http.ListenAndServe(), http.ListenAndServeTLS(), http.Serve(), http.ServeTLS(), ou http.Server{} sans configuration de timeout est vulnérable aux attaques de consommation de ressources. Un adversaire peut ouvrir des milliers de connexions sans compléter les requêtes ou terminer les connexions, ce qui peut provoquer une déni de service en épuisant les ressources du serveur.

Remédiation :

Considérez éviter les fonctions par défaut http.ListenAndServe() et http.Serve() dans les environnements de production car elles ne peuvent pas avoir de timeouts configurés. Il est recommandé de créer un http.Server personnalisé avec des valeurs de timeout explicites : ReadHeaderTimeout (temps pour lire les en-têtes de requête), ReadTimeout (temps total pour lire la requête, y compris le corps), WriteTimeout (temps avant le timeout des écritures de réponse), et IdleTimeout (temps d'attente pour la prochaine requête avec keep-alives). Pour une protection supplémentaire, envisagez d'utiliser http.TimeoutHandler pour définir des timeouts par requête au niveau du gestionnaire.

OWASP :

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

go_network_rule-bind-to-all-interfaces¶

Résumé :

Liaison à une adresse IP non restreinte

Gravité : Faible

CWE : CWE-1327

Description :

Liaison de service à toutes les interfaces réseau détectée. L'utilisation de net.Listen() ou tls.Listen() avec l'adresse "0.0.0.0" ou "[::]" lie à toutes les interfaces réseau disponibles, exposant potentiellement le service à des réseaux non intentionnés ou non sécurisés. Cela peut créer des risques de sécurité si le service ne doit être accessible que sur des interfaces spécifiques.

Remédiation :

Considérez la possibilité de spécifier une adresse IP d'interface réseau spécifique au lieu de lier à toutes les interfaces. Les approches recommandées incluent la récupération de l'adresse IP à partir d'une variable d'environnement (par exemple, os.Getenv("BIND_ADDRESS")), la lecture à partir d'un fichier de configuration, ou la détermination programmatique de l'adresse IP de l'interface principale. Cela garantit que le service n'écoute que sur des interfaces réseau sécurisées et intentionnées.

OWASP :

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

go_memory_rule-memoryaliasing¶

Résumé :

Accès incorrect à une ressource indexable ('Erreur de plage')

Sévérité : Info

CWE : CWE-118

Description :

Aliasing mémoire détecté dans la boucle for ... range. La variable d'itération est réutilisée pour chaque itération de la boucle, pointant toujours vers la même localisation mémoire. Prendre l'adresse de cette variable (&var) fait que toutes les références pointent vers la valeur finale de l'itération, entraînant un comportement inattendu lorsque les adresses sont stockées, passées à des fonctions ou utilisées dans des goroutines.

Remédiation :

Envisagez de corriger ce problème en utilisant l'une des trois approches : (1) éviter de prendre l'adresse de la variable d'itération complètement, (2) réaffecter la variable d'itération à une nouvelle variable locale à l'intérieur de la boucle (par exemple, tmp := iterVar), ou (3) utiliser l'adresse indexée de la collection originale (par exemple, &collection[idx]). Chaque approche garantit des adresses mémoire uniques pour chaque itération. Pour plus d'informations, voir : spécification

OWASP :

A6:2017-Mauvaise configuration de la sécurité
A05:2021-Mauvaise configuration de la sécurité