Aller au contenu

Règles Semgrep Python

pyramid_jinja2_reflected_xss

Résumé :

Neutralisation incorrecte des entrées utilisateur rendues en HTML ('XSS')

Sévérité : Élevée

CWE : CWE-79

Description :

Les entrées utilisateur non fiables sont transmises à la fonction render() de Pyramid sans une sanitation appropriée, créant ainsi une vulnérabilité XSS réfléchie. Même si les modèles Jinja2 échappent généralement les variables automatiquement, cette protection peut être contournée par des fonctionnalités de modèle qui désactivent l'échappement automatique (comme les filtres 'safe' ou les blocs 'raw').

Remédiation :

Envisagez de sanitiser les entrées utilisateur avant de les transmettre aux modèles en utilisant des fonctions comme escape_html() de pyramid.escape, escape() de markupsafe, html.escape(), ou bleach.clean(). Il est recommandé de passer les données utilisateur par le biais de dictionnaires de contexte plutôt que de les intégrer directement. Soyez particulièrement prudent avec les fonctionnalités de modèle qui désactivent l'échappement automatique lors de la manipulation de données contrôlées par l'utilisateur.

OWASP :

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

pyramid_unsafe_user_input

Résumé :

Neutralisation incorrecte de l'entrée utilisateur rendue en HTML ('XSS')

Gravité : Élevée

CWE : CWE-79

Description :

L'entrée utilisateur non fiable provenant des objets de requête (params, GET, POST, json_body, matchdict) est directement intégrée dans un Response() de Pyramid sans désinfection appropriée, créant une vulnérabilité XSS réfléchie. Cela permet aux attaquants d'injecter des scripts malveillants qui s'exécutent dans les navigateurs des utilisateurs.

Remédiation :

Envisagez de désinfecter l'entrée utilisateur avant de l'inclure dans les réponses HTML en utilisant escape_html() de pyramid.escape, escape() de markupsafe, html.escape(), ou bleach.clean(). Il est recommandé d'utiliser les moteurs de template de Pyramid qui échappent automatiquement les variables par défaut. Notez que l'échappement HTML n'est pas suffisant pour JavaScript, CSS ou les contexts d'URL - utilisez une désinfection spécifique au contexte pour ces cas.

OWASP :

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

python_deserialization_rule-cpickle

Résumé :

Désérialisation de données non fiables

Sévérité : Élevée

CWE : CWE-502

Description :

L'application utilise le module cPickle pour la désérialisation, ce qui permet l'exécution de code arbitraire lors du traitement de données non fiables. Le module cPickle (implémentation C de pickle pour Python 2) peut exécuter du code Python arbitraire durant le processus de désérialisation via des charges utiles spécialement conçues contenant des méthodes __reduce__ ou d'autres méthodes magiques. Lorsque un attaquant contrôle les données sérialisées en cours de désérialisation, il peut injecter des objets malveillants qui exécutent des commandes, lisent des fichiers sensibles, ou établissent des shells inversés lors de la reconstruction des objets. Les attaques par injection d'objets à travers cPickle peuvent également exploiter des vulnérabilités d'assignation massive en incluant des champs inattendus qui modifient l'état de l'application ou contournent les contrôles de sécurité.

Remédiation :

Envisagez de migrer vers des formats de sérialisation plus sûrs tels que JSON avec le module intégré json, qui ne prend en charge que des types de données de base et ne peut pas exécuter de code arbitraire. Pour la sérialisation d'objets complexes, envisagez d'utiliser MessagePack (msgpack-python) ou Protocol Buffers (protobuf), qui offrent une sérialisation typée et sûre sans risques d'exécution de code. Si la sérialisation basée sur pickle doit être utilisée avec des données non fiables, mettez en œuvre des signatures HMAC en utilisant hmac.new() pour vérifier l'intégrité des données avant la désérialisation, bien que cela ne protège que contre la falsification et non contre des sources internes malveillantes. Pour se protéger contre l'assignation massive, désérialisez dans des objets intermédiaires et utilisez la validation de schéma avec la bibliothèque jsonschema pour mettre explicitement sur liste blanche les champs autorisés avant de copier les données dans des objets de production. Notez que cPickle est uniquement pour Python 2 et que les applications devraient migrer vers Python 3, qui utilise exclusivement le module pickle. Pour plus d'informations, consultez la feuille de triche de désérialisation d'OWASP à l'adresse suivante : https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html

OWASP :

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

python_deserialization_rule-dill

Résumé :

Désérialisation de données non fiables

Sévérité : Élevée

CWE : CWE-502

Description :

L'application utilise la bibliothèque dill pour la désérialisation, qui étend les capacités de pickle mais hérite de toutes les vulnérabilités de sécurité de pickle. Les fonctions dill.load(), dill.loads() et d'autres fonctions similaires peuvent exécuter du code Python arbitraire lors du traitement de données non fiables à travers des charges utiles malveillantes contenant des méthodes __reduce__, des fonctions lambda, ou d'autres constructions exécutables. Dill est particulièrement dangereux car il peut sérialiser et désérialiser une plus grande variété d'objets Python que le pickle standard, y compris des fonctions lambda, des fonctions imbriquées et l'état de session de l'interpréteur, ce qui élargit la surface d'attaque pour l'exécution de code à distance. Lorsque des attaquants contrôlent des données dill sérialisées, ils peuvent injecter des objets qui exécutent des commandes système, exfiltrent des données, ou établissent des portes dérobées persistantes pendant le processus de désérialisation.

Remédiation :

Envisagez de remplacer dill par des formats de sérialisation plus sûrs qui n'exécutent pas de code lors de la désérialisation. Pour des structures de données de base, utilisez le module json, qui ne gère que les types primitifs et ne peut pas exécuter de code arbitraire. Pour des graphes d'objets plus complexes nécessitant la préservation des informations de type, envisagez MessagePack (msgpack-python) ou Protocol Buffers (protobuf), qui fournissent tous deux une sérialisation sécurisée par type sans capacités d'exécution de code. Si dill doit être utilisé à des fins légitimes, comme la sérialisation de fermetures de fonction pour le calcul distribué, assurez-vous qu'il ne traite que des données en provenance de sources internes fiables et ne désérialise jamais des données fournies par des utilisateurs ou reçues par le réseau. Mettez en œuvre des signatures HMAC en utilisant hmac.new() avec une clé secrète pour vérifier l'authenticité des données avant la désérialisation, bien que cela ne protège que contre la falsification externe. Pour se protéger contre les attaques par assignation massive, désérialisez dans des objets intermédiaires et validez avec jsonschema pour approuver les champs autorisés avant de copier vers des objets de production. Pour plus d'informations, consultez la feuille de triche de désérialisation d'OWASP à l'adresse suivante : https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html

OWASP :

  • A8:2017-Désérialisation Insecure
  • A08:2021-Failures d'intégrité des logiciels et des données

python_deserialization_rule-marshal

Résumé :

Désérialisation de données non fiables

Gravité : Élevée

CWE : CWE-502

Description :

L'application utilise le module marshal pour la désérialisation via des fonctions telles que marshal.load() ou marshal.loads(), ce qui peut entraîner des vulnérabilités de sécurité lors du traitement de données non fiables. Le module marshal est conçu pour un usage interne de Python pour sérialiser le bytecode compilé (.pyc) et est explicitement documenté comme étant non sécurisé pour les données non fiables. Des données marshal malicieusement fabriquées peuvent provoquer des plantages, de la corruption de mémoire ou potentiellement l'exécution de code arbitraire en désérialisant des objets de bytecode invalides ou en exploitant des bugs d'implémentation dans le parseur de format marshal. Bien que marshal n'exécute pas de manière inhérente les méthodes __reduce__ comme le fait pickle, sa complexité et son manque de validation en font un choix inadapté pour des applications sensibles à la sécurité, et la documentation de Python met explicitement en garde contre l'utilisation de marshal avec des données non fiables.

Remédiation :

Envisagez de remplacer marshal par des formats de sérialisation plus sûrs conçus pour des données non fiables. Utilisez le module json pour sérialiser des structures de données simples, qui offre une sécurité intégrée en ne prenant en charge que des types primitifs et ne peut pas exécuter de code ou désérialiser des objets complexes. Pour les applications nécessitant une sérialisation binaire avec sécurité de type, envisagez MessagePack (msgpack-python) ou Protocol Buffers (protobuf), qui incluent tous deux une validation appropriée et une application de schéma. Le module marshal ne doit être utilisé que pour son usage prévu de sérialisation du bytecode Python pour les fichiers .pyc, jamais pour des données d'application ou quoi que ce soit qui pourrait être influencé par une entrée externe. Si vous devez échanger des objets Python complexes, utilisez le module pickle avec des signatures HMAC pour la vérification de l'intégrité des données, bien que même cette approche doive être limitée à des communications internes fiables uniquement. Notez que le format de marshal est spécifique à la version et peut changer entre les versions de Python, ce qui le rend inadapté pour le stockage de données à long terme ou la compatibilité entre versions. Pour plus d'informations, consultez la documentation de Python à l'adresse https://docs.python.org/3/library/marshal.html qui met explicitement en garde contre les risques de sécurité.

OWASP :

  • A8:2017-Désérialisation Insecure
  • A08:2021-Failles d’intégrité des logiciels et des données

python_deserialization_rule-pickle

Résumé :

Désérialisation de données non sûres

Sévérité : Élevée

CWE : CWE-502

Description :

L'application utilise le module pickle pour la désérialisation via des fonctions telles que pickle.load(), pickle.loads(), ou pickle.Unpickler(), ce qui permet l'exécution de code arbitraire lors du traitement de données non fiables. Le module pickle de Python peut exécuter du code arbitraire lors de la désérialisation à travers des payloads spécialement conçus qui incluent __reduce__, __setstate__, ou d'autres méthodes magiques qui sont automatiquement invoquées durant la reconstruction des objets. Lorsque un attaquant contrôle les données sérialisées de pickle, il peut créer des objets malveillants qui exécutent des commandes système, lisent des fichiers sensibles, établissent des shells inversés, ou manipulent l'état de l'application pendant le processus de dé-sérialisation. La documentation officielle de Python avertit explicitement que pickle est dangereux pour les données non sûres et ne doit jamais être utilisé pour désérialiser des données provenant de sources non fiables ou non authentifiées.

Remédiation :

Envisagez de migrer vers des formats de sérialisation plus sûrs qui n'exécutent pas de code durant la désérialisation. Pour des structures de données basiques, utilisez le module json qui ne supporte que des types primitifs (chaînes, nombres, listes, dictionnaires) et ne peut pas exécuter de code arbitraire. Pour des besoins de sérialisation plus complexes nécessitant des formats binaires ou une meilleure performance, envisagez MessagePack (msgpack-python) ou Protocol Buffers (protobuf), qui offrent tous deux une sérialisation sûre par type sans risques d'exécution de code. Si pickle doit être utilisé pour des raisons internes légitimes comme le caching ou la communication inter-processus, assurez-vous qu'il ne traite que des données provenant de sources fiables et mettez en œuvre des signatures HMAC en utilisant hmac.new() avec une clé secrète pour vérifier l'intégrité des données avant la désérialisation. Pour se protéger contre les attaques de mass assignment, désérialisez d'abord dans des objets intermédiaires et validez avec la bibliothèque jsonschema pour explicitement approuver les champs autorisés avant de copier les données dans des objets de production. Envisagez d'exécuter des opérations de désérialisation dans des environnements en bac à sable avec des privilèges limités suivant le principe du moindre privilège. Pour plus d'informations, consultez la feuille de triche de désérialisation de l'OWASP à https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html

OWASP :

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

python_deserialization_rule-shelve

Résumé :

Désérialisation de données non fiables

Sévérité : Élevée

CWE : CWE-502

Description :

L’application utilise le module shelve pour le stockage persistant, qui utilise pickle en interne pour la sérialisation et hérite de toutes les vulnérabilités de sécurité de pickle. La fonction shelve.open() crée un objet persistant ressemblant à un dictionnaire qui tamponne et détamponne automatiquement les objets Python lors du stockage et de la récupération des données, ce qui la rend vulnérable à l'exécution de code arbitraire si le fichier de étagère est altéré ou remplacé par un attaquant. Lors de la lecture d'un fichier d'étagère, des objets picklés fabriqués de manière malveillante peuvent exécuter un code Python arbitraire via des méthodes __reduce__ ou d'autres méthodes magiques pendant le processus de détamponnement. Étant donné que les fichiers d'étagère sont généralement stockés sur disque à des emplacements prévisibles, des attaquants avec accès au système de fichiers peuvent remplacer des fichiers d'étagère légitimes par des versions malveillantes contenant des charges exploit qui s'exécutent lorsque l'application lit des données à partir de l'étagère.

Correction :

Envisagez de remplacer shelve par des solutions de base de données qui ne désérialisent pas de code exécutable. Pour une persistance simple clé-valeur, utilisez SQLite via le module sqlite3 de Python avec une sérialisation JSON pour les valeurs de données, ce qui offre des transactions atomiques et un accès concurrent sans risques de désérialisation. Pour les applications nécessitant des structures de données plus complexes, envisagez des bases de données embarquées comme TinyDB ou des bases de données externes comme PostgreSQL ou MongoDB. Si shelve doit être utilisé, stockez les fichiers d'étagère dans des répertoires avec des permissions restrictives (chmod 600) qui n'autorisent l'accès que par l'utilisateur de l'application, et mettez en œuvre un suivi de l'intégrité des fichiers pour détecter les modifications non autorisées. Envisagez d'utiliser des signatures HMAC pour vérifier l'intégrité des fichiers d'étagère avant de les ouvrir, bien que cela ne protège que contre les manipulations externes. Pour les cas d'utilisation de mise en cache, envisagez des alternatives comme Redis qui utilisent des formats de sérialisation sûrs, ou python-diskcache qui offre une fonctionnalité similaire avec de meilleures options de sécurité. Validez toujours et assainissez les données après leur récupération depuis un stockage persistant avant de les utiliser dans des opérations sensibles à la sécurité. Pour plus d'informations, consultez la Fiche de tricherie sur la désérialisation d’OWASP à l'adresse suivante : https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html

OWASP :

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

python_deserialization_rule-yaml-load

Résumé :

Désérialisation de données non fiables

Gravité : Élevée

CWE : CWE-502

Description :

L'application utilise une désérialisation YAML non sécurisée via yaml.load(), yaml.unsafe_load(), ou yaml.load() avec des chargeurs non sécurisés tels que Loader, UnsafeLoader, CLoader, ou FullLoader. Ces fonctions peuvent instancier des objets Python arbitraires pendant la désérialisation, permettant aux attaquants d'exécuter du code arbitraire lors du traitement d'entrées YAML malveillantes. La bibliothèque PyYAML prend en charge des balises YAML spéciales comme !!python/object/apply qui peuvent invoquer des fonctions ou constructeurs Python arbitraires, permettant l'exécution de code à distance à travers des documents YAML soigneusement élaborés. Même le FullLoader, qui a été introduit comme une alternative plus sûre, présente des vulnérabilités connues et ne doit pas être utilisé avec des données non fiables. Les attaquants peuvent exploiter cela en fournissant des entrées YAML qui construisent des objets malveillants, exécutent des commandes système, ou manipulent l'état de l'application pendant le processus de chargement.

Remédiation :

Remplacez les fonctions de chargement YAML non sécurisées par yaml.safe_load() ou spécifiez explicitement yaml.load(data, Loader=yaml.SafeLoader), qui ne désérialise que les balises YAML standard et ne peut pas instancier d'objets Python arbitraires. Le SafeLoader est conçu pour gérer des données non fiables et restreint la désérialisation aux types de données de base tels que chaînes, nombres, listes et dictionnaires. Pour les applications utilisant la bibliothèque plus récente ruamel.yaml, utilisez YAML(typ='safe') pour une désérialisation sûre. Après une désérialisation sécurisée, validez la structure de données chargée contre un schéma en utilisant des bibliothèques comme pydantic ou jsonschema pour garantir qu'elle correspond aux formats attendus et ne contient aucun champ inattendu qui pourrait exploiter des vulnérabilités de liaison massive. Si vous devez charger du YAML avec des objets Python personnalisés pour des fichiers de configuration internes, assurez-vous que ces fichiers sont stockés avec des permissions restrictives et ne peuvent pas être modifiés par des utilisateurs non fiables. Envisagez de passer au JSON pour les données de configuration lorsque cela est possible, car il a un modèle de sécurité plus simple et ne prend pas en charge les constructions exécutables. Pour plus d'informations, consultez la feuille de triche OWASP sur la désérialisation à l'adresse https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html

OWASP :

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

python_django_rule-django-extra-utilisé

Résumé :

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

Gravité : Élevé

CWE : CWE-89

Description :

La méthode QuerySet.extra() est dépréciée en raison des risques d'injection SQL. Cette méthode permet des requêtes SQL générées dynamiquement où l'entrée de l'utilisateur peut influencer la logique de la requête, ce qui peut permettre à des adversaires d'accéder à des données non autorisées ou d'exécuter des opérations de base de données arbitraires. Les appelants doivent échapper manuellement les paramètres fournis par l'utilisateur, ce qui est sujet à des erreurs et peu sécurisé.

Remédiation :

Envisagez de remplacer QuerySet.extra() par d'autres méthodes QuerySet comme annotate(), filter() ou aggregate() pour éviter les risques d'injection SQL. Si SQL personnalisé est absolument nécessaire, utilisez RawSQL() comme alternative plus sûre, en veillant à ce que tous les arguments fournis par l'utilisateur soient passés uniquement par le paramètre params=[] qui gère l'échappement approprié. Pour plus d'informations, voir :

OWASP :

  • A1:2017-Injection
  • A03:2021-Injection

python_django_rule_reflected_xss_csp

Résumé :

Paramètres de Content Security Policy (CSP) non sécurisés ('XSS')

Sévérité : Élevée

CWE : CWE-79

Description :

L'application configure une Content Security Policy (CSP) non sécurisée dans le code Python, potentiellement pour des applications Django. La configuration CSP utilise des directives non sécurisées, notamment 'unsafe-inline' qui permet les scripts et styles en ligne, 'unsafe-eval' qui autorise eval() et l'exécution dynamique de code similaire, 'unsafe-hashes' qui peut affaiblir les protections basées sur des hachages, ou des listes de sources trop permissives utilisant des jokers '*'. Ces directives CSP faibles réduisent considérablement l'efficacité de la politique en tant que mitigation des XSS, car elles autorisent exactement les types d'exécution de code que le CSP est conçu pour prévenir. La règle détecte les variables de configuration liées au CSP (correspondant aux motifs CSP|Content-Security-Policy|Security|Policy) avec des valeurs dangereuses.

Remédiation :

Envisagez de supprimer 'unsafe-inline', 'unsafe-eval' et 'unsafe-hashes' de vos directives CSP et remplacez les jokers '*' par des listes autorisées explicites ou 'self'. Pour les applications Django utilisant le middleware django-csp, configurez des politiques restrictives comme CSP_SCRIPT_SRC = ("'self'",) et utilisez une CSP basée sur des nonce ou des hachages pour les scripts en ligne lorsque c'est nécessaire. Déplacez le JavaScript en ligne vers des fichiers externes pour éviter d'avoir besoin de 'unsafe-inline'. Remplacez eval(), Function() et les gestionnaires d'événements en ligne pour éliminer le besoin de 'unsafe-eval'. Pour les scripts tiers, autorisez explicitement leurs domaines plutôt que d'utiliser des jokers. Utilisez des directives report-uri ou report-to pour surveiller les violations CSP en production. Envisagez de commencer avec une politique en mode rapport uniquement (Content-Security-Policy-Report-Only) pour tester les restrictions avant de les appliquer. Consultez la documentation CSP de Mozilla à l'adresse https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP et la documentation de django-csp à l'adresse https://django-csp.readthedocs.io/ pour des conseils de mise en œuvre.

OWASP :

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

python_django_rule_reflected_xss_global

Résumé :

Neutralisation inappropriée des entrées utilisateur affichées en HTML ('XSS') dans Django

Sévérité : Élevée

CWE : CWE-79

Description :

L'application Django a des paramètres de protection XSS globaux non sécurisés dans settings.py ou dans le code. Cela inclut : (1) SECURE_BROWSER_XSS_FILTER = False qui désactive le filtrage XSS du navigateur, (2) SECURE_CONTENT_TYPE_NOSNIFF = False qui permet les attaques de sniffing de types MIME, (3) ALLOWED_HOSTS = ['*'] qui autorise l'injection d'en-têtes d'hôte, (4) la configuration du moteur de templates avec 'autoescape': False qui désactive globalement l'échappement HTML de Django, ou (5) l'utilisation du décorateur @html_safe sur des classes qui peuvent traiter des données non fiables. Le décorateur @html_safe marque toutes les représentations de chaîne d'une classe comme du HTML sûr, contournant l'échappement automatique de Django lorsque des instances sont rendues dans des templates. Ces erreurs de configuration globales suppriment des défenses XSS critiques et affectent l'ensemble de l'application plutôt que des vues ou des templates spécifiques.

Remédiation :

Envisagez de définir SECURE_BROWSER_XSS_FILTER = True et SECURE_CONTENT_TYPE_NOSNIFF = True dans les paramètres Django pour activer les protections XSS au niveau du navigateur. Configurez ALLOWED_HOSTS avec une liste spécifique de noms d'hôtes valides au lieu d'utiliser ['*'] pour éviter les attaques par injection d'en-têtes d'hôte. Maintenez l'échappement automatique des templates activé en vous assurant que 'autoescape': True dans les options du MOTEUR de templates (c'est la valeur par défaut). Évitez d'utiliser le décorateur @html_safe sur les classes qui traitent les entrées utilisateur - réservez-le uniquement pour les classes qui génèrent du HTML fiable. Pour Django 4.0 et plus, envisagez d'utiliser le paramètre SECURE_CROSS_ORIGIN_OPENER_POLICY pour une isolation supplémentaire. Mettez en œuvre des en-têtes Content Security Policy (CSP) en utilisant le middleware django-csp pour fournir une protection en profondeur. Consultez la documentation de sécurité de Django à l'adresse https://docs.djangoproject.com/en/stable/topics/security/ pour des conseils complets sur le renforcement de la sécurité.

OWASP :

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

python_django_rule_reflected_xss_httpresponse

Résumé :

Neutralisation incorrecte des entrées utilisateur rendues en HTML ('XSS') dans Django

Sévérité : Élevée

CWE : CWE-79

Description :

L'application Django transmet directement les données fournies par l'utilisateur via request.GET.get() ou request.POST.get() à HttpResponse() sans échapper le HTML. Le constructeur HttpResponse() de Django contourne l'échappement HTML automatique du moteur de templates, rendant le contenu exactement tel que fourni. Cela crée une vulnérabilité de Cross-Site Scripting (XSS) réfléchie où des attaquants peuvent injecter du JavaScript malveillant à travers des paramètres de requête qui s'exécuteront dans les navigateurs des victimes. La règle détecte le flux de contamination entre les accesseurs de paramètres de requête Django et les constructeurs de HttpResponse à l'aide d'une analyse de mode de contamination. Bien que les templates Django échappent automatiquement les variables, l'utilisation directe de HttpResponse() contourne cette protection et nécessite un échappement manuel de toutes les entrées utilisateur.

Remédiation :

Envisagez d'utiliser la fonction render() de Django avec des templates au lieu de HttpResponse() pour les réponses HTML, car les templates offrent un échappement automatique et contextuel. Si vous devez utiliser HttpResponse(), échappez manuellement les entrées utilisateur avec django.utils.html.escape() ou django.utils.html.format_html() avant de construire la réponse. Lors de l'utilisation de format_html(), passez les entrées utilisateur en tant qu'arguments (par exemple, format_html("<b>{}</b>", user_input)) plutôt que de les intégrer dans des f-strings qui contourneraient l'échappement. Pour les réponses en texte brut, définissez le type de contenu sur text/plain avec HttpResponse(content, content_type='text/plain') pour empêcher les navigateurs d'interpréter le contenu comme HTML. Pour les contextes JavaScript ou CSS, utilisez django.utils.html.escapejs() en plus de l'échappement HTML. Utilisez des nettoyeurs basés sur une liste blanche comme bleach ou nh3 pour le contenu riche généré par les utilisateurs requérant une mise en forme HTML.

OWASP :

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

python_django_rule_reflected_xss_render

Résumé :

Neutralisation inadéquate des entrées utilisateur rendues en HTML ('XSS')

Gravité : Élevée

CWE : CWE-79

Description :

L'application Django marque les données fournies par l'utilisateur provenant de request.GET.get() ou request.POST.get() comme HTML sûr en utilisant mark_safe() ou SafeString() avant de les transmettre à la fonction render() ou au contexte du modèle. Ces fonctions indiquent explicitement au moteur de template de Django de sauter l'échappement automatique du HTML pour les chaînes marquées, créant ainsi une vulnérabilité de type Cross-Site Scripting (XSS). La règle détecte également les cas où l'entrée utilisateur est marquée comme sûre puis transmise à render_to_string() combiné avec HttpResponse(), ou lorsque des modèles sont rendus dynamiquement avec des données utilisateur non sécurisées à l'aide de chargeurs de modèles. Bien que les modèles Django aient l'échappement automatique activé par défaut, l'utilisation de mark_safe() ou SafeString() sur l'entrée utilisateur contourne complètement cette protection, permettant l'exécution de JavaScript malveillant dans la page rendue.

Remédiation :

Envisagez de supprimer les appels à mark_safe() et SafeString() sur les données fournies par l'utilisateur et de vous fier à l'échappement automatique des modèles de Django à la place. Ne marquez jamais les entrées utilisateur comme sûres - réservez ces fonctions uniquement pour le HTML généré par votre code d'application. Si vous devez échapper manuellement l'entrée utilisateur avant le rendu, utilisez django.utils.html.escape() ou django.utils.html.format_html() avec un passage d'arguments approprié comme format_html("<b>{}</b>", user_input) plutôt que des f-strings. Pour le contenu riche généré par l'utilisateur qui nécessite un formatage HTML, utilisez un nettoyeur basé sur une liste blanche comme bleach ou nh3 pour nettoyer le HTML avant de le transmettre aux modèles. Pour les contextes JavaScript ou CSS dans les modèles, utilisez django.utils.html.escapejs() en plus de l'échappement automatique de Django. Envisagez d'utiliser la classe Sanitizer de Django pour des scénarios de nettoyage HTML plus complexes. Implémentez des en-têtes de Content Security Policy (CSP) comme protection en profondeur.

OWASP :

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

python_eval_rule-eval

Résumé :

Neutralisation incorrecte des directives dans le code évalué dynamiquement ('Injection d'Eval')

Sévérité : Élevée

CWE : CWE-95

Description :

L'application appelle eval() avec des données non littérales, ce qui permet l'exécution arbitraire de code Python. Si l'entrée contient des données contrôlées par l'utilisateur (directement ou indirectement), un attaquant peut exécuter du code malveillant pour compromettre l'ensemble du système, accéder à des données sensibles ou effectuer des opérations non autorisées. La fonction eval() est intrinsèquement dangereuse avec des entrées non fiables.

Remédiation :

Supprimez tous les appels à eval() et utilisez des alternatives plus sûres. Si vous convertissez des chaînes en structures de données, utilisez json.loads() pour les données JSON. Évitez ast.literal_eval() car il peut encore causer des problèmes de déni de service. Envisagez de repenser la logique pour éviter complètement l'exécution de code dynamique. Il n'existe aucun moyen sûr d'appeler eval() avec des entrées influencées par l'utilisateur, même avec des tentatives de désinfection. Refactorez pour utiliser des conditionnels explicites, des tables de recherche ou des mappings de fonctions prédéfinis à la place.

OWASP :

  • A1:2017-Injection
  • A03:2021-Injection

python_exec_rule-exec-used

Résumé :

Neutralisation inappropriée 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 la fonction exec() de Python avec une variable non littérale, ce qui permet l'exécution de code Python arbitraire à l'exécution. Si la variable passée à exec() contient une entrée fournie par l'utilisateur, un adversaire pourrait parvenir à une compromission totale du système en exécutant du code Python malveillant avec les privilèges de l'application. Cette vulnérabilité est particulièrement dangereuse car exec() a accès à l'ensemble de l'environnement d'exécution Python et peut modifier l'état du programme, accéder à des fichiers, établir des connexions réseau ou exécuter des commandes système.

Remédiation :

Supprimez tous les appels à exec() et redessinez la logique de l'application pour éviter l'exécution dynamique de code. Envisagez d'utiliser json.loads() si l'objectif est de convertir des chaînes en structures de données Python, car cela analyse en toute sécurité le JSON sans exécuter de code. Si l'évaluation d'expressions littérales est nécessaire, ast.literal_eval() peut analyser en toute sécurité des littéraux Python tels que des chaînes, des nombres, des listes et des dictionnaires, bien qu'il doive être utilisé avec prudence car il peut toujours provoquer un déni de service par épuisement des ressources. Pour des systèmes de configuration ou de plugins, envisagez d'utiliser des formats déclaratifs comme YAML ou TOML avec validation de schéma, ou implémentez un langage spécifique à un domaine restreint. Il n'existe aucune méthode sûre d'appel à exec() avec une forme d'entrée influencée par l'utilisateur.

OWASP :

  • A1:2017-Injection
  • A03:2021-Injection

python_exec_rule-linux-command-wildcard-injection

Résumé :

Neutralisation incorrecte des caractères génériques ou des symboles de correspondance

Gravité : Élevée

CWE : CWE-155

Description :

L'application utilise des caractères génériques (* ou ?) dans des appels à os.system(), os.popen(), ou subprocess.Popen() avec shell=True, ce qui permet l'expansion des caractères génériques par le shell. Cela crée une vulnérabilité d'injection de commande car des adversaires peuvent créer des fichiers dont les noms commencent par des tirets (comme -e sh malicious.sh) qui seront étendus par le shell et interprétés comme des options de ligne de commande plutôt que comme des noms de fichier. Cette technique, connue sous le nom d'injection de caractères génériques ou d'injection d'arguments, peut conduire à l'exécution de commandes arbitraires lorsque les noms de fichiers étendus sont traités par la commande cible.

Remédiation :

Utilisez le module glob pour étendre les caractères génériques de manière programmatique avant de passer les résultats aux fonctions subprocess, et utilisez toujours des arguments de type liste sans shell=True. Par exemple, remplacez subprocess.Popen("rm *.txt", shell=True) par subprocess.run(["rm"] + glob.glob("*.txt")). Cela garantit que les noms de fichiers étendus sont traités comme des données plutôt que d'être soumis à l'interprétation du shell. Si l'ensemble des fichiers est prévisible, envisagez de coder en dur la liste des fichiers ou d'utiliser un appariement de chemin plus spécifique. Lorsque vous travaillez avec des motifs spécifiés par l'utilisateur, validez-les strictement et ne permettez jamais aux motifs d'être directement interpolés dans des commandes shell.

OWASP :

  • A1:2017-Injection
  • A03:2021-Injection

python_exec_rule-os-path

Résumé :

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

Gravité : Élevée

CWE : CWE-78

Description :

L'application utilise des fonctions Python obsolètes comme os.system(), os.popen(), os.popen2(), os.popen3(), os.popen4(), commands.getoutput(), ou commands.getstatusoutput() avec des littéraux de chaîne. Bien que l'implémentation actuelle semble utiliser des chaînes statiques, ces fonctions sont intrinsèquement dangereuses car elles invoquent des interprètes de shell, rendant le code fragile et susceptible à l'injection de commande si le code est modifié ultérieurement pour inclure des variables ou des entrées utilisateur.

Remédiation :

Migrer vers subprocess.run() ou subprocess.Popen() avec des arguments de type liste et shell=False (par défaut). Par exemple, remplacez os.system("ls -la") par subprocess.run(["ls", "-la"], capture_output=True). Cette approche évite entièrement l'invocation du shell, éliminant ainsi les risques d'injection de shell même si le code est ensuite modifié pour inclure des variables. Le module subprocess offre un meilleur contrôle sur l'exécution des processus, y compris un traitement approprié des arguments, des variables d'environnement, et de la capture de sortie. Notez que le module commands a été supprimé en Python 3, et la famille de fonctions os.popen est obsolète.

OWASP :

  • A1:2017-Injection
  • A03:2021-Injection

python_exec_rule-os-popen2

Résumé :

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

Sévérité : Élevée

CWE : CWE-78

Description :

L'application utilise des fonctions d'exécution de processus Python obsolètes, y compris os.system(), os.popen(), os.popen2(), os.popen3(), os.popen4(), popen2.popen2(), popen2.popen3(), popen2.popen4(), popen2.Popen3(), popen2.Popen4(), commands.getoutput(), ou commands.getstatusoutput(). Ces fonctions lancent des processus via un interpréteur de shell, ce qui introduit des vulnérabilités d'injection de commande si le code est un jour modifié pour accepter des entrées dynamiques. Même avec des arguments statiques, ces APIs sont obsolètes et devraient être remplacées par des alternatives modernes.

Remédiation :

Remplacez toutes les utilisations par subprocess.run() ou subprocess.Popen() en utilisant des arguments en style liste sans shell=True. Par exemple, transformez os.popen("grep pattern file.txt") en subprocess.run(["grep", "pattern", "file.txt"], capture_output=True, text=True). Le module subprocess offre une meilleure sécurité, une gestion des erreurs et un contrôle sur l'exécution des processus. Le module popen2 a été supprimé dans Python 3.0, et le module commands a également été supprimé dans Python 3. Utiliser les APIs de subprocess modernes évite les vulnérabilités d'injection de shell et rend le code plus maintenable et portable à travers les plateformes.

OWASP :

  • A1:2017-Injection
  • A03:2021-Injection

python_exec_rule-start-process-with-no-shell

Résumé :

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

Sévérité : Élevée

CWE : CWE-78

Description :

L'application utilise la famille de fonctions os.exec*() de Python (y compris os.execl(), os.execle(), os.execlp(), os.execlpe(), os.execv(), os.execve(), os.execvp(), os.execvpe()) ou la famille os.spawn*() (y compris os.spawnl(), os.spawnle(), os.spawnlp(), os.spawnlpe(), os.spawnv(), os.spawnve(), os.spawnvp(), os.spawnvpe()) ou os.startfile() avec des arguments dynamiques qui ne sont pas des littéraux chaînes. Bien que ces fonctions n'invoquent pas un shell par défaut, elles peuvent tout de même permettre une injection de commande si des données externes influencent le chemin de la commande ou les arguments, car les attaquants peuvent exécuter des programmes arbitraires ou manipuler le comportement des commandes.

Remédiation :

Assurez-vous que le chemin de la commande et tous les arguments sont soit des littéraux chaînes codés en dur, soit strictement validés par rapport à une liste autorisée de valeurs sûres. Si l'entrée utilisateur doit influencer la commande à exécuter, utilisez une structure de mappage pour traduire les choix de l'utilisateur en commandes sûres et prédéfinies, plutôt que de permettre une spécification directe du chemin. Pour la famille os.spawn*(), envisagez d'utiliser subprocess.run() ou subprocess.Popen() à la place, car elles offrent un meilleur contrôle et sont l'approche moderne recommandée. Ne permettez jamais à l'entrée utilisateur de contrôler le chemin de l'exécutable, et validez tous les arguments pour vous assurer qu'ils ne peuvent pas sortir des modèles d'utilisation prévus (par exemple, en contenant des séquences de traversée de chemin ou des drapeaux de ligne de commande inattendus).

OWASP :

  • A1:2017-Injection
  • A03:2021-Injection

python_exec_rule-subprocess-call

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 des fonctions du module subprocess (comme subprocess.run(), subprocess.Popen(), subprocess.call(), ou subprocess.check_output()) sans shell=True, ce qui est le comportement par défaut sécurisé. Bien que cette approche évite les vulnérabilités par injection de shell, l'application doit toujours valider que les données fournies par l'utilisateur n'influencent pas le chemin de la commande ou ses arguments de manière dangereuse. Par exemple, passer une entrée utilisateur comme chemin d'exécutable pourrait permettre l'exécution de programmes arbitraires, et des arguments contrôlés par l'utilisateur pourraient activer des attaques par injection de paramètres si la commande cible possède des options dangereuses.

Remédiation :

Assurez-vous que le chemin d'exécutable est toujours un littéral codé en dur ou sélectionné dans une liste blanche stricte de commandes autorisées. Validez tous les arguments provenant de l'entrée utilisateur, en veillant notamment à ce qu'ils ne commencent pas par des traits d'union (qui pourraient être interprétés comme des options de ligne de commande). Envisagez d'utiliser des bibliothèques qui fournissent des abstractions de niveau supérieur pour des tâches courantes plutôt que de lancer directement des sous-processus. Par exemple, utilisez le module shutil pour les opérations sur les fichiers au lieu d'appeler les commandes cp ou mv. Lorsque les entrées utilisateur doivent être passées en tant qu'arguments, mettez en œuvre une validation stricte des entrées, envisagez une isolation, et utilisez le séparateur -- si la commande le prend en charge pour marquer la fin des options et prévenir les injections de paramètres.

OWASP :

  • A1:2017-Injection
  • A03:2021-Injection

python_exec_rule-subprocess-popen-shell-true

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 :

L'application utilise des fonctions du module subprocess telles que subprocess.run(), subprocess.Popen(), subprocess.call(), ou subprocess.check_output() avec shell=True, ce qui exécute des commandes via un interpréteur de shell (comme /bin/sh ou cmd.exe). Cela est extrêmement dangereux car cela permet des attaques par injection de shell si une partie de la chaîne de commande contient des données fournies par l'utilisateur. Les interpréteurs de shell traitent les caractères spéciaux (comme ;, |, &, $, backticks, etc.) comme des opérateurs de contrôle, permettant aux attaquants de enchaîner des commandes, rediriger la sortie ou exécuter du code arbitraire. De plus, shell=True hérite de l'environnement actuel et de la configuration du shell, ce qui peut introduire un comportement inattendu et des vulnérabilités de sécurité.

Remédiation :

Remplacez shell=True par shell=False (la valeur par défaut) et passez la commande sous forme de liste d'arguments au lieu d'une chaîne. Par exemple, remplacez subprocess.run("grep pattern file.txt", shell=True) par subprocess.run(["grep", "pattern", "file.txt"]). Cela garantit que chaque argument est passé directement au programme sans interprétation par le shell, éliminant complètement les vulnérabilités d'injection de shell. Si vous avez besoin de fonctionnalités de shell comme des pipes ou des redirections, implémentez-les en utilisant les fonctionnalités de subprocess : utilisez stdout=subprocess.PIPE et connectez plusieurs processus, ou utilisez la gestion de fichiers intégrée de Python. Ne concaténez jamais ni n'interpolez les entrées utilisateur dans des chaînes de commandes, même lorsqu'elles apparaissent dans des listes d'arguments.

OWASP :

  • A1:2017-Injection
  • A03:2021-Injection

python_exec_rule-subprocess-shell-TRUE

Résumé :

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

Gravité : Élevée

CWE : CWE-78

Description :

L'application utilise des fonctions de création de processus avec shell=True dans un contexte qui semble être un appel semblable à un sous-processus mais qui peut ne pas provenir du module subprocess standard. Ce modèle détecte les vulnérabilités potentielles d'injection de commande dans des wrappers personnalisés de sous-processus ou des bibliothèques tierces qui acceptent les paramètres shell=True. L'utilisation de shell=True permet l'interprétation des chaînes de commande par le shell, ce qui permet aux attaquants d'injecter des métacaractères de shell (comme ;, |, &, $(), etc.) si une entrée utilisateur influence la commande, conduisant à l'exécution de commandes arbitraires.

Remédiation :

Passez en revue la fonction identifiée pour comprendre si elle crée des processus et accepte des commandes shell. Si c'est un wrapper personnalisé autour de la fonctionnalité de sous-processus, modifiez-le pour retirer shell=True et accepter les arguments de commande sous forme de listes plutôt que de chaînes. S'il s'agit d'une bibliothèque tierce, consultez la documentation pour des alternatives sécurisées qui ne nécessitent pas d'appel de shell. Lors de la refactorisation, assurez-vous que les commandes sont passées sous forme de listes (par exemple, ["commande", "arg1", "arg2"]) plutôt que de chaînes, et ne concaténez ni n'interpolez jamais les entrées utilisateur dans les chaînes de commande. Envisagez de créer des abstractions de niveau supérieur qui éliminent le besoin de création de processus directe.

OWASP :

  • A1:2017-Injection
  • A03:2021-Injection

python_flask_rule_reflected_xss_make_response

Résumé :

Neutralisation incorrecte de l'entrée utilisateur rendue en HTML (XSS)

Sévérité : Élevée

CWE : CWE-79

Description :

L'entrée utilisateur non fiable provenant des objets de requête est directement insérée dans une réponse HTML créée avec make_response() sans une sanitisation appropriée, créant une vulnérabilité XSS réfléchie. Il est toujours recommandé de nettoyer l'entrée utilisateur avant de l'inclure dans les réponses HTML en utilisant la fonction d'échappement de Flask, l'échappement de MarkupSafe, html.escape() ou bleach.clean(). Utilisez render_template() de Flask avec des modèles Jinja2 au lieu de construire manuellement du HTML avec make_response(), car les modèles échappent automatiquement aux variables. N'oubliez pas que l'échappement HTML n'est pas suffisant pour les contextes JavaScript, les contextes CSS ou les attributs d'URL - utilisez une sanitisation spécifique au contexte dans ces cas.

Remédiation :

Envisagez d'utiliser la fonction render_template() de Flask avec des modèles Jinja2 au lieu de make_response() avec construction HTML manuelle, car les modèles fournissent un échappement automatique du HTML par défaut. Si vous devez utiliser make_response(), échappez l'entrée utilisateur avec markupsafe.escape(), flask.escape(), html.escape() ou bleach.clean() avant de construire la réponse. Pour les réponses en texte brut, définissez explicitement le type de contenu avec response.mimetype = 'text/plain' pour empêcher les navigateurs d'interpréter le contenu comme HTML. Pour les réponses JSON, utilisez la fonction jsonify() de Flask, qui gère l'échappement automatiquement. Implémentez des en-têtes de Politique de Sécurité de Contenu (CSP) en utilisant les extensions Flask-CSP ou Flask-Talisman pour fournir une protection en profondeur. Pour les contextes JavaScript ou CSS, utilisez des échappements spécifiques au contexte au-delà de l'échappement HTML.

OWASP :

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

python_flask_rule_reflected_xss_render

Résumé :

Neutralisation inappropriée des entrées utilisateur rendues en HTML (XSS)

Sévérité : Élevée

CWE : CWE-79

Description :

Les entrées utilisateur non fiables sont directement insérées dans une chaîne de modèle HTML passée à render_template_string(), créant ainsi une vulnérabilité XSS réfléchie. Bien que les modèles Jinja2 échappent automatiquement aux variables, cette protection est contournée lorsque l'entrée utilisateur est intégrée dans la chaîne de modèle elle-même ou lorsque le filtre |safe est utilisé. Ne construisez jamais de chaînes de modèle dynamiquement avec des entrées utilisateur - passez toujours les données utilisateur en tant que variables de contexte au modèle à la place. Si vous devez inclure des données utilisateur dans des modèles dynamiques, assainissez-les d'abord avec la fonction d'échappement de Flask, l'échappement de MarkupSafe, ou html.escape(). N'utilisez jamais le filtre |safe avec des données non fiables et envisagez d'utiliser render_template() avec des fichiers de modèle statiques au lieu de render_template_string().

Remédiation :

Envisagez d'utiliser render_template() avec des fichiers de modèle statiques au lieu de render_template_string() pour éviter les vulnérabilités d'injection de modèle. Ne mettez jamais directement les entrées utilisateur dans des chaînes de modèle - passez toujours les données utilisateur en tant que variables de contexte de modèle que Jinja2 échappe automatiquement. Si vous devez utiliser des modèles dynamiques, échappez l'entrée utilisateur avec markupsafe.escape() ou flask.escape() avant de l'intégrer dans la chaîne de modèle. N'utilisez jamais le filtre | safe sur des données non fiables dans les modèles. Pour les cas où vous devez construire du contenu dynamique, envisagez d'utiliser l'héritage de modèle ou des inclusions avec des modèles de base statiques. Implémentez des en-têtes de Politique de Sécurité de Contenu (CSP) à l'aide de Flask-Talisman pour fournir une protection en profondeur. Utilisez bleach.clean() pour le contenu riche généré par l'utilisateur qui nécessite un formatage HTML.

OWASP :

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

python_flask_rule_reflected_xss_user_input

Résumé :

Neutralisation incorrecte des entrées utilisateur rendues en HTML (XSS)

Gravité : Élevée

CWE : CWE-79

Description :

Les entrées utilisateur des objets de requête (args, form, values, json) sont directement utilisées dans la sortie HTML sans désinfection appropriée, créant ainsi une vulnérabilité XSS réfléchie. Il est essentiel de désinfecter les entrées utilisateur avant de les inclure dans les réponses HTML en utilisant la fonction d'échappement de Flask, l'échappement de MarkupSafe, html.escape() ou bleach.clean(). Utilisez des modèles Flask (Jinja2) qui échappent automatiquement les variables par défaut plutôt que de construire manuellement du HTML. Pour les contextes JavaScript ou les attributs d'URL, utilisez une désinfection spécifique au contexte car l'échappement HTML seul est insuffisant.

Remédiation :

Considérez l'utilisation de la fonction render_template() de Flask avec des modèles Jinja2 au lieu de retourner des chaînes HTML construites manuellement, car les modèles fournissent un échappement HTML automatique par défaut. Si vous devez retourner des chaînes HTML directement, échappez les entrées utilisateur avec markupsafe.escape(), flask.escape(), html.escape() ou bleach.clean() avant de les inclure dans la réponse. Pour les réponses au format texte brut, utilisez Response(content, mimetype='text/plain') pour empêcher les navigateurs d'interpréter le contenu comme du HTML. Pour les réponses JSON, utilisez la fonction jsonify() de Flask qui gère l'échappement automatiquement. Implémentez des en-têtes de Politique de Sécurité de Contenu (CSP) en utilisant les extensions Flask-Talisman ou Flask-CSP pour fournir une protection en profondeur contre les attaques XSS. Pour les contextes JavaScript ou CSS, utilisez un échappement spécifique au contexte au-delà de l'échappement HTML standard.

OWASP :

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

python_log_rule-logging-config-insecure-listen

Résumé :

Contrôle inapproprié de la génération de code ('Injection de Code')

Gravité : Élevée

CWE : CWE-94

Description :

L'application appelle logging.config.listen(), qui crée un serveur socket pour recevoir la configuration de logging provenant de sources externes. Cette fonction appelle en interne eval() sur les données de configuration reçues, permettant l'exécution de code arbitraire par des utilisateurs locaux ou des attaquants distants exploitant des vulnérabilités SSRF pour envoyer des configurations de logging malveillantes.

Remédiation :

Envisagez de supprimer complètement l'appel à logging.config.listen() et d'utiliser des fichiers de configuration statiques chargés au démarrage à la place. Il est recommandé d'utiliser logging.config.fileConfig() ou logging.config.dictConfig() avec des fichiers de configuration qui sont en lecture seule et appartiennent à des utilisateurs de confiance. Si une configuration de logging dynamique est nécessaire, implémentez un chargeur de configuration personnalisé avec une validation stricte des entrées qui n'utilise pas eval() ou d'autres mécanismes d'exécution de code.

OWASP :

  • A1:2017-Injection
  • A03:2021-Injection

python_rule_sql_injection

Résumé :

Requête SQL non sécurisée avec des paramètres non paramétrés

Sévérité : Élevée

CWE : CWE-89

Description :

Vulnérabilité d'injection SQL détectée : l'entrée contrôlée par l'utilisateur est intégrée dans une requête SQL en utilisant le formatage de chaînes Python (opérateur %), la concaténation (+), les f-strings ou .format(). Cela permet aux attaquants de manipuler la logique de la requête et potentiellement d'accéder, de modifier ou de supprimer des données de la base de données.

Remédiation :

Envisagez d'utiliser des requêtes paramétrées avec des espaces réservés au lieu de la concaténation de chaînes. Utilisez le lien des paramètres comme cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,)) ou des paramètres nommés comme session.exec("SELECT :col", {"col": value}). Évitez les espaces réservés entre guillemets comme '%s'. Il est recommandé d'utiliser des constructeurs de requêtes ORM (Django ORM, SQLAlchemy, SQLModel, Peewee) qui gèrent automatiquement la paramétrisation et offrent une protection supplémentaire contre les injections SQL.

OWASP :

  • A1:2017-Injection
  • A03:2021-Injection

python_rule_sql_injection_queries

Résumé :

Requête SQL non sécurisée avec des paramètres non paramétrés

Sévérité : Élevée

CWE : CWE-89

Description :

Vulnérabilité d'injection SQL détectée : la requête SQL utilise une insertion de paramètres dynamique non sécurisée via des espaces réservés entre guillemets ('%s'), .format(), concaténation de chaînes, f-strings ou opérateurs +=. Cela permet aux attaquants de s'échapper du contexte de la requête et d'exécuter des commandes SQL arbitraries.

Remédiation :

Envisagez d'utiliser des requêtes correctement paramétrées avec des listes de paramètres ou des tuples séparés. Utilisez des modèles comme cursor.execute("SELECT %s FROM table", (input,)) ou execute("SELECT :name", {"name": value}) au lieu de formats de chaîne ou de concaténation. Ne jamais mettre des guillemets autour des espaces réservés comme '%s'. Il est recommandé d'utiliser des frameworks ORM (Django ORM, SQLAlchemy, SQLModel) lorsque cela est possible, car ils offrent une protection intégrée contre les injections SQL. Établissez du SQL brut uniquement lorsque les ORM ne peuvent pas répondre au besoin.

OWASP :

  • A1:2017-Injection
  • A03:2021-Injection

python_rule_ssrf

Résumé :

Demande à une URL contrôlable par l'utilisateur menant à SSRF

Sévérité : Élevée

CWE : CWE-918

Description :

Cette règle a détecté des entrées contrôlées par l'utilisateur utilisées pour construire des URLs pour des bibliothèques cliente HTTP Python, y compris requests.get(), requests.post(), urllib.request.urlopen(), http.client.HTTPConnection(), socket.connect(), tornado.httpclient.fetch(), aiohttp.ClientSession.get(), pyramid.request.Request.blank(), xmlrpc.client.ServerProxy(), zeep.Client(), suds.client.Client(), pycurl.Curl.setopt(), et des appels subprocess à curl ou wget. L'analyse de contamination suit les entrées utilisateur provenant de sources telles que les paramètres de requête Flask, les arguments de ligne de commande, l'entrée standard, et les messages WebSocket vers ces puits de requête réseau. Lorsque l'entrée utilisateur contrôle des URLs sans validation, des vulnérabilités de falsification de requête côté serveur (SSRF) apparaissent, permettant aux attaquants de forcer le serveur à accéder à des services internes (localhost:8080/admin), à des points de terminaison de métadonnées cloud (169.254.169.254), ou à des systèmes externes arbitraires, exposant potentiellement des données sensibles ou permettant une reconnaissance réseau contournant les protections par pare-feu.

Remédiation :

Envisagez de mettre en œuvre une liste blanche stricte d'URLs qui valide les entrées utilisateur contre des domaines approuvés en utilisant urllib.parse.urlparse() de Python pour extraire et valider les composants du schéma, de l'hôte, et du port avant de faire des requêtes. Limitez les protocoles autorisés à http:// et https:// uniquement, en rejetant explicitement file://, gopher://, ftp://, et d'autres schémas dangereux. Mettez en œuvre une protection contre le rebinding DNS en résolvant les noms d'hôtes en utilisant socket.gethostbyname() et en bloquant les connexions vers des plages d'adresses IP privées (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) et des adresses de métadonnées cloud (169.254.169.254) en utilisant des bibliothèques comme ipaddress.ip_address() et is_private. Pour les applications utilisant la bibliothèque requests, configurez des adaptateurs de transport personnalisés avec requests.adapters.HTTPAdapter pour faire respecter les restrictions de connexion. Désactivez les redirections HTTP ou implémentez une validation stricte des redirections pour éviter les contournements SSRF basés sur des redirections. Envisagez d'acheminer toutes les requêtes sortantes via un proxy de sortie surveillé avec filtrage des requêtes, ou utilisez des contrôles au niveau réseau comme des règles iptables pour restreindre l'accès réseau de l'application. Utilisez une approche de mappage côté serveur où l'entrée utilisateur fournit des clés qui mappent à des URLs sûres préconfigurées plutôt que d'accepter des URLs arbitraires.

OWASP :

- A10:2021-Falsification de Requêtes Côté Serveur (SSRF)

python_tornado_rule_reflected_xss

Résumé :

Neutralisation incorrecte des entrées utilisateur rendues dans Tornado ('XSS')

Gravité : Élevée

CWE : CWE-79

Description :

Les entrées contrôlées par l'utilisateur transmises aux méthodes self.write() ou self.redirect() de Tornado peuvent mener à des attaques XSS, car elles n'échappent pas la variable. Il est préférable d'utiliser les méthodes render() de tornado.web.RequestHandler qui échappent automatiquement les variables rendues dans le modèle. Si vous devez utiliser self.write() ou self.redirect(), assurez-vous de les assainir en utilisant tornado.escape.xhtml_escape(...) ou tornado.escape.url_escape(...) si c'est une URL.

Remédiation :

Envisagez d'utiliser la méthode self.render() de Tornado au lieu de self.write() pour les réponses HTML, car self.render() utilise des modèles avec échappement HTML automatique activé par défaut. Si vous devez utiliser self.write(), échappez manuellement l'entrée utilisateur avec tornado.escape.xhtml_escape() avant de l'écrire dans la réponse. Pour les redirections d'URL contenant des entrées utilisateur, utilisez tornado.escape.url_escape() pour encoder correctement les données. Pour les réponses JSON, utilisez tornado.escape.json_encode() qui gère automatiquement l'échappement. Évitez de construire manuellement des chaînes HTML avec des entrées utilisateur - préférez le rendu de modèle qui fournit un échappement contextuel. Pour les téléchargements de fichiers accessibles via self.request.files, assurez-vous que les noms de fichiers et le contenu sont validés et échappés avant d'être affichés. Mettez en œuvre des en-têtes de politique de sécurité de contenu (CSP) en utilisant self.set_header() pour fournir une protection en profondeur contre les attaques XSS.

OWASP :

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

python_tornado_rule_reflected_xss_csp

Résumé :

Neutralisation inadéquate des entrées utilisateur rendues en HTML ('XSS')

Sévérité : Élevée

CWE : CWE-79

Description :

L'application configure une politique de sécurité du contenu (CSP) insecure dans Tornado en utilisant self.set_header(). La politique contient des directives dangereuses telles que unsafe-inline, unsafe-eval, unsafe-hashes, ou des sources à wildcard (*), ou désactive explicitement la protection XSS avec X-XSS-Protection: 0. Ces configurations contournent les protections XSS des navigateurs et permettent l'exécution de scripts en ligne, permettant aux attaquants d'injecter et d'exécuter du JavaScript malveillant.

Remédiation :

Retirez unsafe-inline, unsafe-eval, et unsafe-hashes de vos directives CSP. Envisagez d'implémenter une CSP basée sur des nonce ou des hashes pour les scripts en ligne utilisant les directives nonce- ou sha256-. Remplacez les sources à wildcard (*) par des listes d'autorisation de domaines spécifiques ou utilisez 'self' pour restreindre les ressources uniquement à la même origine. Assurez-vous que X-XSS-Protection est défini sur 1 ou complètement omis (les navigateurs modernes utilisent CSP à la place). Pour les applications Tornado, définissez des en-têtes sécurisés dans la méthode set_default_headers() d'un gestionnaire de base.

OWASP :

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

python_tornado_rule_reflected_xss_global

Résumé :

Neutralisation incorrecte des entrées utilisateur rendues en HTML ('XSS')

Gravité : Élevée

CWE : CWE-79

Description :

L'application Tornado désactive globalement l'auto-échappement HTML en définissant autoescape=None dans le constructeur tornado.web.Application(), l'initialisation de la sous-classe Application, ou la configuration de tornado.template.Loader(). Cela supprime la protection par défaut de Tornado contre les XSS pour tous les templates de l'application, créant des vulnérabilités de Cross-Site Scripting partout où des données fournies par l'utilisateur sont rendues. Contrairement aux contrôles d'échappement au niveau du template, cette configuration globale affecte tous les templates affichés par l'application, y compris les templates et inclus tiers. En définissant autoescape=None, cela signifie que toutes les variables de template {{ variable }} seront rendues sans encodage HTML, permettant l'exécution de JavaScript malveillant dans les entrées utilisateur dans les navigateurs des victimes.

Remédiation :

Considérez à maintenir l'auto-échappement par défaut de Tornado activé en supprimant autoescape=None des configurations d'Application et de Loader ou en utilisant autoescape="xhtml_escape" explicitement. Le comportement par défaut de Tornado échappe automatiquement HTML dans les variables de template, protégeant contre les attaques XSS. Si vous devez rendre du HTML de confiance dans des templates spécifiques, utilisez le directif {% raw %} ou la syntaxe {{! }} de manière sélective plutôt que de désactiver l'échappement globalement. Pour le contenu généré par l'utilisateur qui nécessite un formatage HTML, utilisez un sanitiseur basé sur une liste blanche comme bleach ou nh3 en Python avant de passer les données aux templates. Utilisez les fonctions d'échappement de Tornado lors de la construction de réponses manuellement : tornado.escape.xhtml_escape() pour HTML, tornado.escape.url_escape() pour les URL, et tornado.escape.json_encode() pour JSON. Implémentez des en-têtes de Content Security Policy (CSP) avec self.set_header() pour fournir une protection en profondeur.

OWASP :

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

python_crypto_rule-cipher-modes

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Gravité : Moyenne

CWE : CWE-327

Description :

L'application utilise cryptography.hazmat.primitives.ciphers.modes.ECB() pour instancier le mode de chiffrement ECB (Electronic Codebook), qui est cryptographiquement dangereux car il manque de vérification de l'intégrité des messages. Sans intégrité du message, un adversaire peut manipuler le texte chiffré de manière à compromettre la clé de chiffrement ou modifier le texte clair déchiffré de façon prévisible. Le mode ECB révèle également des modèles dans le texte clair puisque des blocs de texte clair identiques produisent des blocs de texte chiffré identiques, le rendant particulièrement vulnérable aux attaques d'analyse. Les meilleures pratiques cryptographiques modernes exigent un chiffrement authentifié qui combine protection de la confidentialité et de l'intégrité.

Remédiation :

Envisagez de migrer vers ChaCha20Poly1305 du package cryptography, qui fournit un chiffrement authentifié intégré et est plus rapide et plus facile à utiliser correctement que les modes de chiffrement configurés manuellement. Pour les applications nécessitant la compatibilité avec AES, AES-256-GCM peut être utilisé, mais faites attention à la réutilisation des nonces avec GCM qui entraîne des échecs de sécurité catastrophiques - les nonces doivent être générées en utilisant os.urandom(12) et ne jamais être réutilisées avec la même clé. ChaCha20Poly1305 est généralement recommandé pour les nouvelles applications Python car il évite la complexité de configuration des modes de chiffrement et les catastrophes liées à la mauvaise utilisation des nonces associées à AES-GCM. Les deux algorithmes sont disponibles dans le package cryptography sur https://cryptography.io/en/latest/hazmat/primitives/aead/. Exemples d'implémentations : ChaCha20Poly1305.generate_key() crée une clé sécurisée, et encrypt(nonce, plaintext, aad) fournit un chiffrement authentifié en une seule opération.

OWASP :

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

python_crypto_rule-crypto-cipher-blowfish

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Sévérité : Moyenne

CWE : CWE-327

Description :

L'application utilise Crypto.Cipher.Blowfish.new() ou Cryptodome.Cipher.Blowfish.new() pour instancier des chiffres Blowfish. Le chiffre Blowfish a une taille de bloc de 64 bits, ce qui le rend vulnérable aux attaques par anniversaire après avoir traité environ 4 Go de données avec la même clé. Cette limitation pratique signifie que Blowfish ne devrait pas être utilisé pour le chiffrement de masse dans les applications modernes, en particulier pour des scénarios à fort débit comme le chiffrement de fichiers ou les protocoles réseau. Bien que Blowfish ait été conçu en 1993 comme un remplacement du DES et qu'aucune brèche cryptanalytique majeure ne soit connue, sa petite taille de bloc représente une faiblesse fondamentale qui ne peut pas être atténuée par des modifications de configuration.

Remédiation :

Envisagez de migrer vers ChaCha20Poly1305 du package cryptography, qui fournit un chiffrement authentifié avec un design de chiffre de flux moderne qui évite complètement les limitations de taille de bloc. Pour les applications nécessitant une compatibilité AES, AES-256-GCM peut être utilisé à la place, bien qu'il faille être conscient qu'il nécessite une gestion minutieuse des nonces pour éviter des défaillances catastrophiques dues à la réutilisation des nonces. Les packages Crypto et Cryptodome détectés dans cette constatation ne sont plus recommandés pour les nouvelles applications Python - le package cryptography disponible sur https://cryptography.io/ offre de meilleures valeurs par défaut en matière de sécurité et est plus activement maintenu. Lors de la migration depuis Blowfish, assurez-vous d'utiliser des modes de chiffrement authentifié comme ChaCha20Poly1305 ou AES-GCM plutôt que de passer à un autre mode de chiffrement non authentifié, car le chiffrement authentifié offre à la fois confidentialité et protection de l'intégrité.

OWASP :

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

python_crypto_rule-crypto-cipher-des

Résumé :

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

Gravité : Moyenne

CWE : CWE-327

Description :

L'application utilise Crypto.Cipher.DES.new() ou Cryptodome.Cipher.DES.new() pour instancier des chiffrements DES. Le DES (Data Encryption Standard) est un algorithme cryptographique défectueux qui utilise une taille de clé de 56 bits insuffisante, le rendant vulnérable aux attaques par force brute avec la puissance de calcul moderne. Le DES a été officiellement déprécié par le NIST en 2005 et ne devrait jamais être utilisé pour chiffrer des données sensibles. L'utilisation du DES dans les packages Crypto ou Cryptodome indique une dépendance à des bibliothèques cryptographiques obsolètes qui manquent de caractéristiques de sécurité modernes comme le chiffrement authentifié et la dérivation appropriée des clés.

Remédiation :

Envisagez de migrer vers ChaCha20Poly1305 à partir du package cryptography, qui fournit un chiffrement authentifié à la fois plus rapide et plus sûr que le DES. ChaCha20Poly1305 est préféré à l'AES-256-GCM pour la plupart des applications Python car il est plus facile à utiliser correctement et ne présente pas les vulnérabilités catastrophiques de réutilisation de nonce qui affectent les modes GCM. Les packages Crypto et Cryptodome détectés dans cette constatation ne sont plus recommandés pour les nouvelles applications Python - migrez vers le package cryptography sur https://cryptography.io/ qui offre de meilleures valeurs par défaut en matière de sécurité, une maintenance active et un chiffrement authentifié moderne. Lors du remplacement du DES, assurez-vous d'utiliser des modes de chiffrement authentifiés (ChaCha20Poly1305 ou AES-GCM) plutôt que des chiffrements par blocs non authentifiés, car les normes de sécurité modernes exigent à la fois la protection de la confidentialité et de l'intégrité. Notez que toute donnée chiffrée avec le DES doit être rechiffrée avec un algorithme moderne dès que possible.

OWASP :

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

python_crypto_rule-crypto-cipher-rc2

Résumé :

Utilisation d'un algorithme cryptographique brisé ou risqué

Gravité : Moyenne

CWE : CWE-327

Description :

L'application utilise Crypto.Cipher.ARC2.new() ou Cryptodome.Cipher.ARC2.new() pour instancier des chiffrements RC2. RC2 (Rivest Cipher 2) est un algorithme cryptographique brisé présentant des faiblesses connues, y compris une vulnérabilité aux attaques par clés connexes et un mauvais plan de clés. RC2 utilise des tailles de clés variables, mais même avec une longueur de clé maximale, il reste cryptographiquement faible selon les normes modernes. Conçu en 1987 et ensuite désassemblé, RC2 manque de l'examen cryptanalytique et des propriétés de sécurité requises pour le chiffrement moderne, notamment l'absence de chiffrement authentifié permettant de falsifier le texte chiffré.

Remédiation :

Envisagez de migrer vers ChaCha20Poly1305 à partir du package cryptography, qui fournit un chiffrement authentifié à la fois plus rapide et plus sûr que RC2. ChaCha20Poly1305 est recommandé par rapport à AES-256-GCM pour la plupart des applications Python, car il est plus facile à utiliser correctement et évite les vulnérabilités catastrophiques de réutilisation de nonce présentes dans les modes GCM. Les packages Crypto et Cryptodome détectés dans cette constatation ne sont plus recommandés pour les nouvelles applications Python - migrez vers le package cryptography sur https://cryptography.io/ qui offre des primitives de chiffrement authentifié modernes et une maintenance de sécurité active. Lors du remplacement de RC2, assurez-vous d'utiliser des modes de chiffrement authentifié (ChaCha20Poly1305 ou AES-GCM) plutôt que de passer à un autre chiffre non authentifié, car les normes de sécurité modernes nécessitent à la fois une protection de la confidentialité et de l'intégrité.

OWASP :

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

python_crypto_rule-crypto-cipher-rc4

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Gravité : Moyenne

CWE : CWE-327

Description :

L'application utilise Crypto.Cipher.ARC4.new() ou Cryptodome.Cipher.ARC4.new() pour instancier des chiffrages RC4. RC4 (Rivest Cipher 4 ou ARC4) est un chiffre de flux largement cassé avec de multiples attaques pratiques, y compris des biais dans le keystream, des attaques par clé liée et des attaques de récupération de texte en clair. RC4 a été officiellement interdit d'utilisation dans TLS par la RFC 7465 en 2015 et ne doit jamais être utilisé dans aucun contexte sensible à la sécurité. Les faiblesses du chiffre permettent aux attaquants de récupérer le texte en clair à partir du texte chiffré dans des scénarios réalistes, en particulier dans des protocoles comme WEP et les premières versions de TLS où RC4 a été historiquement déployé.

Remédiation :

Envisagez de migrer vers ChaCha20Poly1305 à partir du package de cryptographie, qui fournit un chiffrement authentifié en utilisant un design de chiffre de flux moderne et sécurisé. ChaCha20Poly1305 est recommandé par rapport à AES-256-GCM pour la plupart des applications Python, car il est plus rapide dans les implémentations logicielles et plus facile à utiliser correctement sans les vulnérabilités catastrophiques de réutilisation de nonce qui affligent les modes GCM. Les packages Crypto et Cryptodome détectés dans cette découverte ne sont plus recommandés pour de nouvelles applications Python - migrez vers le package de cryptographie sur https://cryptography.io/ qui fournit des primitives de chiffrement authentifié modernes avec de meilleurs réglages de sécurité par défaut. Lors de la substitution de RC4, assurez-vous que des modes de chiffrement authentifié (ChaCha20Poly1305 ou AES-GCM) sont utilisés, car les normes de sécurité modernes exigent à la fois la confidentialité et la protection de l'intégrité. Toute donnée chiffrée avec RC4 doit être considérée comme potentiellement compromise et doit être réchiffrée immédiatement avec un algorithme sécurisé.

OWASP :

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

python_crypto_rule-crypto-cipher-xor

Résumé :

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

Gravité : Moyenne

CWE : CWE-327

Description :

L'application utilise Crypto.Cipher.XOR.new() ou Cryptodome.Cipher.XOR.new() pour instancier des ciphers XOR. Le cipher XOR n'est pas un algorithme de chiffrement sécurisé et ne fournit qu'une obfuscation triviale qui peut être facilement contournée. Le chiffrement XOR avec une clé répétée est vulnérable à l'analyse de fréquence, aux attaques par texte clair connu et peut souvent être déchiffré avec des outils automatisés en quelques secondes. Utiliser XOR comme primitive de chiffrement dans les paquets Crypto ou Cryptodome représente un malentendu fondamental de la sécurité cryptographique, car XOR seul manque de dérivation de clé, d'authentification, et des propriétés cryptographiques nécessaires à la confidentialité.

Remédiation :

Envisagez de migrer vers ChaCha20Poly1305 à partir du paquet cryptography, qui fournit un vrai chiffrement authentifié au lieu d'une simple obfuscation. ChaCha20Poly1305 est recommandé par rapport à AES-256-GCM pour la plupart des applications Python car il est plus facile à utiliser correctement et fournit à la fois protection de la confidentialité et intégrité en une seule opération. Les paquets Crypto et Cryptodome détectés dans cette découverte ne sont plus recommandés pour de nouvelles applications Python - migrez vers le paquet cryptography à https://cryptography.io/ qui fournit des primitives de chiffrement authentifié modernes avec de bonnes garanties de sécurité. Lors de la substitution du chiffrement XOR, veillez à utiliser des modes de chiffrement authentifié (ChaCha20Poly1305 ou AES-GCM), car les normes de sécurité modernes exigent des algorithmes cryptographiquement sécurisés avec dérivation de clé, mode de fonctionnement approprié et authentification de message. Notez que toute donnée "chiffrée" avec XOR doit être considérée comme exposée et doit être immédiatement re-chiffrée avec un algorithme cryptographique approprié.

OWASP :

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

python_crypto_rule-crypto-encrypt-dsa-rsa

Résumé :

Force de cryptage inadéquate

Gravité : Moyenne

CWE : CWE-326

Description :

L'application utilise Crypto.PublicKey.RSA.generate(), Cryptodome.PublicKey.RSA.generate(), Crypto.PublicKey.DSA.generate(), Cryptodome.PublicKey.DSA.generate(), ou cryptography.hazmat.primitives.asymmetric.rsa.generate_private_key() / cryptography.hazmat.primitives.asymmetric.dsa.generate_private_key() avec une taille de clé de moins de 2048 bits, ce qui offre une sécurité inadéquate contre les attaques de factorisation modernes. Le NIST a déprécié les clés RSA de 1024 bits en décembre 2010, et bien qu'elles n'aient pas encore été publiquement factorisées, les avancées en puissance de calcul et les améliorations algorithmiques rendent la factorisation de plus en plus réalisable. Les clés RSA et DSA de moins de 2048 bits sont considérées comme cryptographiquement faibles et inadaptées à la protection des données sensibles, en particulier pour des exigences de sécurité à long terme telles que la signature de certificats ou les protocoles d'accord de clé.

Remédiation :

Envisagez d'utiliser les algorithmes de courbe elliptique modernes X25519 ou Ed25519 du paquet de cryptographie, qui offrent une sécurité plus forte avec des tailles de clé plus petites et de meilleures performances que RSA ou DSA. Pour l'échange de clés, X25519PrivateKey.generate() gère la génération de clés avec des valeurs par défaut sécurisées, tandis qu'Ed25519PrivateKey.generate() fournit des signatures numériques sécurisées. Si RSA ou DSA doivent être utilisés pour des raisons de compatibilité, utilisez une taille de clé minimale de 2048 bits, bien que 3072 ou 4096 bits soient recommandés pour une sécurité à long terme. Lors de la génération de clés RSA avec cryptography.hazmat.primitives.asymmetric.rsa.generate_private_key(), utilisez toujours public_exponent=65537 et key_size=4096 pour les nouvelles applications. Notez que les paquets Crypto et Cryptodome détectés dans cette constatation ne sont plus recommandés - migrez vers le paquet de cryptographie à l'adresse https://cryptography.io/en/latest/ pour de meilleures valeurs par défaut de sécurité et un entretien actif.

OWASP :

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

python_crypto_rule-crypto-encrypt-ec

Résumé :

Force de chiffrement inadéquate

Gravité : Moyenne

CWE : CWE-326

Description :

L'application utilise cryptography.hazmat.primitives.asymmetric.ec.generate_private_key() avec des paramètres de courbe elliptique faibles - en particulier ec.SECP192R1() (192 bits), ec.SECT163K1() (163 bits) ou ec.SECT163R2() (163 bits). Ces courbes offrent des marges de sécurité inadéquates contre les attaques cryptanalytiques modernes et ne répondent pas à la recommandation minimale de 224 bits de la NIST. L'utilisation de courbes elliptiques faibles dans le paquet de cryptographie peut conduire à des échanges de clés ou des signatures numériques compromis, en particulier à mesure que la puissance de calcul augmente et que les techniques cryptanalytiques s'améliorent.

Remédiation :

Envisagez de passer aux courbes SECP384R1 ou SECP256R1 lors de l'utilisation des courbes NIST P, qui offrent respectivement des niveaux de sécurité de 384 bits et 256 bits. Pour les nouvelles applications, les courbes modernes Ed25519 ou X25519 sont recommandées par rapport aux courbes NIST P car elles offrent de meilleures propriétés de sécurité, sont plus faciles à implémenter correctement et offrent de meilleures performances. Utilisez Ed25519PrivateKey.generate() pour les signatures numériques ou X25519PrivateKey.generate() pour l'échange de clés à partir des modules cryptography.hazmat.primitives.asymmetric.ed25519 et x25519. Si des courbes NIST P sont nécessaires pour la compatibilité, utilisez ec.SECP384R1() ou ec.SECP256R1() avec ec.generate_private_key() - évitez les courbes en dessous de 224 bits de force de sécurité. Plus d'informations sur la cryptographie à courbe elliptique sont disponibles sur https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ec/.

OWASP :

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

python_crypto_rule-crypto-hash-md5

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Sévérité : Moyenne

CWE : CWE-327

Description :

L'application utilise Crypto.Hash.MD5.new() ou Cryptodome.Hash.MD5.new() pour instancier des objets de hachage MD5. MD5 est un algorithme de hachage cryptographiquement cassé et vulnérable aux attaques par collision, où les attaquants peuvent générer différentes entrées produisant la même sortie de hachage. Les attaques par collision contre MD5 sont pratiques et ont été démontrées depuis 2004, rendant MD5 inadapté pour toute application critique en matière de sécurité, y compris les signatures numériques, la validation de certificats ou la vérification d'intégrité. L'utilisation de MD5 dans les packages Crypto ou Cryptodome indique une dépendance à des bibliothèques cryptographiques obsolètes pour une fonction de hachage déjà cassée.

Remédiation :

Envisagez de migrer vers SHA-256 ou SHA-384 du package cryptography pour le hachage général et la vérification d'intégrité. Si cette utilisation de MD5 concerne le hachage de mots de passe, migrez vers un algorithme de hachage de mots de passe dédié comme Argon2id, bcrypt ou PBKDF2 au lieu de toute fonction de hachage généraliste. Utilisez hashes.Hash(hashes.SHA256()) du module cryptography.hazmat.primitives pour créer des résumés de message sécurisés. Les packages Crypto et Cryptodome détectés dans cette constatation ne sont plus recommandés pour les nouvelles applications Python - migrez vers le package cryptography à https://cryptography.io/ pour de meilleures configurations de sécurité. Notez que MD5 ne doit jamais être utilisé à des fins de sécurité, même dans les implémentations de protocoles hérités, bien qu'il puisse être acceptable pour des cas d'utilisation non sécuritaires comme les sommes de contrôle pour détecter une corruption accidentelle des données. Pour des conseils sur le stockage de mots de passe, consultez la feuille de triche sur le stockage de mots de passe OWASP à https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html.

OWASP :

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

python_crypto_rule-crypto-hash-sha1

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Gravité : Moyenne

CWE : CWE-327

Description :

L'application utilise Crypto.Hash.SHA.new() ou Cryptodome.Hash.SHA.new() pour instancier des objets de hachage SHA-1. SHA-1 est un algorithme de hachage cryptographiquement cassé, vulnérable aux attaques par collision, où des attaquants peuvent générer différentes entrées produisant la même sortie de hachage. Des attaques par collision pratiques contre SHA-1 ont été démontrées en 2017 avec l'attaque SHAttered, et SHA-1 a été déconseillé pour la plupart des usages de sécurité par les principaux organismes de normalisation et les fournisseurs de navigateurs. L'utilisation de SHA-1 dans les paquets Crypto ou Cryptodome indique une dépendance à des bibliothèques cryptographiques obsolètes pour une fonction de hachage déjà cassée, qui ne devrait pas être utilisée pour les signatures numériques, la validation de certificats ou la vérification d'intégrité.

Remédiation :

Envisagez de migrer vers SHA-256 ou SHA-384 du paquet cryptography pour le hachage général et la vérification d'intégrité. Si cette utilisation de SHA-1 concerne le hachage de mots de passe, migrez vers un algorithme de hachage de mots de passe dédié tel qu'Argon2id, bcrypt ou PBKDF2 au lieu de toute fonction de hachage générale. Utilisez hashes.Hash(hashes.SHA256()) ou hashes.Hash(hashes.SHA384()) de cryptography.hazmat.primitives pour créer des résumés de message sécurisés. Les paquets Crypto et Cryptodome détectés dans cette découverte ne sont plus recommandés pour les nouvelles applications Python - migrez vers le paquet cryptography à l'adresse https://cryptography.io/ pour de meilleures valeurs par défaut en matière de sécurité. Notez que SHA-1 peut encore être requis pour la compatibilité avec des systèmes hérités comme Git ou des protocoles plus anciens, mais ne devrait jamais être utilisé dans de nouveaux contextes critiques pour la sécurité ou lorsque la résistance aux collisions est requise. Pour des conseils sur le stockage des mots de passe, consultez la OWASP Password Storage Cheat Sheet à l'adresse https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html.

OWASP :

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

python_crypto_rule-crypto-hazmat-cipher-arc4

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Sévérité : Moyenne

CWE : CWE-327

Description :

L'application utilise cryptography.hazmat.primitives.ciphers.algorithms.ARC4() pour instancier des chiffrements RC4. RC4 (également connu sous le nom d'ARC4 ou Rivest Cipher 4) est un chiffre de flux complètement cassé avec de multiples attaques pratiques, y compris des biais dans le flux de clés, des attaques liées à la clé et des attaques de récupération de texte en clair. RC4 a été officiellement interdit pour une utilisation dans TLS par le RFC 7465 en 2015 et ne devrait jamais être utilisé dans un contexte sensible à la sécurité. Les faiblesses de ce chiffre permettent aux attaquants de récupérer du texte en clair à partir de ciphertext dans des scénarios réalistes, notamment dans des protocoles comme WEP et les premières versions de TLS où RC4 a été historiquement déployé.

Remédiation :

Envisagez de passer à ChaCha20Poly1305 du paquet cryptography, qui fournit une encryption authentifiée utilisant un design de chiffre de flux moderne et sécurisé. ChaCha20Poly1305 est recommandé par rapport à AES-256-GCM pour la plupart des applications car il est plus rapide dans les implémentations logicielles et plus facile à utiliser correctement sans les vulnérabilités catastrophiques de réutilisation de nonce qui affectent les modes GCM. Exemple d'implémentation : utilisez ChaCha20Poly1305.generate_key() pour créer une clé sécurisée, puis cryptez avec chacha.encrypt(nonce, plaintext, aad) où le nonce doit être généré en utilisant os.urandom(12) et ne jamais être réutilisé. Pour les applications nécessitant une compatibilité AES, AES-256-GCM peut être utilisé avec AESGCM.generate_key(bit_length=256), mais nécessite une gestion prudente du nonce pour éviter des échecs catastrophiques. Des exemples complets sont disponibles sur https://cryptography.io/en/latest/hazmat/primitives/aead/.

OWASP :

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

python_crypto_rule-crypto-hazmat-cipher-blowfish

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Sévérité : Moyenne

CWE : CWE-327

Description :

L'application utilise cryptography.hazmat.primitives.ciphers.algorithms.Blowfish() pour instancier des chiffrements Blowfish. Le chiffre Blowfish a une taille de bloc de 64 bits, ce qui le rend vulnérable aux attaques d'anniversaire après avoir traité environ 4 Go de données avec la même clé. Cette limitation pratique signifie que Blowfish ne devrait pas être utilisé pour le chiffrement de masse dans les applications modernes, en particulier pour des scénarios à haut débit comme le chiffrement de fichiers ou les protocoles réseau. Bien que Blowfish ait été conçu en 1993 comme un remplacement du DES et qu'aucune rupture cryptanalytique majeure ne soit connue, sa petite taille de bloc représente une faiblesse fondamentale qui ne peut pas être atténuée par des changements de configuration.

Remédiation :

Envisagez de migrer vers ChaCha20Poly1305 du package cryptography, qui fournit le chiffrement authentifié avec un design de flux moderne qui évite entièrement les limitations de taille de bloc. ChaCha20Poly1305 est généralement recommandé pour les nouvelles applications car il est plus rapide que l'AES-GCM et plus facile à utiliser correctement. Exemple : utilisez ChaCha20Poly1305.generate_key() pour créer une clé, puis chacha.encrypt(nonce, plaintext, aad) où nonce = os.urandom(12). Pour les applications nécessitant une compatibilité AES, l'AES-256-GCM peut être utilisé avec AESGCM.generate_key(bit_length=256), mais sachez qu'il requiert une gestion soigneuse des nonces pour éviter des échecs catastrophiques dus à la réutilisation des nonces. Lors de la migration de Blowfish, assurez-vous d'utiliser des modes de chiffrement authentifié plutôt que de passer à un autre chiffre non authentifié, car les normes modernes exigent à la fois la confidentialité et la protection de l'intégrité. Des exemples de code complets sont disponibles sur https://cryptography.io/en/latest/hazmat/primitives/aead/.

OWASP :

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

python_crypto_rule-crypto-hazmat-cipher-idea

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Gravité : Moyenne

CWE : CWE-327

Description :

L'application utilise cryptography.hazmat.primitives.ciphers.algorithms.IDEA() pour instancier les chiffrements IDEA. Le chiffre IDEA (International Data Encryption Algorithm) a été conçu en 1991 comme un remplacement de DES mais a depuis été trouvé avoir plusieurs faiblesses cryptographiques. Des vulnérabilités comprenant des classes de clés faibles et des attaques par clé connexe ont été identifiées, rendant IDEA inadapté aux applications cryptographiques modernes. Bien qu'IDEA utilise une taille de clé de 128 bits, ses défauts de conception et son absence de chiffrement authentifié signifient qu'il ne peut pas fournir les garanties de sécurité requises par les normes contemporaines.

Remédiation :

Envisagez de migrer vers ChaCha20Poly1305 du package cryptography, qui offre un chiffrement authentifié combinant confidentialité et protection de l'intégrité en une seule opération. ChaCha20Poly1305 est recommandé pour la plupart des applications, car il est plus rapide et plus facile à utiliser correctement que l'AES-GCM. Exemple : utilisez ChaCha20Poly1305.generate_key() pour créer une clé, puis chacha.encrypt(nonce, plaintext, aad) où nonce = os.urandom(12) et ne doit jamais être réutilisé. Pour les applications nécessitant une compatibilité AES, AES-256-GCM peut être utilisé avec AESGCM.generate_key(bit_length=256), mais nécessite une gestion prudente des nonces pour éviter des échecs de sécurité catastrophiques. Exemples de code et documentation complète disponibles sur https://cryptography.io/en/latest/hazmat/primitives/aead/.

OWASP :

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

python_crypto_rule-crypto.hazmat-hash-md5

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Sévérité : Moyenne

CWE : CWE-327

Description :

L'application utilise cryptography.hazmat.primitives.hashes.MD5() pour instancier des objets de hachage MD5. MD5 est un algorithme de hachage cryptographiquement cassé, vulnérable aux attaques par collision, où les attaquants peuvent générer des entrées différentes qui produisent la même sortie de hachage. Les attaques par collision contre MD5 sont pratiques et ont été démontrées depuis 2004, rendant MD5 inadapté à toute application critique pour la sécurité, y compris les signatures numériques, la validation des certificats ou la vérification d'intégrité. L'utilisation de MD5 via l'API cryptography.hazmat indique un usage direct d'une fonction de hachage cassée qui devrait être remplacée par des alternatives sécurisées.

Remédiation :

Envisagez de migrer vers SHA-256, SHA-384 ou SHA-512 du package cryptography pour le hachage et la vérification d'intégrité général. Utilisez hashes.Hash(hashes.SHA256()) pour créer des résumés de message sécurisés. Pour le hachage de mots de passe, migrez vers des algorithmes de hachage de mots de passe dédiés comme Argon2id (via le package argon2-cffi) ou PBKDF2, qui incluent des mécanismes appropriés de salage et d'étirement de clé. Exemple avec SHA-256 : digest = hashes.Hash(hashes.SHA256()); digest.update(b"data"); result = digest.finalize(). Notez que MD5 ne devrait jamais être utilisé à des fins de sécurité, même dans des implémentations de protocoles anciens, bien qu'il puisse être acceptable pour des cas d'utilisation non liés à la sécurité, comme les sommes de contrôle pour détecter la corruption de données accidentelle. Pour des conseils sur le stockage des mots de passe, consultez https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html.

OWASP :

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

python_crypto_rule-crypto.hazmat-hash-sha1

Résumé :

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

Sévérité : Moyenne

CWE : CWE-327

Description :

L'application utilise cryptography.hazmat.primitives.hashes.SHA1() pour instancier des objets de hachage SHA-1. Le SHA-1 est un algorithme de hachage cryptographiquement défaillant et vulnérable aux attaques par collision, où des attaquants peuvent générer des entrées différentes produisant la même sortie de hachage. Des attaques de collision pratiques contre le SHA-1 ont été démontrées en 2017 avec l'attaque SHAttered, et le SHA-1 a été déprécié pour la plupart des usages de sécurité par les principaux organismes de normalisation et fournisseurs de navigateurs. L'utilisation de SHA-1 via l'API cryptography.hazmat indique l'utilisation directe d'une fonction de hachage défaillante qui ne devrait pas être utilisée pour des signatures numériques, la validation de certificats ou la vérification d'intégrité dans des contextes sensibles à la sécurité.

Remédiation :

Envisagez de migrer vers SHA-256, SHA-384 ou SHA-512 à partir du paquet cryptography pour le hachage général et la vérification d'intégrité. Utilisez hashes.Hash(hashes.SHA256()) ou hashes.Hash(hashes.SHA384()) pour créer des résumés de message sécurisés. Pour le hachage de mots de passe, migrez vers des algorithmes de hachage de mots de passe dédiés comme Argon2id (via le paquet argon2-cffi) ou PBKDF2, qui incluent des mécanismes de salage appropriés et d'étirement de clé. Exemple avec SHA-256 : digest = hashes.Hash(hashes.SHA256()); digest.update(b"data"); result = digest.finalize(). Notez que le SHA-1 peut encore être requis pour la compatibilité avec des systèmes anciens comme Git ou des protocoles plus anciens, mais ne devrait jamais être utilisé dans de nouveaux contextes critiques pour la sécurité ou là où la résistance aux collisions est requise. Pour des conseils sur le stockage des mots de passe, consultez https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html.

OWASP :

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

python_crypto_rule-hash-md2

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Gravité : Moyenne

CWE : CWE-327

Description :

L'application utilise Crypto.Hash.MD2.new() ou Cryptodome.Hash.MD2.new() pour instancier des objets de hachage MD2. MD2 est un algorithme de hachage cryptographique gravement défaillant, avec des défauts de conception fondamentaux qui le rendent complètement inadapté à tout usage cryptographique. MD2 est vulnérable aux attaques par collision et a été déprécié depuis le début des années 2000 en raison de multiples attaques pratiques contre sa sécurité. L'utilisation de MD2 dans les packages Crypto ou Cryptodome indique une dépendance envers des bibliothèques cryptographiques obsolètes pour un algorithme qui ne devrait jamais être utilisé dans un contexte de sécurité.

Remédiation :

Envisagez de migrer vers SHA-256, SHA-384 ou SHA-512 du package cryptography pour le hachage général et la vérification d'intégrité. Utilisez hashes.Hash(hashes.SHA256()) de cryptography.hazmat.primitives pour créer des résumés de message sécurisés. Les packages Crypto et Cryptodome détectés dans cette constatation ne sont plus recommandés pour les nouvelles applications Python - migrez vers le package cryptography à l'adresse https://cryptography.io/ pour de meilleures options de sécurité par défaut. Pour le hachage de mots de passe, migrez vers des algorithmes de hachage de mots de passe dédiés comme Argon2id (via le package argon2-cffi) ou PBKDF2, qui incluent des mécanismes appropriés de salage et d'étirement des clés. Exemple avec SHA-384 : digest = hashes.Hash(hashes.SHA384()); digest.update(b"data"); result = digest.finalize(). Pour des conseils sur le stockage des mots de passe, consultez https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html.

OWASP :

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

python_crypto_rule-hash-md4

Résumé :

Utilisation d'un algorithme cryptographique obsolète ou risqué

Sévérité : Moyenne

CWE : CWE-327

Description :

L'application utilise Crypto.Hash.MD4.new() ou Cryptodome.Hash.MD4.new() pour instancier des objets de hachage MD4. MD4 est un algorithme de hachage cryptographique gravement défectueux, présentant des vulnérabilités sévères qui le rendent totalement inadapté à tout usage de sécurité. MD4 est vulnérable aux attaques par collision qui peuvent être exécutées en quelques secondes sur du matériel moderne, et il a été déconseillé depuis des décennies en raison de faiblesses cryptographiques fondamentales. L'utilisation de MD4 dans les packages Crypto ou Cryptodome indique une dépendance à des bibliothèques cryptographiques obsolètes pour un algorithme sans cas d'utilisation de sécurité moderne légitime.

Remédiation :

Envisagez de migrer vers SHA-256, SHA-384 ou SHA-512 à partir du package cryptography pour le hachage général et la vérification d'intégrité. Utilisez hashes.Hash(hashes.SHA256()) de cryptography.hazmat.primitives pour créer des résumés de message sécurisés. Les packages Crypto et Cryptodome détectés dans cette constatation ne sont plus recommandés pour les nouvelles applications Python - migrez vers le package cryptography à l'adresse https://cryptography.io/ pour de meilleurs paramètres de sécurité par défaut. Pour le hachage de mots de passe, migrez vers des algorithmes de hachage de mots de passe dédiés comme Argon2id (via le package argon2-cffi) ou PBKDF2, qui incluent des mécanismes de salage et d'étirement de clé appropriés. Exemple avec SHA-384 : digest = hashes.Hash(hashes.SHA384()); digest.update(b"data"); result = digest.finalize(). Pour des conseils sur le stockage des mots de passe, consultez https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html.

OWASP :

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

python_crypto_rule-hash-md5

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Gravité : Moyenne

CWE : CWE-327

Description :

L'application utilise hashlib.md5() pour instancier des objets de hachage MD5. MD5 est un algorithme de hachage cryptographiquement cassé, vulnérable aux attaques par collision, où les attaquants peuvent générer différentes entrées produisant la même sortie de hachage. Les attaques par collision contre MD5 sont pratiques et ont été démontrées depuis 2004, rendant MD5 inapproprié pour toute application critique en matière de sécurité, y compris les signatures numériques, la validation de certificats ou la vérification d'intégrité. L'utilisation de hashlib.md5() indique l'utilisation directe d'une fonction de hachage cassée qui devrait être remplacée par des alternatives sécurisées.

Remédiation :

Envisagez de remplacer hashlib.md5() par hashlib.sha256(), hashlib.sha384() ou hashlib.sha512() pour la vérification de l'intégrité des données et le hachage général. Exemple avec SHA-256 : digest = hashlib.sha256(); digest.update(b"data"); result = digest.digest(). Pour le hachage des mots de passe, migrez vers des algorithmes de hachage de mot de passe dédiés comme Argon2id (via le package argon2-cffi) ou PBKDF2 du package cryptography, qui incluent des mécanismes appropriés de salage et d'étirement de clé. Notez que MD5 ne doit jamais être utilisé à des fins de sécurité, même dans les mises en œuvre de protocoles hérités, bien qu'il puisse être acceptable pour des cas d'utilisation non sécurisés comme les sommes de contrôle pour détecter une corruption de données accidentelle. Pour des conseils sur le stockage des mots de passe, consultez https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html.

OWASP :

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

python_crypto_rule-hash-sha1

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Sévérité : Moyenne

CWE : CWE-327

Description :

L'application utilise hashlib.sha1() pour instancier des objets de hachage SHA-1. SHA-1 est un algorithme de hachage cryptographiquement cassé vulnérable aux attaques par collision, où les attaquants peuvent générer différentes entrées produisant la même sortie de hachage. Des attaques pratiques par collision contre SHA-1 ont été démontrées en 2017 avec l'attaque SHAttered, et SHA-1 a été déprécié pour la plupart des utilisations en matière de sécurité par les principaux organismes de normalisation et les fournisseurs de navigateurs. L'utilisation de hashlib.sha1() indique l'utilisation directe d'une fonction de hachage cassée qui ne devrait pas être utilisée pour les signatures numériques, la validation des certificats ou la vérification de l'intégrité dans des contextes sensibles à la sécurité.

Remédiation :

Envisagez de remplacer hashlib.sha1() par hashlib.sha256(), hashlib.sha384() ou hashlib.sha512() pour la vérification de l'intégrité des données et le hachage à usage général. Exemple avec SHA-256 : digest = hashlib.sha256(); digest.update(b"data"); result = digest.digest(). Pour le hachage de mots de passe, migrez vers des algorithmes de hachage de mots de passe dédiés comme Argon2id (via le package argon2-cffi) ou PBKDF2 du package cryptography, qui incluent des mécanismes de salage appropriés et d'étirement de clé. Notez que SHA-1 peut encore être requis pour la compatibilité avec des systèmes anciens comme Git ou des protocoles plus anciens, mais ne devrait jamais être utilisé dans de nouveaux contextes critiques pour la sécurité ou là où une résistance aux collisions est requise. Pour des conseils sur le stockage des mots de passe, voir https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html.

OWASP :

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

python_crypto_rule-hashlib-new-insecure-functions

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Gravité : Moyenne

CWE : CWE-327

Description :

L'application utilise hashlib.new() avec un paramètre de nom d'algorithme de hachage non sécurisé (MD2, MD4, MD5, SHA ou SHA-1) qui est vulnérable aux attaques par collision. Ces algorithmes de hachage se sont révélés être cryptographiquement cassés, où les attaquants peuvent générer différentes entrées produisant le même résultat de hachage. L'utilisation d'algorithmes de hachage non sécurisés via hashlib.new() rend le code moins évident et plus difficile à auditer, tout en n'offrant aucun avantage en matière de sécurité en raison des faiblesses fondamentales de ces algorithmes.

Remédiation :

Envisagez de remplacer les appels à hashlib.new() par des appels de fonction directs utilisant des algorithmes sécurisés : hashlib.sha256(), hashlib.sha384() ou hashlib.sha512() pour la vérification de l'intégrité des données et le hachage à usage général. Les appels de fonction directs comme hashlib.sha256() sont préférés à hashlib.new('sha256') pour une meilleure clarté du code et des audits de sécurité plus faciles. Exemple avec SHA-384 : digest = hashlib.sha384(); digest.update(b"data"); result = digest.digest(). Pour le hachage de mots de passe, migrez vers des algorithmes de hachage de mots de passe dédiés comme Argon2id (via le package argon2-cffi) ou PBKDF2 du package cryptography, qui incluent des mécanismes de salage et d'étirement de clés appropriés pour résister aux attaques par force brute. Évitez d'implémenter des algorithmes de hachage personnalisés, car cela est sujet à des erreurs et des vulnérabilités de sécurité.

OWASP :

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

python_crypto_rule-import-pycrypto

Résumé :

Utilisation de composants tiers non maintenus

Sévérité : Moyenne

CWE : CWE-1104

Description :

L'application importe depuis le package pycrypto en utilisant import Crypto.Cipher, import Crypto.Hash, ou d'autres imports de modules Crypto.*. Le package pycrypto a été abandonné depuis 2013 et contient des vulnérabilités de sécurité connues qui ne seront jamais corrigées. L'utilisation d'une bibliothèque cryptographique non maintenue pose de graves risques de sécurité, car les vulnérabilités nouvellement découvertes resteront non corrigées et exploitables. Le package pycrypto manque de primitives cryptographiques modernes et de fonctionnalités de sécurité qui sont standard dans les bibliothèques contemporaines.

Remédiation :

Envisagez de migrer vers le package cryptography, qui est activement maintenu, à l'adresse https://cryptography.io/, fournissant des implémentations modernes et sécurisées de primitives cryptographiques avec des mises à jour de sécurité régulières. Le package cryptography offre un support complet pour le chiffrement authentifié (ChaCha20Poly1305, AES-GCM), le hachage sécurisé (SHA-256, SHA-384, SHA-512), et le hachage de mots de passe (PBKDF2), ainsi qu'un support communautaire solide et un entretien actif. Pour le chiffrement authentifié, utilisez ChaCha20Poly1305.generate_key() et chacha.encrypt(nonce, plaintext, aad). Pour le hachage, utilisez hashes.Hash(hashes.SHA256()) de cryptography.hazmat.primitives. La migration implique généralement de remplacer les imports Crypto.Cipher par cryptography.hazmat.primitives.ciphers.aead pour des modes de chiffrement authentifié modernes.

OWASP :

  • A9:2017-Utilisation de composants ayant des vulnérabilités connues
  • A02:2021-Failles cryptographiques

python_escaping_rule-jinja2-autoescape-false

Résumé :

Encodage ou échappement incorrect de la sortie

Gravité : Moyenne

CWE : CWE-116

Description :

L'application utilise jinja2.Environment() sans activer l'auto-échappement. Lors du rendu de templates HTML avec des entrées fournies par l'utilisateur, cela permet à un contenu malveillant d'être rendu sous forme de JavaScript ou HTML exécutable, ce qui peut entraîner des attaques de Cross-Site Scripting (XSS) pouvant compromettre les sessions et les données des utilisateurs.

Remédiation :

Envisagez d'activer l'auto-échappement en passant autoescape=True ou autoescape=select_autoescape() lors de la création de l'environnement Jinja2. Notez que l'auto-échappement de Jinja2 fournit uniquement un échappement contextuel HTML et est insuffisant pour d'autres contextes (JavaScript, CSS, URLs, etc.). Pour des applications complexes, implémentez des filtres personnalisés utilisant des décorateurs @pass_eval_context pour gérer l'échappement spécifique au contexte. Il est recommandé de ne jamais afficher directement les entrées utilisateur dans des blocs JavaScript, et de valider/assainir toutes les entrées utilisateur avant le rendu.

OWASP :

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

python_escaping_rule-utilisation-des-templates-mako

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 utilise mako.template.Template() ou mako.lookup.TemplateLookup() sans spécifier default_filters. Lors du rendu de templates HTML avec des entrées fournies par l'utilisateur, cela permet à du contenu malveillant d'être rendu en tant que JavaScript ou HTML exécutable, conduisant à des attaques de Cross-Site Scripting (XSS) pouvant compromettre les sessions et les données des utilisateurs.

Remédiation :

Considérez l'ajout de default_filters=['h'] aux constructeurs Template ou TemplateLookup pour activer l'échappement HTML par défaut. Le filtre 'h' échappe automatiquement les variables dans les templates. Notez que cela ne protège que les contextes HTML et est insuffisant pour les contextes JavaScript, CSS ou URL. Pour des applications complexes, implémentez des filtres personnalisés pour l'échappement spécifique au contexte et importez-les via le paramètre imports. Il est recommandé de ne jamais afficher directement les entrées utilisateur dans des blocs JavaScript et de valider/désinfecter toutes les entrées utilisateur avant le rendu.

OWASP :

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

python_file-permissions_rule-general-bad-permission

Résumé :

Attribution incorrecte des permissions pour une ressource critique

Gravité : Moyenne

CWE : CWE-732

Description :

L'application utilise os.chmod() pour définir des permissions de fichier trop permissives, permettant un accès en écriture ou en exécution par le monde. Cela crée un risque de sécurité où des utilisateurs ou des processus non autorisés pourraient modifier ou exécuter des fichiers sensibles, ce qui pourrait entraîner une escalade de privilèges, une falsification de données ou l'exécution de code arbitraire.

Remédiation :

Envisagez de restreindre les permissions de fichier au strict minimum nécessaire pour l'application. Il est recommandé d'utiliser des valeurs octales comme 0o600 (lecture/écriture uniquement pour le propriétaire) ou 0o400 (lecture seule pour le propriétaire) lorsque l'utilisateur de l'application est le seul processus ayant besoin d'accès. Évitez les permissions qui accordent l'accès en écriture (0o2) ou en exécution (0o1) au groupe ou aux autres. Par exemple, utilisez os.chmod('file.txt', 0o600) au lieu de modes accessibles en écriture par le monde.

OWASP :

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

python_files_rule-tarfile-unsafe-members

Résumé :

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

Gravité : Moyenne

CWE : CWE-22

Description :

L'application utilise tarfile.extractall() sans validation appropriée du chemin, la rendant vulnérable aux attaques de traversal de chemin (Zip Slip). Des fichiers d'archive malveillants peuvent contenir des entrées avec des séquences de traversal de chemin telles que ../../etc/passwd qui échappent au répertoire d'extraction prévu, permettant aux attaquants d'écraser des fichiers système critiques ou d'implanter du code malveillant à des emplacements arbitraires.

Remédiation :

Considérez valider chaque membre d'archive avant extraction en utilisant tar.getmembers() et en vérifiant que les chemins n'échappent pas au répertoire cible. Il est recommandé de vérifier member.isfile() pour ignorer les liens symboliques et les répertoires, d'assainir les noms de fichiers en utilisant os.path.basename(), et de valider que le chemin résolu commence par votre répertoire prévu. Pour Python 3.12+, utilisez le paramètre filter='data' dans extractall() pour une protection automatique contre le traversal de chemin et d'autres attaques basées sur les archives.

OWASP :

  • A5:2017-Control d'accès brisé
  • A01:2021-Control d'accès brisé

python_flask_rule-app-debug

Résumé :

Code de débogage actif

Sévérité : Moyenne

CWE : CWE-489

Description :

L'application Flask utilise app.run(debug=True) ce qui active le débogueur interactif en production. Cela expose des informations sensibles telles que le code source, les variables d'environnement et les traces de pile via les réponses HTTP lorsque des exceptions se produisent. Le débogueur fournit également une console interactive accessible via un navigateur web, permettant aux attaquants d'exécuter un code Python arbitraire sur le serveur.

Remédiation :

Envisagez de désactiver le mode débogage en production en réglant debug=False ou en omettant complètement le paramètre. Il est recommandé d'utiliser des variables d'environnement comme app.config.from_envvar() pour contrôler les paramètres de débogage en fonction de l'environnement de déploiement. Pour les déploiements en production, utilisez un serveur WSGI de qualité production tel que Gunicorn ou Waitress plutôt que le serveur de développement intégré de Flask (app.run()).

OWASP :

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

python_ftp_rule-ftplib

Résumé :

Transmission en clair d'informations sensibles

Gravité : Moyenne

CWE : CWE-319

Description :

L'application utilise le module ftplib pour les opérations du protocole de transfert de fichiers. FTP transmet toutes les données, y compris les identifiants et le contenu des fichiers, en clair sans chiffrement, permettant aux attaquants d'intercepter des informations sensibles par le biais d'écoute réseau ou d'attaques de type homme du milieu.

Remédiation :

Envisagez de migrer vers des protocoles de transfert de fichiers sécurisés qui offrent un chiffrement. Il est recommandé d'utiliser SFTP via la bibliothèque paramiko avec le module scp (par exemple, paramiko.SSHClient() avec scp.SCPClient()) pour des transferts de fichiers sécurisés basés sur SSH. Pour la compatibilité avec les serveurs FTP qui prennent en charge le chiffrement, utilisez ftplib.FTP_TLS() à la place, bien que SFTP soit préféré. Assurez-vous d'une vérification appropriée des clés hôtes lors de l'utilisation d'approches basées sur SSH afin de prévenir les attaques MITM.

OWASP :

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

python_requests_rule-request-without-timeout

Résumé :

Allocation de ressources sans limites ni restriction

Sévérité : Moyenne

CWE : CWE-770

Description :

L'application appelle les méthodes du module requests (get(), post(), put(), etc.) sans spécifier de paramètre timeout. Cela permet aux connexions réseau de rester bloquées indéfiniment, entraînant une consommation incontrôlée des ressources et une exhaustion des sockets, ce qui provoque effectivement une condition de Déni de Service (DoS).

Remédiation :

Envisagez d'ajouter un paramètre timeout à tous les appels de méthode requests pour éviter le blocage indéfini. La valeur du timeout doit être fixée en fonction des conditions réseau attendues et des exigences de l'application, généralement entre 5 et 30 secondes. Par exemple, utilisez requests.get('https://example.com', timeout=10) pour définir un timeout de 10 secondes. Il est recommandé d'appliquer des timeouts de manière cohérente à toutes les opérations HTTP, y compris get(), post(), put(), delete(), patch(), head(), et options(). Évitez de définir timeout=None ou timeout=0 car cela désactive la protection par timeout.

OWASP :

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

python_snmp_rule-insecure-snmp-version

Résumé :

Transmission en clair d'informations sensibles

Gravité : Moyenne

CWE : CWE-319

Description :

L'API CommunityData() avec mpModel=0 (SNMPv1) ou mpModel=1 (SNMPv2c) transmet des identifiants et des données en clair sans cryptage ni authentification forte. Cela expose des informations sensibles sur les dispositifs et des chaînes communautaires à l'écoute sur le réseau et aux attaques de type homme du milieu.

Remédiation :

Envisagez de migrer vers SNMPv3 avec UsmUserData() au lieu de CommunityData(). Il est recommandé d'utiliser une authentification basée sur SHA (authProtocol=usmHMACSHAAuthProtocol) avec une clé d'authentification forte (authKey), et un cryptage AES (privProtocol=usmAesCfb128Protocol) avec une clé privée forte (privKey). Par exemple : UsmUserData('username', 'authKey', 'privKey', authProtocol=usmHMACSHAAuthProtocol, privProtocol=usmAesCfb128Protocol).

OWASP :

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

python_snmp_rule-snmp-weak-cryptography

Résumé :

Transmission en clair d'informations sensibles

Gravité : Moyenne

CWE : CWE-319

Description :

L'API UsmUserData() est configurée sans authentification ni cryptage. L'utilisation de usmNoAuthProtocol, usmNoPrivProtocol, d'une clé d'authentification manquante/nulle ou d'une clé de confidentialité manquante/nulle expose les communications SNMP à l'écoute clandestine et à la falsification. Sans authentification, les attaquants peuvent usurper l'identité des appareils ; sans cryptage, les données sensibles des appareils et les informations d'identification sont transmises en clair.

Remédiation :

Envisagez d'activer à la fois l'authentification et la confidentialité dans UsmUserData(). Il est recommandé de définir authProtocol=usmHMACSHAAuthProtocol avec une clé d'authentification forte (authKey) pour l'authentification des messages, et privProtocol=usmAesCfb128Protocol avec une clé de confidentialité forte (privKey) pour le cryptage. Évitez usmNoAuthProtocol et usmNoPrivProtocol. Toujours fournir des valeurs non nulles pour authKey et privKey afin d'assurer des communications SNMPv3 sécurisées.

OWASP :

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

python_ssh_rule-ssh-nohost-key-verification

Résumé :

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

Sévérité : Moyenne

CWE : CWE-322

Description :

L'application utilise SSHClient.set_missing_host_key_policy() avec AutoAddPolicy ou WarningPolicy, ce qui désactive la vérification de la clé de l'hôte. Cela permet des connexions à des hôtes non fiables et facilite les attaques de type homme du milieu, car le client ne peut pas valider l'identité du serveur via l'authentification par clé d'hôte.

Remédiation :

Envisagez de supprimer complètement l'appel à set_missing_host_key_policy() pour utiliser la RejectPolicy par défaut de paramiko, qui rejette les connexions à des hôtes inconnus. Il est recommandé de charger les clés d'hôtes connues en utilisant ssh.load_system_host_keys() ou ssh.load_host_keys('/path/to/known_hosts') avant de se connecter. Pour les environnements de production, maintenez un fichier known_hosts avec des empreintes de serveur vérifiées. Si vous devez vous connecter à de nouveaux hôtes, vérifiez manuellement l'empreinte de la clé d'hôte par des moyens indirects avant de l'ajouter à votre fichier known_hosts. Évitez d'utiliser AutoAddPolicy ou WarningPolicy car ils acceptent toute clé d'hôte sans vérification.

OWASP :

  • A5:2017-Contrôle d'accès brisé
  • A07:2021-Failles d'identification et d'authentification

python_ssl_rule-req-no-certvalid

Résumé :

Validation de certificat incorrecte

Gravité : Moyenne

CWE : CWE-295

Description :

L'application utilise requests.get(), requests.post(), ou d'autres fonctions du module requests avec l'argument verify=False, ce qui désactive la validation des certificats SSL/TLS. Cela empêche la bibliothèque requests de vérifier l'identité du serveur, rendant la connexion vulnérable aux attaques de type homme du milieu. Un adversaire positionné entre l'application et le serveur cible pourrait intercepter des données sensibles, injecter des réponses malveillantes ou usurper des serveurs légitimes sans détection.

Remédiation :

Envisagez de supprimer complètement l'argument verify=False de tous les appels de fonction requests, car la vérification des certificats est activée par défaut dans la bibliothèque requests. Si une vérification explicite est nécessaire, définissez verify=True ou fournissez un chemin vers un fichier de bundle CA personnalisé en utilisant verify='/path/to/ca-bundle.crt'. Pour les environnements de développement avec des certificats auto-signés, il est recommandé d'ajouter le certificat au magasin de confiance du système plutôt que de désactiver la vérification globalement. Lorsque vous travaillez avec des proxys d'entreprise ou des services internes, envisagez d'utiliser la variable d'environnement REQUESTS_CA_BUNDLE pour spécifier les chemins de certificat au niveau du système. Associez toujours la vérification des certificats à des valeurs de délai d'attente appropriées (par exemple, timeout=10) pour éviter les connexions suspendues. Pour plus d'informations, consultez https://requests.readthedocs.io/en/latest/user/advanced/#ssl-cert-verification

OWASP :

  • A2:2017-Autorisation brisée
  • A07:2021-Échecs d'identification et d'authentification

python_ssl_rule-ssl-no-version

Résumé :

Force de chiffrement inadéquate

Gravité : Moyenne

CWE : CWE-326

Description :

L'application appelle ssl.wrap_socket() sans spécifier de version de protocole TLS, ce qui peut entraîner la négociation de versions de protocole faibles ou obsolètes. De plus, ssl.wrap_socket() a été déprécié depuis Python 3.7 et ne dispose pas des fonctionnalités de sécurité et des paramètres par défaut appropriés fournis par l'API SSLContext moderne. L'utilisation de cette fonction dépréciée sans configuration explicite du protocole laisse l'application vulnérable aux attaques par rétrogradation de protocole et peut permettre par inadvertance l'utilisation de versions SSL/TLS non sécurisées.

Remédiation :

Envisagez de migrer de ssl.wrap_socket() à l'API SSLContext en créant un contexte avec ssl.SSLContext(protocol=ssl.PROTOCOL_TLS_CLIENT) pour les connexions client ou ssl.SSLContext(protocol=ssl.PROTOCOL_TLS_SERVER) pour les connexions serveur. Les constantes PROTOCOL_TLS_CLIENT et PROTOCOL_TLS_SERVER sélectionnent automatiquement la version TLS la plus élevée disponible (1.3 pour Python 3.7+, 1.2 en tant que secours) tout en empêchant la rétrogradation vers des protocoles vulnérables. Après avoir créé le contexte, utilisez context.wrap_socket(sock, server_hostname="example.org") au lieu de la fonction dépréciée. Pour les connexions client, spécifiez toujours le paramètre server_hostname pour activer l'indication de nom de serveur (SNI) et assurer une validation appropriée des certificats. L'approche SSLContext offre un meilleur contrôle sur les suites de chiffrement, les options de vérification des certificats et les versions de protocole. Pour plus d'informations, consultez https://docs.python.org/3/library/ssl.html#ssl.SSLContext

OWASP :

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

python_ssl_rule-ssl-with-bad-version

Résumé :

Force de chiffrement inadéquate

Gravité : Moyenne

CWE : CWE-326

Description :

L'application spécifie explicitement des versions de protocole SSL/TLS vulnérables telles que ssl.PROTOCOL_SSLv2, ssl.PROTOCOL_SSLv3, ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_TLSv1_1, ou leurs équivalents pyOpenSSL comme pyOpenSSL.SSL.SSLv3_METHOD et pyOpenSSL.SSL.TLSv1_METHOD. Ces protocoles présentent des faiblesses cryptographiques connues, y compris la vulnérabilité à POODLE, BEAST, et d'autres attaques qui permettent aux adversaires de déchiffrer le trafic ou de rétrograder la sécurité de la connexion. SSLv2 et SSLv3 sont complètement obsolètes, tandis que TLS 1.0 et 1.1 ont été dépréciés par les principaux navigateurs et organisations de normalisation en 2020 en raison d'une force cryptographique insuffisante face aux techniques d'attaque modernes.

Remédiation :

Envisagez de remplacer les constantes de protocole vulnérables par ssl.PROTOCOL_TLS_CLIENT pour les applications client ou ssl.PROTOCOL_TLS_SERVER pour les applications serveur lors de la création d'un SSLContext. Ces constantes négocient automatiquement la plus haute version TLS disponible (1.3 sur Python 3.7+, avec rétrogradation à 1.2) tout en empêchant explicitement la rétrogradation vers des protocoles vulnérables. Si vous utilisez pyOpenSSL, il est recommandé de migrer vers le module ssl de la bibliothèque standard ou le paquet pyca/cryptography, car pyOpenSSL a été déprécié par l'Autorité de Cryptographie Python. Pour les applications nécessitant une compatibilité descendante avec TLS 1.2, utilisez ssl.PROTOCOL_TLS et configurez context.minimum_version = ssl.TLSVersion.TLSv1_2 pour définir un niveau minimum explicite. Évitez d'utiliser PROTOCOL_SSLv23 malgré son nom trompeur suggérant de la flexibilité, car il nécessite une configuration supplémentaire pour éviter la rétrogradation du protocole. Pour plus d'informations, consultez https://docs.python.org/3/library/ssl.html#ssl-security et https://cryptography.io/en/latest/

OWASP :

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

python_ssl_rule-unverified-context

Résumé :

Validation de certificat incorrecte

Gravité : Moyenne

CWE : CWE-295

Description :

L'application crée un contexte SSL en utilisant ssl._create_unverified_context(), ce qui désactive complètement la validation des certificats du serveur. Cette fonction API privée contourne toutes les vérifications de validation des certificats, y compris la validation des noms d'hôte, la vérification de la chaîne de confiance de l'autorité de certification et les vérifications d'expiration. L'utilisation d'un contexte non vérifié rend l'application vulnérable aux attaques de type homme du milieu, où un adversaire peut intercepter le trafic crypté, usurper l'identité de serveurs légitimes et voler ou manipuler des données sensibles sans être détecté.

Remédiation :

Envisagez de remplacer ssl._create_unverified_context() par ssl.create_default_context(), qui fournit des valeurs par défaut sécurisées, y compris la vérification des certificats, la vérification des noms d'hôte et la sélection du protocole TLS moderne. Le contexte par défaut charge automatiquement les certificats CA du système et impose une validation appropriée. Pour les connexions client, utilisez ssl.create_default_context(purpose=ssl.Purpose.SERVER_AUTH) et pour les connexions serveur, utilisez ssl.Purpose.CLIENT_AUTH. Si vous travaillez avec des certificats auto-signés dans des environnements de développement, il est recommandé d'ajouter le certificat au contexte en utilisant context.load_verify_locations('cert.pem') plutôt que de désactiver complètement la vérification. Pour les environnements d'entreprise avec des certificats CA personnalisés, configurez les variables d'environnement SSL_CERT_FILE ou SSL_CERT_DIR pour spécifier les emplacements de certificats de confiance. N'utilisez jamais la fonction _create_unverified_context() avec un préfixe souligné dans le code de production, car c'est une API interne destinée uniquement aux fins de débogage. Pour plus d'informations, consultez https://docs.python.org/3/library/ssl.html#ssl.create_default_context

OWASP :

  • A2:2017-Authentification Brisée
  • A07:2021-Échecs d'Identification et d'Authentification

python_telnet_rule-import-telnib

Résumé :

Transmission en clair d'informations sensibles

Gravité : Moyenne

CWE : CWE-319

Description :

L'application importe le module telnetlib, qui transmet toutes les données, y compris les informations d'identification et les informations sensibles, en clair sur le réseau. Cela expose les communications à l'écoute clandestine, l'interception et les attaques de type homme du milieu.

Remédiation :

Envisagez de remplacer telnetlib par la bibliothèque paramiko pour utiliser SSH pour un accès à distance chiffré. SSH fournit un chiffrement fort tant pour l'authentification que pour la transmission de données. Utilisez paramiko.SSHClient() avec load_system_host_keys() ou load_host_keys() pour établir des connexions vérifiées. Pour l'exécution de commandes, utilisez ssh.exec_command() au lieu des méthodes read_until() et write() de telnet. Si le protocole telnet est absolument nécessaire pour la compatibilité avec des systèmes légataires, envisagez de le tunneler via un VPN chiffré ou le port forwarding SSH plutôt que de transmettre en clair sur le réseau.

OWASP :

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

python_tmpdir_rule-hardcodedtmp

Résumé :

Fichier temporaire non sécurisé

Sévérité : Moyenne

CWE : CWE-377

Description :

L'application crée des fichiers directement dans des répertoires temporaires partagés du système (/tmp ou /var/tmp) en utilisant des opérations de fichier standard au lieu des fonctions sécurisées du module Python tempfile. Cela permet aux attaquants d'exploiter des conditions de course de type time-of-check à time-of-use (TOCTOU) en créant des liens symboliques vers des fichiers sensibles, ce qui peut conduire à une création de fichiers non autorisée, à un écrasement ou à une divulgation d'informations.

Remédiation :

Envisagez d'utiliser le module tempfile de Python pour des opérations de fichiers temporaires sécurisées. Les fonctions recommandées incluent tempfile.TemporaryFile() pour un nettoyage automatique, tempfile.NamedTemporaryFile() lorsqu'un nom de système de fichiers est nécessaire, ou tempfile.mkstemp() pour un contrôle de bas niveau avec création de descripteurs de fichiers sécurisés. Ces fonctions utilisent des noms générés de manière sécurisée et des permissions de fichiers appropriées pour prévenir les conditions de course. Utilisez des gestionnaires de contexte (with) pour garantir un nettoyage automatique lorsque cela est possible.

OWASP :

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

python_tmpdir_rule-mktemp-q

Résumé :

Fichier temporaire non sécurisé

Gravité : Moyenne

CWE : CWE-377

Description :

L'application utilise tempfile.mktemp(), qui est obsolète et vulnérable aux conditions de concurrence. Cette fonction génère uniquement un nom de fichier sans créer le fichier de manière atomique, permettant aux attaquants de créer des liens symboliques ou des fichiers à ce chemin entre la génération du nom et la création du fichier, ce qui peut entraîner un accès non autorisé, un écrasement de fichier ou une divulgation d'informations.

Remédiation :

Remplacez tempfile.mktemp() par des alternatives sécurisées qui créent des fichiers de manière atomique. Envisagez d'utiliser tempfile.NamedTemporaryFile() pour des opérations de haut niveau avec nettoyage automatique, ou tempfile.mkstemp() qui retourne à la fois un descripteur de fichier et un nom de fichier créés de manière sécurisée. Si vous avez besoin d'un répertoire temporaire, utilisez tempfile.TemporaryDirectory() ou tempfile.mkdtemp(). Utilisez toujours des gestionnaires de contexte (instructions with) lorsque cela est possible pour assurer un nettoyage approprié et une gestion des ressources.

OWASP :

  • A3:2017-Divulgation de données sensibles
  • A01:2021-Contrôle d'accès rompu

python_urlopen_rule-urllib-urlopen

Résumé :

Autorisation incorrecte dans le gestionnaire de schéma URL personnalisé

Gravité : Moyenne

CWE : CWE-939

Description :

L'application passe une valeur non littérale à urllib.urlopen(), urllib.urlretrieve(), ou aux méthodes de URLopener. Ces API prennent en charge le schéma file://, ce qui permet à un attaquant qui contrôle l'URL de lire des fichiers arbitraires depuis le système de fichiers, entraînant une divulgation d'informations sensibles.

Remédiation :

Envisagez de migrer vers la bibliothèque requests, qui ne prend pas en charge le schéma file:// par défaut et offre une meilleure sécurité. Si urllib doit être utilisé, validez que les URL n'utilisent pas le schéma file:// en vérifiant le préfixe de l'URL avant de le transmettre aux méthodes d'urllib. Il est recommandé de maintenir une liste blanche des schémas d'URL autorisés (par exemple, uniquement https://) et de rejeter toute URL qui ne correspond pas. Alternativement, codez en dur toutes les URL pour éviter les entrées contrôlées par l'utilisateur.

OWASP :

  • A1:2017-Injection
  • A03:2021-Injection

python_xml_rule-celement

Résumé :

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

Gravité : Moyenne

CWE : CWE-611

Description :

L'application utilise xml.etree.cElementTree.parse(), xml.etree.cElementTree.fromstring(), xml.etree.cElementTree.iterparse(), ou xml.etree.cElementTree.XMLParser() pour traiter des données XML sans restrictions appropriées sur les entités. Les parseurs XML natifs de Python sont vulnérables aux attaques XML External Entity (XXE) dans les anciennes versions de Python et aux attaques d'expansion d'entité dans toutes les versions. Le module cElementTree est particulièrement préoccupant car il souffre d'attaques des milliards de rires (expansion d'entité exponentielle) et d'expansion d'entité à croissance quadratique, ce qui peut permettre aux attaquants de provoquer des attaques par déni de service en soumettant des documents XML malveillants qui consomment une quantité excessive de CPU et de mémoire lors du parsing. Ces vulnérabilités affectent les applications traitant des XML non fiables provenant de sources externes telles que des requêtes API, des téléchargements de fichiers ou des fichiers de configuration.

Remédiation :

Envisagez de migrer vers la bibliothèque defusedxml, qui fournit des remplacements prêts à l'emploi pour les parseurs XML standard de Python avec des valeurs par défaut sécurisées qui empêchent les attaques XXE et d'expansion d'entité. Le module defusedxml.ElementTree peut remplacer xml.etree.cElementTree avec des modifications de code minimales. Par exemple, remplacez from xml.etree.cElementTree import parse par from defusedxml.ElementTree import parse pour utiliser le parseur renforcé. La bibliothèque defusedxml désactive le traitement des entités externes, le traitement DTD et l'expansion d'entité par défaut, protégeant ainsi contre les injections XXE et les attaques DoS. Pour les applications qui ne peuvent pas utiliser defusedxml, vous pouvez configurer manuellement le XMLParser pour désactiver les fonctionnalités dangereuses, mais cette approche est plus sujette aux erreurs et n'est pas recommandée pour les applications critiques en matière de sécurité. Plus d'informations sont disponibles sur https://docs.python.org/3/library/xml.html#xml-vulnerabilities et https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#python

OWASP :

  • A4:2017-Entités externes XML (XXE)
  • A03:2021-Injection

python_xml_rule-element

Résumé :

Restriction inadéquate de la référence d'entité externe XML

Sévérité : Moyenne

CWE : CWE-611

Description :

L'application utilise xml.etree.ElementTree.parse(), xml.etree.ElementTree.fromstring(), xml.etree.ElementTree.iterparse(), ou xml.etree.ElementTree.XMLParser() pour traiter les données XML sans restrictions appropriées sur les entités. Les parseurs XML intégrés de Python sont vulnérables aux attaques par entités externes XML (XXE) dans les versions antérieures de Python et aux attaques par expansion d'entité dans toutes les versions. Le module ElementTree souffre des attaques des "milliards de rires" (expansion d'entité exponentielle) et d'expansion d'entité quadratique, permettant aux attaquants de provoquer une déni de service en soumettant des documents XML construits qui consomment une CPU et de la mémoire excessives lors du parsing. Bien que Python 3.7.1+ désactive par défaut les entités externes dans ElementTree, les attaques par expansion d'entité restent exploitables. Ces vulnérabilités affectent les applications traitant des XML non fiables provenant de sources externes telles que les requêtes API, les téléversements de fichiers ou les fichiers de configuration.

Remédiation :

Envisagez de migrer vers la bibliothèque defusedxml qui fournit des remplacements compatibles pour les parseurs XML standard de Python avec des paramètres par défaut sécurisés qui empêchent les attaques XXE et d'expansion d'entité. Le module defusedxml.ElementTree peut remplacer xml.etree.ElementTree avec des modifications minimales du code. Par exemple, remplacez from xml.etree.ElementTree import parse par from defusedxml.ElementTree import parse pour utiliser le parseur hardened. La bibliothèque defusedxml désactive par défaut le traitement des entités externes, le traitement DTD et l'expansion des entités, se protégeant ainsi contre les injections XXE et les attaques DoS. Pour les applications qui ne peuvent pas utiliser defusedxml, vous pouvez configurer manuellement le XMLParser pour désactiver les fonctionnalités dangereuses, mais cette approche est plus sujette aux erreurs et n'est pas recommandée pour les applications critiques en matière de sécurité. Plus d'informations sont disponibles sur https://docs.python.org/3/library/xml.html#xml-vulnerabilities et https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#python

OWASP :

  • A4:2017-Entités externes XML (XXE)
  • A03:2021-Injection

python_xml_rule-etree

Résumé :

Restriction inadéquate des références d'entités externes XML

Sévérité : Moyenne

CWE : CWE-611

Description :

L'application utilise lxml.etree.parse(), lxml.etree.fromstring(), lxml.etree.RestrictedElement(), lxml.etree.GlobalParserTLS(), lxml.etree.getDefaultParser(), ou lxml.etree.check_docinfo() pour traiter des données XML potentiellement sans restrictions d'entités appropriées. La bibliothèque lxml est plus puissante que les parseurs XML de la bibliothèque standard de Python, mais nécessite une configuration explicite pour désactiver les fonctionnalités dangereuses. Par défaut, les parseurs lxml peuvent permettre la résolution d'entités externes, le traitement DTD et l'expansion d'entités, ce qui peut conduire à des attaques par entités externes XML (XXE), des attaques par contournement de requêtes côté serveur (SSRF), la divulgation arbitraire de fichiers et des attaques par déni de service via des milliards de rires ou des explosions quadratiques. Lors de l'utilisation des parseurs par défaut de lxml avec des entrées XML non fiables provenant de sources telles que des requêtes API, des téléchargements de fichiers ou des flux externes, les applications deviennent vulnérables à ces vecteurs d'attaque à moins que les parseurs ne soient configurés explicitement avec des paramètres sécurisés.

Remédiation :

Envisagez d'utiliser la bibliothèque defusedxml qui fournit des wrappers sécurisés pour les parseurs lxml, ou configurez manuellement les parseurs lxml avec des paramètres sécurisés. Si vous utilisez lxml directement, créez un parseur avec lxml.etree.XMLParser(resolve_entities=False, no_network=True, dtd_validation=False, load_dtd=False) et passez-le aux fonctions de parsing. Le paramètre resolve_entities=False est critique car il empêche les attaques par expansion d'entités externes, tandis que no_network=True prévient les attaques SSRF. Pour les applications pouvant changer de bibliothèques, defusedxml fournit des remplacements compatibilisés qui appliquent automatiquement ces valeurs par défaut sécurisées. Soyez conscient que la configuration de sécurité de lxml doit être appliquée à chaque instance de parseur, car les parseurs par défaut ne sont pas sécurisés. De plus, évitez d'utiliser lxml.etree.RestrictedElement car il ne fournit pas de frontières de sécurité adéquates pour des XML non fiables. Plus d'informations sont disponibles sur https://lxml.de/FAQ.html#how-do-i-use-lxml-safely-as-a-web-service-endpoint et https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#python

OWASP :

  • A4:2017-Entités Externes XML (XXE)
  • A03:2021-Injection

python_xml_rule-expatbuilder

Résumé :

Restriction inadéquate de la référence d'entité externe XML

Sévérité : Moyenne

CWE : CWE-611

Description :

L'application utilise xml.dom.expatbuilder.parse() ou xml.dom.expatbuilder.parseString() pour traiter des données XML, qui utilise en interne le package xml.dom.minidom sans restrictions appropriées sur les entités. Les analyseurs XML DOM intégrés de Python sont vulnérables aux attaques par entités externes XML (XXE) dans les anciennes versions de Python et aux attaques par expansion d'entités dans toutes les versions. Le module expatbuilder, qui construit des arbres DOM en utilisant l'analyseur Expat, souffre d'attaques "billion laughs" (expansion d'entités exponentielle) et de vulnérabilités d'expansion d'entités à explosion quadratique. Ces attaques permettent aux adversaires de provoquer des conditions de déni de service sévères en soumettant des documents XML malveillants avec des définitions d'entités profondément imbriquées ou largement répétées, ce qui consomme une CPU et une mémoire excessives lors de l'analyse. Les applications utilisant expatbuilder pour traiter des XML non fiables provenant de sources telles que des requêtes API, des téléchargements de fichiers ou des fichiers de configuration sont particulièrement à risque.

Remédiation :

Envisagez de migrer vers la bibliothèque defusedxml, qui fournit des alternatives sécurisées à la fonctionnalité d'analyse DOM de Python, avec une protection contre les attaques XXE et les expansions d'entités. Bien que defusedxml ne fournisse pas de remplacement direct pour expatbuilder, vous pouvez utiliser defusedxml.minidom.parseString() comme une alternative sécurisée dans la plupart des cas d'utilisation de l'analyse DOM. La bibliothèque defusedxml désactive par défaut le traitement des entités externes, le traitement DTD et l'expansion d'entités, protégeant ainsi contre les injections XXE et les attaques DoS. Si vous avez besoin de la fonctionnalité spécifique d'expatbuilder et ne pouvez pas utiliser defusedxml, sachez que le renforcement manuel d'expatbuilder est complexe et sujet à erreurs. Pour la plupart des applications, il est recommandé de passer à defusedxml ou de reconsidérer si l'analyse DOM est nécessaire (ElementTree est souvent plus efficace). Plus d'informations sont disponibles à https://docs.python.org/3/library/xml.html#xml-vulnerabilities et https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#python

OWASP :

  • A4:2017-Entités externes XML (XXE)
  • A03:2021-Injection

python_xml_rule-expatreader

Résumé :

Restriction inadéquate de la référence d'entité externe XML

Gravité : Moyenne

CWE : CWE-611

Description :

L'application utilise xml.dom.expatreader.parse(), xml.dom.expatreader.parseString(), ou xml.dom.expatreader.create_parser() pour traiter des données XML, utilisant le parser Expat basé sur SAX sans restrictions appropriées des entités. Les parseurs XML SAX intégrés de Python sont vulnérables aux attaques de type XML External Entity (XXE) dans les anciennes versions de Python et aux attaques d'expansion d'entités dans toutes les versions. Le module expatreader, qui fournit une interface SAX au parser Expat, souffre d'attaques de type "billion laughs" (expansion exponentielle d'entités) et de vulnérabilités liées à l'expansion quadratique d'entités. Ces attaques permettent aux adversaires de provoquer des conditions de déni de service graves en soumettant des documents XML falsifiés avec des définitions d'entités profondément imbriquées ou largement répétées, consommant une quantité excessive de CPU et de mémoire lors du traitement par événements. Les applications utilisant expatreader pour traiter des XML non fiables provenant de sources telles que les requêtes API, les flux en streaming ou les téléchargements de fichiers sont particulièrement vulnérables.

Remédiation :

Envisagez d'utiliser la bibliothèque defusedxml, qui fournit des alternatives de parsing SAX sécurisées pour prévenir les attaques XXE et d'expansion d'entités. Le module defusedxml.sax offre des remplacements immédiats pour les fonctions expatreader avec des paramètres par défaut renforcés. Par exemple, utilisez defusedxml.sax.parse() au lieu de xml.dom.expatreader.parse() pour tirer parti de la configuration sécurisée du parseur automatiquement. La bibliothèque defusedxml désactive le traitement des entités externes, le traitement DTD et l'expansion d'entités par défaut, protégeant contre les injections XXE et les attaques DoS tout en maintenant le modèle de parsing basé sur des événements de SAX pour un traitement efficace en mémoire de grands documents XML. Si vous ne pouvez pas utiliser defusedxml, vous pouvez configurer manuellement les parseurs SAX en définissant des caractéristiques sur l'instance du parseur, mais cette approche est complexe et sujette à erreurs par rapport à l'utilisation des paramètres par défaut sécurisés de defusedxml. Plus d'informations sont disponibles sur https://docs.python.org/3/library/xml.html#xml-vulnerabilities et https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#python

OWASP :

  • A4:2017-Entités externes XML (XXE)
  • A03:2021-Injection

python_xml_rule-minidom

Résumé :

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

Gravité : Moyenne

CWE : CWE-611

Description :

L'application utilise xml.dom.minidom.parse() ou xml.dom.minidom.parseString() pour traiter des données XML et construire un arbre de modèle d'objet de document sans restrictions appropriées des entités. Le parser minidom intégré de Python est vulnérable aux attaques d'entités externes XML (XXE) dans les anciennes versions de Python et aux attaques d'expansion d'entités dans toutes les versions. Le module xml.dom.minidom fournit une implémentation DOM légère qui souffre d'attaques de milliard de rires (expansion d'entités exponentielle) et de vulnérabilités d'expansion d'entités de blowup quadratique, permettant aux attaquants de causer de graves conditions de déni de service en soumettant des documents XML façonnés avec des définitions d'entités profondément imbriquées ou largement répétées. Contrairement aux parseurs de flux, minidom charge l'ensemble du document XML en mémoire sous forme d'arbre DOM, ce qui le rend particulièrement vulnérable aux attaques d'épuisement de mémoire. Les applications utilisant minidom pour traiter des XML non fiables provenant de sources comme les requêtes API, les téléchargements de fichiers ou les fichiers de configuration sont à un risque significatif.

Remédiation :

Envisagez de migrer vers la bibliothèque defusedxml qui fournit des alternatives de parsing DOM sécurisées avec protection contre les attaques XXE et d'expansion d'entités. Utilisez defusedxml.minidom.parse() ou defusedxml.minidom.parseString() comme remplacements intégrés pour les fonctions minidom standard. La bibliothèque defusedxml applique des paramètres par défaut sécurisés qui désactivent le traitement des entités externes, le traitement DTD et l'expansion d'entités, protégeant contre les injections XXE et les attaques DoS tout en maintenant l'interface DOM. Pour les applications avec de grands documents XML, envisagez si le parsing DOM est nécessaire, car des parseurs de flux comme SAX ou des parseurs itératifs comme iterparse d'ElementTree sont plus efficaces en mémoire et peuvent également être sécurisés avec defusedxml. Soyez conscient que l'arbre DOM en mémoire de minidom peut consommer une mémoire significative même sans expansion d'entités malveillantes, le rendant inadapté au traitement de grands documents XML ou de XML non fiables, quelle que soit la sécurisation. Plus d'informations sont disponibles sur https://docs.python.org/3/library/xml.html#xml-vulnerabilities et https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#python

OWASP :

  • A4:2017-Entités Externes XML (XXE)
  • A03:2021-Injection

python_xml_rule-pulldom

Résumé :

Restriction inappropriée de la référence d'entité externe XML

Sévérité : Moyenne

CWE : CWE-611

Description :

L'application utilise xml.dom.pulldom.parse() ou xml.dom.pulldom.parseString() pour traiter des données XML en utilisant un modèle de parsing hybride par tirage/événement sans restrictions d'entités appropriées. Le parseur pulldom intégré de Python est vulnérable aux attaques d'entité externe XML (XXE) dans les anciennes versions de Python et aux attaques d'expansion d'entité dans toutes les versions. Le module xml.dom.pulldom fournit une interface orientée événement qui peut construire des sous-arbres DOM à la demande, mais il souffre des attaques de milliard de rires (expansion d'entité exponentielle) et des vulnérabilités d'expansion d'entité avec explosion quadratique. Ces attaques permettent aux adversaires de provoquer des conditions graves de déni de service en soumettant des documents XML conçus avec des définitions d'entités profondément imbriquées ou largement répétées. Bien que l'approche de parsing incrémentiel de pulldom puisse être plus efficace en mémoire que le parsing complet de DOM, elle reste vulnérable aux attaques d'expansion d'entité qui peuvent épuiser les ressources CPU et mémoire. Les applications utilisant pulldom pour traiter des XML non fiables provenant de sources telles que des requêtes API, des flux de données ou des téléchargements de fichiers sont à risque.

Remédiation :

Envisagez de migrer vers la bibliothèque defusedxml qui fournit des alternatives sécurisées à pulldom avec protection contre les attaques XXE et d'expansion d'entité. Bien que defusedxml ne propose pas de remplacement direct de pulldom, vous pouvez utiliser defusedxml.ElementTree.iterparse() pour une fonctionnalité de parsing incrémentiel similaire avec des valeurs par défaut sécurisées. L'approche iterparse fournit un parsing orienté événement comme pulldom tout en désactivant automatiquement le traitement des entités externes, le traitement DTD et l'expansion d'entité. Pour les applications qui nécessitent spécifiquement la capacité de construction de sous-arbres DOM de pulldom, envisagez si l'API complète d'ElementTree avec protection defusedxml répondrait à vos besoins, car elle offre une fonctionnalité similaire avec une meilleure sécurité. Si vous devez utiliser pulldom, sachez que le renforcement manuel est complexe et sujet à des erreurs. L'iterparse de la bibliothèque defusedxml est généralement un meilleur choix pour traiter des documents XML volumineux ou non fiables de manière incrémentielle. Plus d'informations sont disponibles sur https://docs.python.org/3/library/xml.html#xml-vulnerabilities et https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#python

OWASP :

  • A4:2017-Entités externes XML (XXE)
  • A03:2021-Injection

python_xml_rule-sax

Résumé :

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

Gravité : Moyenne

CWE : CWE-611

Description :

L'application utilise xml.sax.parse(), xml.sax.parseString(), ou xml.sax.make_parser() pour traiter des données XML en utilisant SAX (API Simple pour XML) dont le traitement est basé sur des événements, sans restrictions adéquates sur les entités. Les parseurs SAX intégrés de Python sont vulnérables aux attaques par entité externe XML (XXE) dans les anciennes versions de Python et aux attaques par expansion d'entité dans toutes les versions. Le module xml.sax fournit une interface de streaming, axée sur les événements pour le traitement XML qui suffre des attaques "billion laughs" (expansion exponentielle des entités) et des vulnérabilités d'expansion d'entité à explosion quadratique. Ces attaques permettent aux adversaires de provoquer des conditions de déni de service grave en soumettant des documents XML créés avec des définitions d'entités profondément imbriquées ou largement répétées qui consomment une quantité excessive de CPU et de mémoire lors du traitement des événements. Bien que la parsing SAX soit efficace en mémoire pour les grands documents, elle reste vulnérable aux attaques basées sur des entités qui peuvent épuiser les ressources système. Les applications utilisant xml.sax pour traiter des XML non fiables provenant de sources telles que des requêtes API, des flux en streaming, ou des téléchargements de fichiers sont à risque considérable.

Remédiation :

Envisagez de migrer vers la bibliothèque defusedxml qui offre des fonctions de parsing SAX sécurisées avec une protection contre les attaques XXE et d'expansion d'entité. Utilisez defusedxml.sax.parse(), defusedxml.sax.parseString(), ou defusedxml.sax.make_parser() comme remplacements directs des fonctions standard xml.sax. La bibliothèque defusedxml configure automatiquement les parseurs SAX avec des paramètres par défaut sécurisés qui désactivent le traitement des entités externes, le traitement des DTD et l'expansion d'entité, protégeant à la fois contre les injections XXE et les attaques DoS tout en maintenant le modèle de parsing basé sur des événements de SAX. Cela vous permet de continuer à utiliser l'approche de streaming efficace en mémoire de SAX pour de grands documents XML sans risques de sécurité. Si vous ne pouvez pas utiliser defusedxml, vous pouvez configurer manuellement les fonctionnalités du parseur SAX en appelant parser.setFeature() pour désactiver les capacités dangereuses, mais cette approche est complexe et sujette à erreur par rapport à l'utilisation des paramètres par défaut renforcés de defusedxml. Plus d'informations sont disponibles sur https://docs.python.org/3/library/xml.html#xml-vulnerabilities et https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#python

OWASP :

  • A4:2017-Entités Externes XML (XXE)
  • A03:2021-Injection

python_bind-all-interfaces_rule-general-bindall-interfaces

Résumé :

Liaison à une adresse IP non restreinte

Sévérité : Faible

CWE : CWE-1327

Description :

L'application appelle socket.bind() avec "0.0.0.0", "::" ou une chaîne vide, ce qui lie le socket à toutes les interfaces réseau. Cela est dangereux car cela expose le service au trafic sur toutes les interfaces réseau, y compris celles qui ne sont pas intentionnelles ou sécurisées, et qui peuvent ne pas être correctement documentées, protégées par un pare-feu, ou destinées à un accès externe.

Remédiation :

Liez à une interface réseau spécifique au lieu de toutes les interfaces. Envisagez d'utiliser "127.0.0.1" ou "localhost" pour les services uniquement locaux, ou liez à une adresse d'interface interne spécifique pour un accès réseau contrôlé. Il est recommandé d'obtenir l'adresse IP à partir d'une variable d'environnement (par exemple, os.getenv("BIND_ADDRESS", "127.0.0.1")) ou d'un fichier de configuration pour permettre un déploiement flexible tout en maintenant la sécurité.

OWASP :

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

python_prompt_injection

Résumé :

Injection de prompt dans les appels d'API LLM

Gravité : Faible

CWE : CWE-1427

Description :

Les entrées contrôlées par l'utilisateur sont transmises directement aux API LLM (chat.completions.create(), generate_content()) d'OpenAI, Gemini ou Azure AI sans validation ou assainissement appropriés. Les attaques par injection de prompt peuvent manipuler les modèles d'IA pour ignorer leurs instructions, divulguer des informations sensibles ou effectuer des actions non intentionnelles.

Remédiation :

Envisagez de valider et d'assainir toutes les entrées des utilisateurs avant de les envoyer aux API LLM. Il est recommandé de mettre en œuvre des modèles de prompt qui séparent clairement les données utilisateur des instructions système à l'aide de formats structurés. Utilisez le filtrage des entrées pour supprimer ou échapper aux prompts potentiellement malveillants. Envisagez d'utiliser des entrées structurées plutôt que du texte libre lorsque cela est possible, et appliquez le principe du moindre privilège aux appels d'API LLM.

python_random_rule-random

Résumé :

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

Sévérité : Faible

CWE : CWE-338

Description :

L'application utilise le module random pour générer des valeurs aléatoires. Le module random met en œuvre un PRNG Mersenne Twister qui n'est pas sécurisé cryptographiquement et produit des valeurs prévisibles pouvant être exploitées lorsqu'elles sont utilisées pour des jetons, des identifiants de session, des clés cryptographiques, des nonces ou d'autres contextes sensibles à la sécurité.

Remédiation :

Envisagez d'utiliser le module secrets à la place lors de la génération de valeurs pour des opérations sensibles à la sécurité. Il est recommandé d'utiliser secrets.token_bytes() pour des octets bruts, secrets.token_hex() pour des chaînes hexadécimales, ou secrets.token_urlsafe() pour des chaînes encodées en base64 sécurisées pour les URL. Pour choisir des éléments aléatoires dans une séquence, utilisez secrets.choice(). Le module random est approprié uniquement pour des fins non liées à la sécurité comme des simulations, des jeux ou des tests où la prévisibilité est acceptable.

OWASP :

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

python_assert_rule-assert-used

Résumé :

Vérification incorrecte des conditions inhabituelles ou exceptionnelles

Gravité : Info

CWE : CWE-754

Description :

L'application utilise assert dans du code non-test, ce qui est dangereux car les instructions d'assertion sont supprimées lorsque Python est compilé avec des flags d'optimisation (-O ou -OO). Cela peut entraîner le contournement des vérifications de sécurité en production, provoquant potentiellement un comportement indéfini ou des vulnérabilités lorsque la logique de validation critique est silencieusement supprimée.

Remédiation :

Supprimez toutes les instructions assert du code de production et remplacez-les par une gestion des erreurs appropriée. Envisagez d'utiliser des conditions if qui lèvent des exceptions appropriées (par exemple, ValueError, AuthError) ou utilisez des blocs try/except pour la logique de validation. Par exemple, remplacez assert user.is_authenticated() par une vérification explicite comme if not user.is_authenticated(): raise AuthError(). Cela garantit que la logique de validation reste active dans les versions optimisées de production.

OWASP :

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