Règles Semgrep c, cpp¶
c_buffer_rule-gets--getts¶
Résumé :
Utilisation d'une fonction obsolète (gets)
Gravité : Élevée
CWE : CWE-120
Description :
La fonction gets() (et ses variantes à larges caractères _getts() et _getws()) lit une ligne depuis stdin dans le tampon fourni jusqu'à ce qu'un saut de ligne terminal ou EOF soit rencontré, le remplaçant par un octet nul. Ces fonctions ne vérifient pas les limites sur le tampon de destination, rendant les attaques par dépassement de tampon triviales à exécuter. La fonction gets() a été officiellement supprimée de la norme C11 en raison de ses risques de sécurité inhérents et de son incapacité à être utilisée en toute sécurité dans n'importe quelle situation.
Remédiation :
Envisagez de remplacer gets() par fgets(), qui accepte un paramètre de taille de tampon maximum pour prévenir les débordements. La fonction fgets() doit être appelée avec la taille du tampon comme deuxième paramètre, par exemple fgets(buffer, sizeof(buffer), stdin). Notez que fgets() conserve le caractère de saut de ligne si le tampon est suffisamment grand, vous devrez donc peut-être l'enlever manuellement. Pour lire des données binaires ou des entrées qui peuvent contenir des octets nuls, utilisez read() ou fread() à la place, car fgets() s'arrête au premier octet nul sur certaines plateformes. Pour le nouveau code en C, envisagez d'utiliser des alternatives plus sûres comme getline() sur les systèmes POSIX qui gèrent automatiquement l'allocation de tampon.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
c_buffer_rule-getwd¶
Résumé :
Protection insuffisante contre le débordement de tampon (getwd)
Sévérité : Élevée
CWE : CWE-120
Description :
La fonction getwd() récupère le chemin du répertoire de travail actuel mais n'accepte pas de paramètre de taille pour limiter le nombre de caractères pouvant être écrits dans le tampon de destination. Cela crée une vulnérabilité de débordement de tampon lorsque le chemin dépasse la taille du tampon, en particulier sur les systèmes avec des structures de répertoire profondes. La fonction a été dépréciée des normes POSIX et retirée des bibliothèques C modernes en raison de ces préoccupations de sécurité.
Remédiation :
Envisagez de migrer vers getcwd() qui accepte à la fois un pointeur vers le tampon et un paramètre de taille pour limiter en toute sécurité le nombre de caractères écrits. L'utilisation standard est getcwd(buffer, sizeof(buffer)) ce qui garantit que le chemin est tronqué s'il dépasse la taille du tampon. Pour une portabilité maximale, il est recommandé d'allouer au moins PATH_MAX octets pour le tampon, bien que sur certains systèmes, vous puissiez passer NULL comme paramètre de tampon pour que getcwd() alloue de la mémoire automatiquement (doit être libéré avec free()). La fonction getcwd() renverra NULL et définira errno à ERANGE si le tampon est trop petit, permettant une gestion d'erreur élégante.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
c_buffer_rule-scanf-vscanf¶
Résumé :
Les fonctions scanf() peuvent permettre des débordements de chaîne basés sur des chaînes de format.
Gravité : Élevée
CWE : CWE-120
Description :
La famille de fonctions scanf(), vscanf(), wscanf(), _tscanf() et vwscanf() peut provoquer des débordements de tampon lorsque des spécificateurs de format comme %s sont utilisés sans limitations de largeur de champ. Lorsqu'elles lisent des données de chaînes sans spécificateur de largeur, ces fonctions continueront à écrire dans le tampon de destination jusqu'à ce qu'un espace blanc soit rencontré ou que la fin de fichier (EOF) soit atteinte, indépendamment de la taille réelle du tampon. Cela les rend particulièrement dangereuses lors du traitement d'entrées non fiables, où un attaquant peut fournir des chaînes de longueur arbitraire pour faire déborder les tampons et potentiellement exécuter du code arbitraire.
Remédiation :
Envisagez d'utiliser des spécificateurs de largeur de champ dans tous les spécificateurs de format de chaîne pour limiter les écritures dans le tampon, par exemple scanf("%10s", buffer) lira au maximum 10 caractères plus un terminateur nul dans un tampon de 11 octets. Il est recommandé de calculer la largeur comme sizeof(buffer)-1 pour laisser de la place pour le terminateur nul. Pour le développement avec la bibliothèque d'exécution C de Microsoft (CRT), utilisez les versions sécurisées suffixées par _s comme scanf_s() qui nécessitent des tailles de tampon explicites et fournissent une vérification des bornes à l'exécution. Pour une gestion d'entrée plus robuste, envisagez d'utiliser fgets() suivi de sscanf(), ce qui vous permet de contrôler la longueur de la ligne d'entrée séparément de l'analyse, ou utilisez getline() sur les systèmes POSIX pour une gestion automatique des tampons.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
c_format_rule-fprintf-vfprintf¶
Résumé :
Vulnérabilité potentielle de chaîne de format
Sévérité : Élevée
CWE : CWE-134
Description :
L'application utilise fprintf(), vfprintf(), _ftprintf(), fwprintf(),
ou fvwprintf() avec un argument de chaîne de format non constant. Les vulnérabilités de chaîne de format permettent à un attaquant de lire ou, dans certains cas, d'écrire des données depuis et vers des emplacements dans la mémoire du processus. Lorsque des entrées contrôlées par l'utilisateur ou non fiables sont passées directement comme spécification de format à ces fonctions, les attaquants peuvent utiliser des spécificateurs de format comme %x, %n, et %s pour divulguer des informations sensibles de la pile ou écrire des données arbitraires dans des emplacements mémoire.
Remédiation :
Envisagez d'utiliser un littéral de chaîne constant pour la spécification de format au lieu d'accepter des entrées contrôlées par l'utilisateur ou non fiables. Si des chaînes de format dynamiques sont nécessaires, il est recommandé de mettre en œuvre une validation stricte qui n'autorise que des caractères spécifiques sûrs et supprime complètement les spécificateurs de format comme %x, %n, %s, et %p. Pour la journalisation des données fournies par l'utilisateur, envisagez d'utiliser des alternatives sûres comme fputs() qui n'interprètent pas les spécificateurs de format. Lors de l'appel à fprintf() ou des fonctions connexes, utilisez toujours une chaîne de format fixe telle que fprintf(fd, "%s", user_data) plutôt que fprintf(fd, user_data). Le drapeau de compilateur -Wformat-security peut aider à détecter les cas où des chaînes de format non littérales sont utilisées sans arguments appropriés.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
c_format_rule-printf-vprintf¶
Résumé :
Vulnérabilité potentielle due aux chaînes de format
Gravité : Élevée
CWE : CWE-134
Description :
L'application utilise printf(), vprintf(), vwprintf(), vfwprintf(),
_vtprintf(), ou wprintf() avec un argument de chaîne de format non constant.
Les vulnérabilités liées aux chaînes de format permettent à un attaquant de lire ou, dans certains cas, d'écrire des données à partir de localisations dans la mémoire du processus. Lorsque des entrées contrôlées par l'utilisateur ou non fiables sont transmises directement comme spécification de format à ces fonctions, les attaquants peuvent utiliser des spécificateurs de format comme %x, %n et %s pour divulguer des informations sensibles de la pile ou écrire des données arbitraires dans des emplacements mémoire.
Remédiation :
Envisagez d'utiliser une chaîne littérale constante pour la spécification de format au lieu d'accepter des entrées contrôlées par l'utilisateur ou non fiables. Si des chaînes de format dynamiques sont nécessaires, il est recommandé de mettre en œuvre une validation stricte qui n'autorise que des caractères sûrs spécifiques et retire complètement les spécificateurs de format comme %x, %n, %s et %p. Pour l'impression de données fournies par l'utilisateur, envisagez d'utiliser des alternatives sûres comme puts() qui n'interprètent pas les spécificateurs de format. Lors de l'appel de printf() ou de fonctions associées, utilisez toujours une chaîne de format fixe telle que printf("%s", user_data) plutôt que printf(user_data). Le drapeau du compilateur -Wformat-security peut aider à détecter les cas où des chaînes de format non littérales sont utilisées sans arguments appropriés.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
c_format_rule-snprintf-vsnprintf¶
Résumé :
Vulnérabilité potentielle de chaîne de format
Sévérité : Élevée
CWE : CWE-134
Description :
L'application utilise snprintf(), vsnprintf(), _snprintf(),
_sntprintf(), ou _vsntprintf() avec un argument de chaîne de format non constant.
Les vulnérabilités de chaîne de format permettent à un attaquant de lire ou, dans certains cas, d'écrire potentiellement des données vers et depuis des emplacements dans la mémoire du processus. Lorsque des données contrôlées par l'utilisateur ou non fiables sont passées directement comme spécification de format à ces fonctions, les attaquants peuvent utiliser des spécificateurs de format comme %x, %n, et %s pour divulguer des informations sensibles de la pile ou écrire des données arbitraires dans des emplacements mémoire. Notez que certaines variations de ces fonctions ne terminent pas toujours les chaînes résultantes par un caractère nul.
Remédiation :
Envisagez d'utiliser une chaîne littérale constante pour la spécification de format au lieu d'accepter des entrées contrôlées par l'utilisateur ou non fiables. Si des chaînes de format dynamiques sont requises, il est recommandé de mettre en œuvre une validation stricte qui n'autorise que des caractères sûrs spécifiques et élimine complètement les spécificateurs de format comme %x, %n, %s, et %p. Pour copier des données fournies par l'utilisateur dans un tampon, envisagez d'utiliser des alternatives plus sûres comme strncpy() ou strlcpy() qui n'interprètent pas les spécificateurs de format. Lors de l'appel à snprintf() ou à des fonctions similaires, utilisez toujours une chaîne de format fixe, telle que snprintf(buf, size, "%s", user_data) plutôt que snprintf(buf, size, user_data). Soyez conscient que _snprintf() ne garantit pas la terminaison nulle lorsque le tampon est trop petit, donc envisagez d'utiliser la fonction standard snprintf() lorsque cela est possible. L'option du compilateur -Wformat-security peut aider à détecter les cas où des chaînes de format non littérales sont utilisées sans arguments appropriés.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
c_format_rule-syslog¶
Résumé :
Vulnérabilité potentielle de chaîne de format dans l'appel syslog
Gravité : Élevée
CWE : CWE-134
Description :
L'application utilise syslog() avec un argument de chaîne de format non constant. Les vulnérabilités liées aux chaînes de format permettent à un attaquant de lire ou, dans certains cas, d'écrire des données vers et depuis des emplacements dans la mémoire du processus. Lorsque des entrées contrôlées par l'utilisateur ou non fiables sont directement passées comme spécification de format à syslog(), les attaquants peuvent utiliser des spécificateurs de format tels que %x, %n et %s pour divulguer des informations sensibles de la pile ou écrire des données arbitraires dans des emplacements mémoire. Cela est particulièrement dangereux dans syslog() car il est couramment utilisé pour enregistrer des entrées fournies par l'utilisateur, faisant de lui une cible fréquentte pour les attaques par chaîne de format.
Remédiation :
Envisagez d'utiliser une chaîne littérale constante pour la spécification de format au lieu d'accepter une entrée contrôlée par l'utilisateur ou non fiable. Il est recommandé d'appeler toujours syslog() avec une chaîne de format fixe telle que syslog(priority, "%s", user_data) plutôt que syslog(priority, user_data). Si vous devez enregistrer des messages fournis par l'utilisateur, envisagez de mettre en œuvre une validation stricte qui élimine complètement les spécificateurs de format tels que %x, %n, %s et %p avant de transmettre les données à syslog(). Pour une sécurité supplémentaire, envisagez d'utiliser des wrappers syslog qui assainissent automatiquement les entrées ou d'utiliser des bibliothèques de journalisation structurée qui séparent le modèle de message de journal des données enregistrées. Le paramètre du compilateur -Wformat-security peut aider à détecter les cas où des chaînes de format non littérales sont utilisées sans arguments appropriés.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
c_shell_rule-CreateProcess¶
Résumé :
Possibilité de détournement de chemin exécutable (CreateProcess)
Gravité : Élevée
CWE : CWE-78
Description :
La fonction API Windows CreateProcess() est vulnérable au détournement de chemin exécutable en raison de la manière dont elle analyse les espaces dans les chemins non cités. Lorsque les chemins contiennent des espaces et ne sont pas correctement cités, un attaquant peut en tirer profit en plaçant un binaire malveillant plus tôt dans le chemin de recherche qui correspond à la première partie du nom exécutable prévu. Cette vulnérabilité est particulièrement dangereuse dans des répertoires comme 'C:\Program Files' où les espaces sont courants dans les chemins légitimes.
Remédiation :
Envisagez de toujours enfermer le chemin exécutable dans des guillemets échappés pour prévenir les vulnérabilités de détournement de chemin. Par exemple, utilisez CreateProcessA(NULL, "\"C:\Program Files\MyApp.exe\"", ...) pour vous assurer que l'ensemble du chemin est traité comme un seul argument. Il est recommandé de spécifier le chemin absolu complet vers l'exécutable plutôt que de se fier à la résolution de la variable d'environnement PATH. De plus, envisagez de valider que l'exécutable existe à l'emplacement attendu avant d'appeler CreateProcess() et de vérifier sa signature numérique lors des opérations sensibles à la sécurité. Pour des conseils plus détaillés, consultez les remarques de sécurité de Microsoft à l'adresse https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa#security-remarks
OWASP :
- A1:2017-Injection
- A03:2021-Injection
c_shell_rule-CreateProcessAsUser-CreateProcessWithLogon¶
Résumé :
Possibilité de détournement de chemin exécutable (CreateProcessAsUser/CreateProcessWithLogon)
Sévérité : Élevée
CWE : CWE-78
Description :
Les fonctions de l'API Windows CreateProcessAsUser() et CreateProcessWithLogon() sont vulnérables au détournement de chemin exécutable en raison de la manière dont elles analysent les espaces dans les chemins non cités. Lorsque les chemins contiennent des espaces et ne sont pas correctement cités, un attaquant peut exploiter cela en plaçant un binaire malveillant plus tôt dans le chemin de recherche, correspondant à la première partie du nom exécutable prévu. Ces fonctions sont particulièrement préoccupantes car elles exécutent des processus sous différents contextes de sécurité, rendant les attaques de détournement de chemin encore plus dangereuses, puisque le code malveillant serait exécuté avec les privilèges d'un utilisateur élevé ou alternatif.
Remédiation :
Envisagez toujours d'encadrer le chemin exécutable de guillemets échappés pour prévenir les vulnérabilités de détournement de chemin. Pour CreateProcessAsUser(), utilisez le format CreateProcessAsUser(hToken, NULL, "\"C:\Program Files\MyApp.exe\"", ...) pour vous assurer que l'ensemble du chemin est traité comme un seul argument. Il est recommandé de spécifier le chemin absolu complet vers l'exécutable et de vérifier qu'il existe à l'emplacement prévu avant l'exécution. Étant donné que ces fonctions exécutent du code sous différents contextes de sécurité, envisagez également de vérifier la signature numérique de l'exécutable pour garantir son authenticité. Pour CreateProcessWithLogon(), les mêmes règles de citation s'appliquent, mais sachez que les identifiants sont transmis en clair et envisagez d'utiliser CreateProcessWithTokenW() à la place pour une meilleure sécurité. Consultez la documentation de Microsoft à l'adresse suivante : https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessasusera#security-remarks pour des conseils de sécurité détaillés.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
c_shell_rule-execl-execlp¶
Résumé :
Potentiel d'injection de commande OS
Sévérité : Élevée
CWE : CWE-78
Description :
L'application utilise des fonctions d'exécution de commandes C/C++ incluant execl(), execlp(), execle(), execv(), execvp(), popen(), ou des API Windows WinExec() et ShellExecute(), ce qui peut conduire à des vulnérabilités d'injection de commande OS. Ces fonctions sont particulièrement dangereuses lorsque n'importe quelle partie de la chaîne de commande ou des arguments est construite à partir des entrées utilisateur, car les attaquants peuvent injecter des commandes arbitraires via des métacaractères de shell. Les variantes 'p' (execlp(), execvp()) sont particulièrement risquées, car elles recherchent des exécutables dans le PATH, permettant potentiellement aux attaquants de contrôler quel binaire est exécuté par la manipulation du PATH.
Remédiation :
Envisagez de remplacer l'exécution de commandes par des appels de bibliothèque directs qui offrent la même fonctionnalité sans invoquer un shell. Si l'exécution de commandes est inévitable, utilisez les variantes non cherchant dans le PATH (execv() au lieu de execvp()) avec des chemins absolus codés en dur vers les exécutables. Il est recommandé de construire les tableaux d'arguments de manière programmatique plutôt que de construire des chaînes de commandes, car cela empêche l'interprétation shell des métacaractères. Lorsque l'entrée utilisateur doit être incluse dans les arguments, implémentez une liste blanche stricte des valeurs permises plutôt que d'essayer de nettoyer ou d'échapper aux caractères spéciaux. Pour les applications Windows, préférez CreateProcess() avec un quoting approprié à WinExec() ou ShellExecute(), car cela offre plus de contrôle et n'invoque pas cmd.exe. Voir les solutions conformes de SEI CERT à https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152177 pour des modèles d'implémentation sécurisés.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
c_shell_rule-system¶
Résumé :
Risque potentiel d'injection de commandes OS
Gravité : Élevée
CWE : CWE-78
Description :
L'application utilise la fonction de la bibliothèque standard C system() qui invoque le shell du système pour exécuter des commandes, créant un risque significatif d'injection de commandes OS. La fonction system() est particulièrement dangereuse car elle transmet l'ensemble de la chaîne de commande au shell (généralement /bin/sh sur Unix ou cmd.exe sur Windows), permettant aux métacaractères du shell, tels que les points-virgules, les tubes et les accents graves, d'injecter des commandes arbitraires. Même des commandes statiques apparemment sûres peuvent être exploitées si les variables d'environnement ou le PATH sont sous le contrôle de l'attaquant.
Remédiation :
Envisagez de remplacer les appels à system() par des fonctions de bibliothèque directes qui fournissent une fonctionnalité équivalente sans invocation de shell. Si l'exécution de commandes est nécessaire, utilisez fork() et execve() directement sur des systèmes de type Unix, ou CreateProcess() sur Windows, car ces méthodes permettent de passer des arguments sous forme de tableaux plutôt que de chaînes interprétées par le shell. Il est recommandé d'utiliser des chemins absolus vers les exécutables plutôt que de se fier à la résolution du PATH. Lorsque l'entrée de l'utilisateur doit influencer le comportement de la commande, mettez en œuvre une liste d'autorisation stricte des valeurs permises et construisez des tableaux d'arguments de manière programmatique pour prévenir l'interprétation des métacaractères du shell. N'essayez jamais de nettoyer l'entrée en bloquant les caractères spéciaux, car cette approche est sujette aux erreurs et peut être contournée. Consultez le SEI CERT C Coding Standard à l'adresse https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152177 pour des alternatives sécurisées détaillées et des exemples d'implémentation.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
c_crypto_rule-EVP-des-ecb-EVP-des-cbc¶
Résumé :
Algorithme de chiffrement peu sûr (DES)
Gravité : Moyenne
CWE : CWE-327
Description :
L'application utilise des fonctions de chiffrement DES OpenSSL telles que EVP_des_ecb(), EVP_des_cbc(), EVP_des_cfb(), EVP_des_ofb(), ou EVP_desx_cbc() qui mettent en œuvre l'algorithme Data Encryption Standard. DES a une taille de clé effective de seulement 56 bits, ce qui le rend vulnérable aux attaques par force brute avec du matériel moderne. L'algorithme a été officiellement retiré par le NIST (FIPS 46-3) en 2005 et n'est plus recommandé depuis plus de 15 ans.
Remédiation :
Envisagez de migrer vers les fonctions crypto_secretbox_easy() ou crypto_secretbox_detached() de libsodium qui offrent un chiffrement authentifié utilisant XSalsa20 et Poly1305. Ces primitives modernes sont plus rapides et considérablement plus sécurisées que DES, protégeant à la fois contre les falsifications et les attaques de récupération de clés. Pour les applications nécessitant la conformité FIPS 140-2, il est recommandé d'utiliser les fonctions de chiffrement AES d'OpenSSL telles que EVP_aes_256_gcm() pour le chiffrement authentifié ou EVP_aes_256_cbc() avec une authentification HMAC séparée. Évitez 3DES (EVP_des_ede3_cbc()) car il a une taille de bloc de 64 bits, le rendant vulnérable aux attaques d'anniversaire après le traitement de 32 Go de données. Pour des exemples détaillés d'utilisation de libsodium, consultez https://libsodium.gitbook.io/doc/secret-key_cryptography/secretbox.
OWASP :
- A3:2017-Exposition de données sensibles
- A02:2021-Failles cryptographiques
c_crypto_rule-EVP-rc4-40-EVP-rc2-40-cbc¶
Résumé :
Chiffreur de flux non sécurisé (RC4)
Gravité : Moyenne
CWE : CWE-327
Description :
L'application utilise les fonctions de chiffrement OpenSSL RC4 ou RC2 telles que
EVP_rc4_40(), EVP_rc2_40_cbc(), ou EVP_rc2_64_cbc(), qui implémentent
des chiffreurs de flux défectueux. RC4 présente plusieurs biais statistiques dans son flux de clés, ce qui le rend vulnérable à des attaques de récupération de texte en clair pratiques, notamment dans des protocoles comme TLS où la même clé chiffre plusieurs messages. Les variantes à 40 bits et 64 bits de niveau exportation sont de plus vulnérables à la récupération de clés par force brute. RC4 a été interdit dans TLS par le RFC 7465 en 2015.
Remédiation :
Envisagez d'utiliser les fonctions crypto_secretstream_xchacha20poly1305_init_push() et crypto_secretstream_xchacha20poly1305_push() de libsodium pour le chiffrement par chiffreur de flux avec authentification. Cette construction moderne protège à la fois contre la falsification et la récupération de clés tout en offrant d'excellentes performances sur toutes les plateformes. Pour les applications qui doivent maintenir la compatibilité avec les déploiements RC4 existants lors de la migration, il est recommandé d'implémenter un fonctionnement en mode double où les nouvelles connexions utilisent ChaCha20-Poly1305 tandis que les connexions héritées sont progressivement supprimées. Si la conformité FIPS 140-2 est requise, vous pouvez utiliser EVP_aes_256_ctr() d'OpenSSL en mode compteur avec une authentification HMAC-SHA256 séparée, bien que les modes de chiffrement authentifié comme EVP_aes_256_gcm() soient préférés. Évitez 3DES comme remplacement en raison de sa vulnérabilité liée à la taille de bloc de 64 bits. Pour des exemples détaillés de chiffrement de flux avec libsodium, consultez
https://libsodium.gitbook.io/doc/secret-key_cryptography/secretstream.
OWASP :
- A3:2017-Exposition de données sensibles
- A02:2021-Failles cryptographiques
c_crypto_rule-crypt-crypt-r¶
Résumé :
Algorithme de hachage non sécurisé
Sévérité : Moyenne
CWE : CWE-327
Description :
L'application utilise les fonctions crypt() ou crypt_r() de la bibliothèque crypt POSIX pour le hachage des mots de passe. Ces fonctions implémentent traditionnellement un hachage de mot de passe basé sur DES avec une longueur maximale de mot de passe efficace de 8 caractères et seulement 4096 sels possibles, ce qui entraîne un espace de clés extrêmement réduit. Même avec des implémentations étendues prenant en charge le hachage basé sur MD5 ou SHA-256/SHA-512, les fonctions crypt offrent par défaut des nombre d'itérations insuffisants, les rendant vulnérables aux attaques par force brute accélérées par GPU avec du matériel moderne.
Remédiation :
Envisagez de migrer vers les fonctions crypto_pwhash_str() et crypto_pwhash_str_verify() de libsodium, qui implémentent l'algorithme de hachage de mot de passe Argon2id. Argon2id est le vainqueur de la Password Hashing Competition et offre une forte résistance contre les tentatives de cracking basées sur GPU et ASIC grâce à des opérations gourmandes en mémoire. L'implémentation de libsodium gère automatiquement la génération de sels et la sélection des paramètres, ce qui la rend beaucoup plus facile à utiliser en toute sécurité que les implémentations manuelles de bcrypt ou PBKDF2. Pour les cas d'utilisation de connexion interactive, il est recommandé d'utiliser les constantes crypto_pwhash_OPSLIMIT_INTERACTIVE et crypto_pwhash_MEMLIMIT_INTERACTIVE pour une vérification plus rapide, tandis que les applications sensibles devraient utiliser crypto_pwhash_OPSLIMIT_SENSITIVE et crypto_pwhash_MEMLIMIT_SENSITIVE pour une sécurité maximale. Pour des exemples détaillés de hachage de mots de passe et des conseils de migration, référez-vous à https://libsodium.gitbook.io/doc/password_hashing.
OWASP :
- A3:2017-Exposition de données sensibles
- A02:2021-Failures cryptographiques
c_tmpfile_rule-mktemp¶
Résumé :
Utilisation d'une fonction obsolète (mktemp)
Gravité : Moyenne
CWE : CWE-377
Description :
La fonction mktemp() est obsolète et ne doit plus être utilisée en raison de
multiples failles de sécurité. Certaines implémentations créent des noms de fichiers temporaires en utilisant
des informations prévisibles telles que l'ID de processus et une seule lettre, rendant trivial pour les attaquants de deviner le chemin d'accès généré. Cela crée une vulnérabilité de condition de course où un attaquant pourrait créer ou manipuler le fichier entre le moment où mktemp() génère le nom et celui où l'application l'utilise, ce qui pourrait entraîner un accès non autorisé aux fichiers, une corruption des données ou des attaques par symlink.
Remédiation :
Envisagez de migrer vers la fonction mkstemp(), qui crée et ouvre le
fichier temporaire de manière atomique, éliminant ainsi la fenêtre de condition de course. Cependant,
il est conseillé d'être conscient que mkstemp() a également des considérations de sécurité. Assurez-vous que le processus appelle umask() avec des permissions restrictives (par exemple,
umask(0077)) avant d'appeler mkstemp() pour empêcher la création du fichier avec des droits d'accès trop permissifs. Après que mkstemp() a renvoyé un descripteur de fichier, validez les permissions du fichier à l'aide de fstat() avant d'écrire des données sensibles. Pour plus d'informations sur la gestion sécurisée des fichiers temporaires, consultez : viewpage.action
OWASP :
- A5:2017-Contrôle d'accès brisé
- A01:2021-Contrôle d'accès brisé
c_tmpfile_rule-tmpnam-tempnam¶
Résumé :
Vulnérabilité potentielle de type "temps de vérification, temps d'utilisation" (tmpnam/tempnam)
Gravité : Moyenne
CWE : CWE-377
Description :
Les fonctions tmpnam() et tempnam() sont vulnérables aux attaques par condition de course (temps de vérification, temps d'utilisation). Entre le moment où ces fonctions renvoient un chemin d'accès et celui où l'application l'ouvre, un attaquant pourrait créer ce chemin d'accès en utilisant open(), détournant potentiellement le descripteur de fichier, ou le créer en tant que lien symbolique pour détourner les écritures vers un emplacement arbitraire. Cela peut entraîner un accès non autorisé aux fichiers, une élévation de privilèges ou une corruption des données, l'application opérant sans le savoir sur des fichiers contrôlés par l'attaquant.
Remédiation :
Envisagez de remplacer tmpnam() et tempnam() par mkstemp(), qui crée et ouvre atomiquement le fichier temporaire en une seule opération, éliminant ainsi la fenêtre de condition de course. Il est recommandé d'appeler umask() avec des autorisations restrictives (par exemple, umask(0077)) avant d'invoquer mkstemp() pour s'assurer que le fichier temporaire est créé avec des contrôles d'accès sécurisés empêchant d'autres utilisateurs de le lire ou de le modifier. Après avoir obtenu le descripteur de fichier à partir de mkstemp(), validez les permissions du fichier en utilisant fstat() avant d'effectuer toute opération sensible. Pour des conseils complets sur la gestion sécurisée des fichiers temporaires, consultez : viewpage.action
OWASP :
- A5:2017-Contrôle d'Accès Fragile
- A01:2021-Contrôle d'Accès Fragile