Aller au contenu

Règles Semgrep pour Scala

scala_password_rule-ConstanteDBMotDePasse

Résumé :

Utilisation de mot de passe codé en dur

Gravité : Critique

CWE : CWE-259

Description :

Un mot de passe codé en dur a été détecté dans un appel à java.sql.DriverManager.getConnection(). Le codage des informations d’identification de la base de données directement dans le code source crée une vulnérabilité de sécurité significative, car le mot de passe devient accessible à quiconque ayant accès à la base de code, à l'historique de contrôle de version ou aux binaires compilés. Cette pratique rend la rotation des informations d’identification extrêmement difficile et empêche un audit d'accès approprié, permettant potentiellement à un accès non autorisé à la base de données de persister sans être détecté même après une violation de la sécurité.

Remédiation :

Envisagez de charger les informations d’identification de la base de données à partir de sources externes sécurisées plutôt que de les codifier en dur dans votre application. Les approches recommandées incluent l'utilisation de variables d'environnement, de fichiers de configuration exclus du contrôle de version, ou de préférence d'un Système de Gestion des Clés (KMS). Un KMS fournit une gestion centralisée des secrets avec audit d'accès, capacités de rotation automatique et contrôles d'accès granulaire. Lorsque les informations d’identification sont stockées dans un KMS, vous pouvez facilement les faire pivoter en cas de violation et maintenir un registre complet des accès et des secrets consultés. Pour Google Cloud Platform, envisagez d'utiliser Cloud Key Management (https://cloud.google.com/kms/docs). Pour Amazon Web Services, AWS Secrets Manager ou AWS Systems Manager Parameter Store s'intègrent parfaitement avec KMS (https://aws.amazon.com/kms/). Pour des déploiements sur site ou des solutions agnostiques au cloud, envisagez HashiCorp Vault (https://www.vaultproject.io/). La plupart des frameworks d'application modernes offrent un support intégré pour récupérer les informations d’identification à partir de ces services au moment de l'exécution.

scala_password_rule-EmptyDBPassword

Résumé :

Utilisation d'un mot de passe codé en dur

Gravité : Critique

CWE : CWE-259

Description :

Un mot de passe vide a été détecté dans un appel à java.sql.DriverManager.getConnection(). Se connecter à une base de données sans authentification permet un accès illimité à quiconque peut atteindre le serveur de base de données, exposant des données sensibles à des visualisations, modifications ou suppressions non autorisées. Cette configuration contourne tous les contrôles d'accès et mécanismes d'audit, rendant impossible le suivi de qui a accédé à quelles données ou de restreindre les opérations en fonction des privilèges utilisateur. Des mots de passe vides dans les connexions à la base de données représentent une vulnérabilité de sécurité critique pouvant entraîner une compromission complète des données.

Remédiation :

Envisagez de configurer votre serveur de base de données pour exiger une authentification et de faire respecter les contrôles d'accès basés sur les privilèges des utilisateurs. Consultez la documentation de votre serveur de base de données pour obtenir des instructions sur l'activation de l'authentification et la création de comptes utilisateurs avec les autorisations appropriées. Une fois l'authentification activée, chargez les informations d'identification à partir de sources externes sécurisées plutôt que de les coder en dur dans votre application. Les approches recommandées incluent l'utilisation de variables d'environnement, de fichiers de configuration exclus du contrôle de version, ou de préférence d'un système de gestion des clés (KMS). Un KMS offre une gestion centralisée des secrets avec audit d'accès, capacités de rotation automatique et contrôles d'accès granulaires. Pour Google Cloud Platform, envisagez d'utiliser Cloud Key Management (https://cloud.google.com/kms/docs). Pour Amazon Web Services, AWS Secrets Manager ou AWS Systems Manager Parameter Store s'intègrent parfaitement avec KMS (https://aws.amazon.com/kms/). Pour des déploiements sur site ou des solutions agnostiques au cloud, envisagez HashiCorp Vault (https://www.vaultproject.io/). De plus, mettez en œuvre des contrôles de sécurité au niveau réseau pour restreindre l'accès à la base de données uniquement aux serveurs d'application autorisés.

Résumé :

Neutralisation incorrecte des séquences CRLF dans les en-têtes HTTP ('HTTP Response Splitting')

Gravité : Élevée

CWE : CWE-113

Description :

L'application crée un javax.servlet.http.Cookie avec des données provenant de HttpServletRequest.getParameter() ou appelle Cookie.setValue() avec des paramètres de requête non fiables sans une sanitation appropriée des caractères CRLF. Lorsque des données fournies par l'utilisateur contenant des séquences de retour chariot (CR) et de saut de ligne (LF) sont placées dans des valeurs de cookies, des attaquants peuvent injecter des en-têtes HTTP supplémentaires ou scinder la réponse en plusieurs réponses. Cela permet des attaques de séparation de réponse HTTP où un attaquant contrôle les en-têtes de réponse suivants, ce qui peut potentiellement entraîner une contamination de cache, des attaques XSS ou un vol de session en injectant des en-têtes Set-Cookie malveillants.

Réparation :

Résumé :

Neutralisation inadéquate des séquences CRLF dans les en-têtes HTTP ('Délégation de réponses HTTP')

Gravité : Élevée

CWE : CWE-113

Description :

L'application écrit des données non fiables provenant de HttpServletRequest.getParameter() directement dans les en-têtes HTTP en utilisant HttpServletResponse.setHeader() ou HttpServletResponse.addHeader() sans une désinfection correcte des CRLF. Lorsque des entrées fournies par l'utilisateur contenant des caractères de retour chariot et de saut de ligne sont placées dans les en-têtes HTTP, les attaquants peuvent injecter des en-têtes supplémentaires ou créer plusieurs réponses HTTP à partir d'une seule requête. Cette vulnérabilité de délégation de réponse HTTP permet le empoisonnement de cache, la fixation de session via des en-têtes Set-Cookie malveillants, des attaques XSS via du contenu injecté, et des redirections vers des sites malveillants à travers des en-têtes Location injectés.

Remédiation :

Ne jamais utiliser les paramètres de requête directement dans les en-têtes HTTP sans une validation et une désinfection approfondies. Supprimer tous les caractères CRLF en utilisant replaceAll("[\r\n]", "") ou utiliser l'encodage URL avec java.net.URLEncoder.encode(value, "UTF-8") avant de définir les valeurs d'en-tête. Envisager d'utiliser la bibliothèque OWASP Java Encoder avec Encode.forUriComponent() pour une protection complète. Mettre en œuvre une validation stricte de la liste blanche pour accepter uniquement les caractères attendus plutôt que d'essayer de bloquer les motifs malveillants. Pour les applications Play Framework, utiliser les API d'en-tête typées du framework qui fournissent une protection intégrée contre l'injection d'en-têtes. Éviter d'utiliser les entrées utilisateur dans des en-têtes sensibles à la sécurité tels que Location, Set-Cookie ou Content-Type dès que cela est possible. Si la redirection basée sur l'entrée utilisateur est nécessaire, valider les URL par rapport à une liste blanche de destinations autorisées.

scala_inject_rule-CustomInjectionSQLString

Résumé :

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

Sévérité : Élevée

CWE : CWE-89

Description :

L'application construit des chaînes de requête SQL en utilisant la concaténation de chaînes, String.format(), StringBuilder.append(), ou des opérations .concat() où les mots-clés SQL (SELECT, INSERT, CREATE, UPDATE, ALTER, DELETE, DROP) sont combinés avec des entrées contrôlées par l'utilisateur à partir de paramètres String. Ce modèle indique une vulnérabilité d'injection SQL où les attaquants peuvent injecter des fragments SQL malveillants pour manipuler la sémantique des requêtes, extraire des données non autorisées, modifier le contenu de la base de données, ou élever des privilèges. La haute sévérité reflète la construction directe d'instructions SQL avec des entrées contrôlées de l'extérieur.

Remédiation :

Envisagez de remplacer toute construction de chaîne SQL par des requêtes paramétrées utilisant java.sql.PreparedStatement où l'entrée utilisateur est liée via setString(), setInt(), et des méthodes similaires qui gèrent automatiquement l'échappement. Il est recommandé d'adopter des bibliothèques de base de données spécifiques à Scala comme Slick (pour la sécurité des types à la compilation) ou Doobie (pour la programmation fonctionnelle avec une paramétrisation appropriée des requêtes). Pour le Play Framework, utilisez Anorm avec l'interpolation de chaînes SQL qui fournit un liage de paramètres (SQL"SELECT * FROM users WHERE id = $userId"). Ne construisez jamais SQL par concaténation, même avec StringBuilder - utilisez toujours des interfaces paramétrées. Si la construction dynamique de SQL est absolument nécessaire (par exemple, des noms de tables dynamiques), validez l'entrée contre des listes blanches strictes d'identifiants autorisés et utilisez des fonctions de citation d'identifiants spécifiques à la base de données.

scala_inject_rule-ELInjection

Résumé :

Contrôle inadéquat de la génération de code ('Injection de code')

Sévérité : Élevée

CWE : CWE-94

Description :

L'application utilise javax.el.createValueExpression() ou createMethodExpression() pour construire des expressions de Langage d'Expression (EL) avec des valeurs dynamiques issues de paramètres de chaîne, ce qui permet des attaques par injection de code. Lorsque des entrées utilisateur non fiables sont utilisées pour construire des expressions EL sans validation, les attaquants peuvent injecter une syntaxe EL malveillante pour accéder à des objets sensibles dans le contexte EL, invoquer des méthodes arbitraires, lire ou modifier l'état de l'application, et potentiellement obtenir une exécution de code à distance grâce aux capacités de réflexion Java disponibles dans l'environnement EL.

Remédiation :

Envisagez d'éviter complètement la construction d'expressions EL dynamiques - utilisez des expressions statiques avec des valeurs paramétrées passées par le contexte EL à la place. Il est recommandé de passer les données utilisateur en tant que variables de contexte EL (en utilisant ELContext.getVariableMapper()) plutôt que de les concaténer dans des chaînes d'expressions, ce qui garantit que les données sont traitées comme des valeurs et non comme du code. Si les expressions dynamiques sont inévitables, mettez en œuvre une validation stricte par liste blanche qui n'autorise que les noms de propriétés ou les identifiants de méthodes attendus. Pour les applications JSP/JSF, envisagez d'utiliser des inclusions paramétrées ou une logique côté contrôleur au lieu de la génération dynamique d'EL. Soyez conscient que les expressions EL ont accès à des objets Java puissants et à des capacités de réflexion, donc limiter les objets disponibles dans le contexte EL peut fournir une défense en profondeur contre les attaques par injection.

scala_inject_rule-PathTraversalOut

Résumé :

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

Gravité : Élevée

CWE : CWE-22

Description :

L'application ouvre des fichiers en écriture en utilisant java.io.FileWriter ou java.io.FileOutputStream avec des chemins de fichiers construits à partir de paramètres de chaîne ou d'arguments de ligne de commande des paramètres de fonction Array[String]. Lorsque des paramètres non filtrés contrôlent les chemins de fichiers, les attaquants peuvent injecter des séquences de traversée de chemin (../, ../../) ou des chemins absolus pour écrire des fichiers à des emplacements arbitraires du système de fichiers en dehors des répertoires prévus. Cela permet aux attaquants de remplacer des fichiers systèmes critiques, des configurations d'application, ou du code exécutable, pouvant potentiellement aboutir à une exécution de code à distance ou à un déni de service. La gravité élevée reflète la capacité d'écriture qui peut compromettre directement l'intégrité du système.

Remédiation :

Envisagez d'utiliser org.apache.commons.io.FilenameUtils.getName() pour extraire uniquement le composant nom de fichier, empêchant toute traversée de répertoire. Il est recommandé de valider les chemins de fichiers en utilisant File.getCanonicalPath() et de vérifier que le chemin résolu commence par un répertoire de base autorisé avant toute opération d'écriture. On peut utiliser java.nio.file.Path.normalize() pour réduire les séquences de traversée, puis vérifier que le chemin normalisé est un descendant du répertoire souhaité en utilisant startsWith(). Implémentez une validation stricte par liste blanche pour les noms de fichiers autorisés et rejetez tout chemin contenant des séparateurs de répertoire ou des motifs de traversée. Pour les scénarios de téléchargement, générez des noms de fichiers aléatoires côté serveur et conservez le mappage vers les noms fournis par les utilisateurs séparément. Définissez des permissions appropriées sur les répertoires de téléchargement pour limiter les dommages potentiels des attaques de traversée.

OWASP :

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

scala_ldap_rule-EntryPoisoning

Résumé :

Contrôle de sécurité mal implémenté pour le standard

Gravité : Élevée

CWE : CWE-358

Description :

Configuration des SearchControls LDAP détectée avec returningObjFlag défini sur true, ce qui permet la désérialisation automatique d'objets Java à partir des entrées LDAP. Cela peut conduire à des attaques de contamination d'entrée LDAP où des entrées LDAP malveillantes contenant des objets sérialisés déclenchent une exécution de code arbitraire lorsqu'elles sont récupérées par l'application.

Remédiation :

Envisagez de définir le paramètre returningObjFlag sur false dans le constructeur de SearchControls pour empêcher la désérialisation automatique d'objets à partir des entrées LDAP. Il est recommandé d'utiliser new SearchControls(scope, countLimit, timeLimit, attributes, false, deref) à la place. Si la récupération d'objets est nécessaire, envisagez de mettre en œuvre une validation de type explicite et d'utiliser un mécanisme de désérialisation sécurisé avec une liste blanche stricte des classes autorisées.

scala_password_rule-HardcodePassword

Résumé :

Utilisation de mots de passe en dur

Sévérité : Élevée

CWE : CWE-259

Description :

Un mot de passe en dur a été détecté dans des appels d'API sensibles à la sécurité tels que
KeyStore.load(), PBEKeySpec(), KeyManagerFactory.init(),
PasswordCallback.setPassword(), DriverManager.getConnection(), ou
CSRFHandler.create(). L'insertion de données d'identification directement dans le code source
crée une vulnérabilité de sécurité importante, car les mots de passe deviennent accessibles
à quiconque ayant accès à la base de code, à l'historique de contrôle de version ou aux
binaires compilés. Cette pratique rend la rotation des identifiants extrêmement difficile et
empêche un audit d'accès approprié, permettant potentiellement à un accès non autorisé de
persister sans être détecté même après une violation de sécurité. Lorsque les mots de passe sont
intégrés dans le code, ils restent souvent inchangés pendant de longues périodes et peuvent être
exposés accidentellement par le partage de code, les fuites de dépôts ou la décompilation de
binaires.

Remédiation :

Envisagez de charger les mots de passe et les données d'identification sensibles à partir de
sources externes sécurisées plutôt que de les coder en dur dans votre application. Les approches
recommandées incluent l'utilisation de variables d'environnement, de fichiers de configuration
exclus du contrôle de version, ou de préférence, d'un système de gestion des clés (KMS). Un KMS
offre une gestion centralisée des secrets avec audit d'accès, capacités de rotation automatique,
et contrôles d'accès granulaires. Lorsque les identifiants sont stockés dans un KMS, vous pouvez
les faire facilement tourner en cas de violation et maintenir une trace d'audit complète de qui
a accédé à quels secrets et quand. Pour Google Cloud Platform, envisagez d'utiliser Cloud Key
Management (https://cloud.google.com/kms/docs). Pour Amazon Web Services, AWS Secrets Manager
ou AWS Systems Manager Parameter Store s'intègrent parfaitement avec le KMS
(https://aws.amazon.com/kms/). Pour les déploiements sur site ou les solutions agnostiques au
cloud, envisagez HashiCorp Vault (https://www.vaultproject.io/). La plupart des frameworks
d'application modernes offrent un support intégré pour récupérer des identifiants à partir de ces
services au moment de l'exécution. Pour les mots de passe de keystore et de chiffrement,
envisagez d'utiliser des magasins d'identifiants du système d'exploitation ou des modules de
sécurité matériels (HSM) pour une protection supplémentaire.

scala_perm_rule-OverlyPermissiveFilePermissionInline

Résumé :

Attribution Incorrecte de Permissions pour une Ressource Critique

Gravité : Élevée

CWE : CWE-732

Description :

La définition de permissions de fichier trop permissives via java.nio.file.Files.setPosixFilePermissions() avec des chaînes de permissions provenant de PosixFilePermissions.fromString() qui accordent des permissions de lecture, écriture ou exécution à "d'autres" (lisible/écrivable par tout le monde) expose des fichiers sensibles à un accès non autorisé. Lorsque la chaîne de permissions contient des drapeaux de permission dans les trois derniers caractères (par exemple, "rwxrwxrwx" ou "rw-rw-rw-"), elle permet à n'importe quel utilisateur sur le système d'accéder au fichier, ce qui peut conduire à des divulgations d'informations, à la falsification de données, ou à une élévation de privilèges.

Remédiation :

Envisagez de restreindre les permissions de fichier uniquement au propriétaire et au groupe qui nécessitent l'accès, en supprimant toutes les permissions pour "les autres". Il est recommandé d'utiliser des chaînes de permissions comme "rw-------" (0600) pour les fichiers sensibles auxquels seul le propriétaire doit avoir accès, ou "rw-r-----" (0640) pour les fichiers nécessitant un accès en lecture pour le groupe. Lorsque vous définissez les permissions avec PosixFilePermissions.fromString(), assurez-vous que les trois derniers caractères sont "---" pour refuser tout accès aux autres. Pour les fichiers exécutables, envisagez "rwx------" (0700) ou "rwxr-x---" (0750) au lieu de permissions exécutables pour tout le monde. Examinez la logique de création de fichiers de votre application et établissez une politique de permission par défaut sécurisée. Envisagez d'utiliser des ACL (Listes de Contrôle d'Accès) pour un contrôle plus granulaire des permissions si nécessaire. Validez toujours que les fichiers sensibles tels que les fichiers de configuration, les clés privées, et les magasins d'identifiants disposent de permissions strictes immédiatement après leur création.

scala_smtp_rule-InsecureSmtp

Résumé :

Validation incorrecte du certificat avec non-concordance de l'hôte

Sévérité : Élevée

CWE : CWE-297

Description :

Apache Commons Email est configuré avec SSL activé mais sans vérification de l'identité du serveur. Cela permet des attaques de type homme du milieu où un attaquant peut intercepter le trafic SMTP, capturant potentiellement des contenus d'e-mails sensibles et des identifiants d'authentification malgré la connexion SSL.

Remédiation :

Lors de l'utilisation des classes Apache Commons Email comme SimpleEmail, HtmlEmail ou MultiPartEmail avec SSL, activez toujours la vérification de l'identité du serveur en appelant setSSLCheckServerIdentity(true) après setSSLOnConnect(true). Cela garantit que le nom d'hôte du certificat SSL correspond au serveur auquel vous vous connectez, prévenant ainsi les attaques de type homme du milieu. Sans cette vérification, SSL offre un chiffrement mais pas d'authentification, laissant les connexions vulnérables à des interceptions.

OWASP :

  • A2:2017-Authentification brisée
  • A07:2021-Failles d'identification et d'authentification

scala_smtp_rule-SmtpClient

Résumé :

Neutralisation inadéquate des éléments spéciaux utilisés dans une commande

Gravité : Élevée

CWE : CWE-77

Description :

Vulnérabilité potentielle d'injection d'en-tête SMTP détectée lors de l'utilisation des méthodes MimeMessage telles que setSubject(), addHeader(), setDescription(), et setDisposition() avec des valeurs non littérales. Si les entrées utilisateur sont placées dans les en-têtes d'e-mail sans désinfection adéquate, des attaquants peuvent injecter des caractères CR/LF pour insérer des en-têtes arbitraires ou manipuler l'acheminement et le contenu des e-mails.

Remédiation :

Envisagez d'utiliser des bibliothèques d'e-mail sûres telles qu'Apache Commons Email ou Simple Java Mail, qui désinfectent automatiquement les valeurs d'en-tête et préviennent les attaques par injection. Il est recommandé de valider et de supprimer les caractères CR (\r) et LF (\n) de toutes les données contrôlées par l'utilisateur avant de les inclure dans les en-têtes d'e-mail. Si vous utilisez MimeMessage directement, envisagez d'implémenter une validation stricte des entrées en utilisant des modèles de liste blanche pour les caractères autorisés dans chaque en-tête.

scala_unsafe_rule-ExternalConfigControl

Résumé :

Contrôle externe des paramètres système ou de configuration

Gravité : Élevée

CWE : CWE-15

Description :

Un contrôle externe de la configuration du catalogue de base de données a été détecté. Les entrées fournies par l'utilisateur via HttpServletRequest.getParameter() sont transmises directement à Connection.setCatalog() sans validation. Cela permet aux attaquants de manipuler les paramètres de configuration de la base de données, ce qui pourrait amener l'application à se connecter à des catalogues de base de données non autorisés, à perturber le service en fournissant des noms de catalogue inexistants ou à accéder à des données sensibles provenant de schémas de base de données non prévus.

Remédiation :

Envisagez de mettre en œuvre une validation stricte et une liste blanche des noms de catalogue avant de les utiliser dans Connection.setCatalog(). Il est recommandé de définir un ensemble fixe de noms de catalogues autorisés dans la configuration et de valider les entrées utilisateur par rapport à cette liste. Pensez à utiliser une énumération ou un trait scellé pour représenter les options de catalogue valides, garantissant que seules des valeurs prédéfinies peuvent être utilisées. Évitez de transmettre directement les paramètres fournis par l'utilisateur aux méthodes de configuration de la base de données. Si la sélection dynamique de catalogue est nécessaire, mettez en œuvre une couche de mapping qui traduit les entrées utilisateur assainies en identifiants de catalogue internes. Pensez à enregistrer les tentatives d'accès au catalogue à des fins de surveillance de la sécurité et d'audit.

scala_xml_rule-XmlDecoder

Résumé :

Désérialisation de données non fiables

Gravité : Élevée

CWE : CWE-502

Description :

Utiliser java.beans.XMLDecoder avec la méthode readObject() pour désérialiser des XML provenant de sources non fiables crée une vulnérabilité critique d'exécution de code à distance. XMLDecoder exécute un code Java arbitraire incorporé dans le XML pendant la désérialisation, permettant aux attaquants d'instancier des classes malveillantes, d'invoquer des méthodes et de prendre le contrôle total de l'application. Cette vulnérabilité est particulièrement dangereuse car XMLDecoder a été conçu pour la persistance de beans de confiance, pas pour le traitement d'entrées non fiables.

Remédiation :

Envisagez de migrer vers des formats de sérialisation sûrs comme JSON avec des bibliothèques telles que Jackson, Gson, ou kotlinx.serialization pour les applications Scala. Ces bibliothèques offrent une désérialisation type-safe sans risques d'exécution de code arbitraire. Si la sérialisation XML est requise, il est recommandé d'utiliser JAXB avec une validation stricte du schéma ou XStream configuré avec un cadre de sécurité activé et des listes de types explicites via XStream.allowTypes(). Pour les fichiers de configuration, envisagez d'utiliser des formats structurés comme YAML avec SnakeYAML en mode sécurisé, ou HOCON pour les applications Scala. Ne désérialisez jamais de XML provenant de sources non fiables sans validation stricte, et mettez en œuvre une défense en profondeur en exécutant la désérialisation dans des environnements en bac à sable avec des capacités de chargement de classes restreintes.

scala_crypto_rule-BlowfishKeySize

Résumé :

Force de chiffrement inadéquate

Sévérité : Moyenne

CWE : CWE-326

Description :

L'application utilise javax.crypto.KeyGenerator.getInstance("Blowfish") avec une taille de clé inférieure à 128 bits, rendant le texte chiffré vulnérable aux attaques par force brute. Bien que Blowfish prenne en charge des tailles de clé variables allant de 32 à 448 bits, les normes cryptographiques modernes exigent un minimum de 128 bits d'entropie pour garantir une sécurité adéquate contre les capacités informatiques actuelles. L'utilisation de tailles de clé insuffisantes réduit considérablement le temps et les ressources nécessaires à un attaquant pour effectuer avec succès des attaques de récupération de clé par force brute.

Remédiation :

Envisagez de migrer de Blowfish à AES (Norme de chiffrement avancé) avec des clés de 256 bits en utilisant javax.crypto.KeyGenerator.getInstance("AES") et en initialisant avec keyGen.init(256). AES est la norme recommandée par le NIST actuelle et offre de meilleures performances et caractéristiques de sécurité que Blowfish pour les applications modernes. Si Blowfish doit être utilisé pour des raisons de compatibilité avec les anciennes versions, assurez-vous que les tailles de clé sont d'au moins 128 bits, bien que 256-448 bits soient recommandés. Pour les applications Scala, envisagez d'utiliser des bibliothèques de cryptographie de niveau supérieur comme Tsec ou l'Architecture de cryptographie Java (JCA) avec des wrappers sécurisés par type pour éviter les erreurs de configuration.

scala_crypto_rule-CipherDESInsecure

Résumé :

Force de chiffrement inadéquate

Gravité : Moyenne

CWE : CWE-326

Description :

L'application utilise javax.crypto.Cipher.getInstance("DES/...") qui implémente la norme de chiffrement de données, un chiffrement cassé sur le plan cryptographique qui n'est plus considéré comme sécurisé pour les applications modernes. DES utilise une taille de clé de 56 bits, ce qui est bien trop petit selon les normes actuelles et peut être attaqué par brute-force en quelques heures en utilisant des ressources informatiques facilement disponibles. La petite taille de bloc de 64 bits de l'algorithme le rend également vulnérable à des attaques de type birthday lors du chiffrement de grandes quantités de données.

Remédiation :

Migrez vers AES (Advanced Encryption Standard) qui est l'algorithme de chiffrement symétrique recommandé par le NIST. Remplacez javax.crypto.Cipher.getInstance("DES/...") par javax.crypto.Cipher.getInstance("AES/GCM/NoPadding") pour un chiffrement authentifié qui garantit à la fois la confidentialité et la protection de l'intégrité. Utilisez des clés AES de 256 bits générées avec javax.crypto.KeyGenerator.getInstance("AES") initialisées à 256 bits. Pour les applications Scala, envisagez d'utiliser la bibliothèque Tsec qui fournit des primitives cryptographiques sûres en termes de type et facilite l'utilisation de valeurs par défaut sécurisées. Assurez-vous de générer correctement le vecteur d'initialisation (IV) à l'aide de java.security.SecureRandom pour chaque opération de chiffrement.

scala_crypto_rule-CipherDESedeInsecure

Résumé :

Force de chiffrement inadéquate

Gravité : Moyenne

CWE : CWE-326

Description :

L'application utilise javax.crypto.Cipher.getInstance("DESede/...") qui implémente Triple DES (3DES), un algorithme de chiffrement hérité qui est obsolète et n'est plus recommandé pour les applications modernes. Bien que Triple DES applique DES trois fois pour augmenter la sécurité, il souffre toujours d'une taille de bloc de 64 bits, ce qui le rend vulnérable aux attaques d'anniversaire après le traitement d'environ 32 Go de données avec la même clé. Le NIST a officiellement déprécié 3DES en 2023 et recommande de passer à AES pour toutes les nouvelles applications et les systèmes existants.

Remédiation :

Migrez vers AES-256-GCM (Galois/Counter Mode) qui fournit un chiffrement authentifié avec des données associées (AEAD). Remplacez javax.crypto.Cipher.getInstance("DESede/...") par javax.crypto.Cipher.getInstance("AES/GCM/NoPadding") et utilisez des clés de 256 bits pour une sécurité maximale. AES-GCM fournit à la fois le chiffrement et l'authentification en une seule opération, éliminant ainsi le besoin d'opérations HMAC séparées. Pour les projets Scala, envisagez d'utiliser les bibliothèques Tsec ou BouncyCastle qui offrent des API Scala idiomatiques pour les opérations cryptographiques. Lors de la migration des systèmes hérités, assurez-vous d'avoir un plan de transition pour le réenregistrement des données déjà chiffrées par 3DES, car les sorties de chiffrement ne sont pas compatibles entre les algorithmes.

scala_crypto_rule-CipherECBMode

Résumé :

Renforcement de cryptage inadéquat

Gravité : Moyenne

CWE : CWE-326

Description :

L'application utilise javax.crypto.Cipher.getInstance() avec le mode ECB (Electronic Code Book) tel que "AES/ECB/..." ou "DES/ECB/...", qui ne fournit pas de sécurité sémantique. Le mode ECB crypte des blocs de texte clair identiques en blocs de ciphertext identiques, révélant des motifs dans les données chiffrées qui peuvent divulguer des informations sur le texte clair sous-jacent. Ce comportement déterministe permet aux attaquants de détecter des données répétées, d'effectuer des attaques par substitution de blocs et potentiellement de reconstruire des portions du texte clair sans déchiffrer le chiffrement sous-jacent.

Remédiation :

Remplacer le mode ECB par un mode de cryptage authentifié comme GCM (Galois/Counter Mode) en utilisant javax.crypto.Cipher.getInstance("AES/GCM/NoPadding"), qui fournit à la fois une protection de la confidentialité et de l'intégrité. Le mode GCM utilise un IV (vecteur d'initialisation) unique pour chaque opération de chiffrement, garantissant que des textes clairs identiques produisent des ciphertexts différents. Générer un IV aléatoire sécurisé cryptographiquement de 12 octets en utilisant java.security.SecureRandom pour chaque chiffrement et le stocker avec le ciphertext. Pour les applications Scala, des bibliothèques comme Tsec fournissent des wrappers fonctionnels autour de JCA qui imposent des valeurs par défaut sécurisées et rendent plus difficile la mauvaise configuration des modes de chiffrement. Si GCM n'est pas disponible, le mode CBC avec vérification HMAC est une alternative acceptable, bien qu'il nécessite une mise en œuvre minutieuse.

scala_crypto_rule-CipherIntegrity

Résumé :

Support pour la vérification d'intégrité manquant

Gravité : Moyenne

CWE : CWE-353

Description :

L'application utilise javax.crypto.Cipher.getInstance() avec des modes de chiffrement comme CBC, CTR, OFB, ou ECB qui ne fournissent que du chiffrement sans authentification. Ces modes produisent du texte chiffré qui est susceptible d'être altéré par un adversaire, car ils ne permettent pas de détecter la falsification ou la modification des données chiffrées. Un attaquant capable d'intercepter et de modifier le texte chiffré peut réaliser des attaques par inversion de bits en modes CTR ou OFB, ou des attaques par oracle de rembourrage en mode CBC, ce qui peut conduire à une manipulation arbitraire de texte en clair ou à une décryption complète sans connaissance de la clé.

Remédiation :

Migrer vers des modes de chiffrement authentifiés qui fournissent à la fois confidentialité et intégrité en une seule opération. Utiliser javax.crypto.Cipher.getInstance("AES/GCM/NoPadding") pour le chiffrement authentifié avec données associées (AEAD), qui authentifie automatiquement le texte chiffré et empêche la falsification. Si GCM n'est pas disponible, utiliser le mode CBC avec une opération HMAC-SHA256 séparée suivant le modèle Encrypt-then-MAC, bien que cela nécessite une implémentation soignée pour éviter les vulnérabilités de timing. Pour les applications Scala, la bibliothèque Tsec fournit des constructions AEAD sûres pour le type qui facilitent l'utilisation correcte du chiffrement authentifié. Toujours vérifier le tag d'authentification avant d'essayer de déchiffrer les données pour éviter le traitement de textes chiffrés falsifiés.

scala_crypto_rule-CipherPaddingOracle

Résumé :

Ordre de comportement incorrect

Gravité : Moyenne

CWE : CWE-696

Description :

L'application utilise javax.crypto.Cipher.getInstance() avec le mode CBC et PKCS5Padding (par exemple, "AES/CBC/PKCS5Padding"), qui est susceptible aux attaques par oracle de rembourrage. Un adversaire peut potentiellement déchiffrer du texte chiffré sans connaître la clé si l'application révèle des différences de timing, des messages d'erreur distincts ou des différences comportementales entre des rembourrages valides et invalides lors du déchiffrement. Ces attaques par oracle ont été exploitées avec succès dans de nombreux systèmes réels, permettant une récupération complète du texte en clair grâce à une manipulation soigneuse des blocs de texte chiffré et à l'observation des réponses d'erreur de déchiffrement.

Remédiation :

Remplacez le mode CBC par un chiffrement authentifié en utilisant javax.crypto.Cipher.getInstance("AES/GCM/NoPadding"), qui élimine complètement le rembourrage en utilisant des modes de chiffrement par flux et fournit une authentification intégrée. Le mode GCM authentifie le texte chiffré avant le déchiffrement, empêchant les attaques par oracle de rembourrage et d'autres tentatives de manipulation. Si le mode CBC doit être utilisé pour des raisons de compatibilité avec les systèmes hérités, implémentez le schéma Encrypt-then-MAC avec HMAC-SHA256 et vérifiez le MAC en temps constant avant d'essayer de déchiffrer. Pour les applications Scala, utilisez des bibliothèques comme Tsec qui proposent des implémentations AEAD sécurisées par défaut et aident à éviter les pièges cryptographiques courants. Ne jamais exposer de différents messages d'erreur ou comportements de timing pour les échecs de validation de rembourrage par rapport à d'autres erreurs de déchiffrement.

scala_crypto_rule-CustomMessageDigest

Résumé :

Utilisation d'un algorithme cryptographique cassé ou risqué

Gravité : Moyenne

CWE : CWE-327

Description :

L'application implémente une classe personnalisée qui étend java.security.MessageDigest, ce qui est extrêmement sujet à erreurs et dangereux. Les fonctions de hachage cryptographique nécessitent une construction mathématique soignée pour garantir des propriétés telles que la résistance aux collisions, la résistance aux préimages et l'effet d'avalanche. Même des erreurs d'implémentation mineures dans des fonctions de hachage personnalisées peuvent conduire à des échecs de sécurité catastrophiques qui peuvent ne pas être immédiatement évidents mais qui peuvent être exploités par des attaquants sophistiqués. Les implémentations cryptographiques personnalisées manquent de l'examen par les pairs et de la cryptanalyse approfondie que les algorithmes standard ont subis.

Réparation :

Supprimez les implémentations de MessageDigest personnalisées et utilisez des fonctions de hachage cryptographiques standard de l'Architecture de cryptographie Java. Utilisez java.security.MessageDigest.getInstance() avec des algorithmes approuvés par le NIST tels que "SHA-256", "SHA-384" ou "SHA-512" en fonction de vos exigences de sécurité. Pour la plupart des applications, SHA-256 offre un excellent équilibre entre sécurité et performance. Pour les applications Scala, envisagez d'utiliser des bibliothèques de niveau supérieur comme Tsec qui fournissent des wrappers type-safe autour des fonctions de hachage JCA et facilitent le respect des meilleures pratiques cryptographiques. Si vous avez besoin d'un comportement de hachage spécifique à l'application, utilisez HMAC avec une fonction de hachage standard au lieu d'implémenter une cryptographie personnalisée, car HMAC fournit un hachage avec clé avec des propriétés de sécurité prouvées.

scala_crypto_rule-HazelcastSymmetricEncryption

Résumé :

Force de chiffrement insuffisante

Sévérité : Moyenne

CWE : CWE-326

Description :

L'application utilise new com.hazelcast.config.SymmetricEncryptionConfig() pour configurer les communications réseau de Hazelcast avec un chiffrement symétrique, qui est obsolète et offre une sécurité insuffisante. Le chiffrement symétrique de Hazelcast utilise généralement des ciphers faibles comme DES ou Blowfish par défaut et ne fournit pas d'authentification ni de protection contre l'intégrité du trafic réseau. Sans authentification, le cluster est vulnérable aux attaques de type homme du milieu où un attaquant peut intercepter, modifier ou injecter des messages entre les nœuds du cluster. Hazelcast a déprécié cette fonctionnalité au profit d'un chiffrement basé sur TLS/SSL qui offre des garanties de sécurité plus fortes.

Remédiation :

Remplacez SymmetricEncryptionConfig par une configuration TLS/SSL en utilisant le SSLConfig de Hazelcast qui offre une authentification mutuelle et des suites de chiffrement modernes. Configurez TLS pour les communications membre à membre et client à membre de Hazelcast en utilisant networkConfig.setSSLConfig(sslConfig) avec des magasins de clés et de confiance appropriés. Utilisez TLS 1.2 ou supérieur avec des suites de chiffrement robustes qui offrent la confidentialité future, telles que celles utilisant l'échange de clés ECDHE et AES-GCM pour le chiffrement. Pour les applications Scala, enveloppez la configuration de Hazelcast dans des objets de configuration sûrs typiquement pour éviter les erreurs de configuration. De plus, activez l'authentification TLS mutuelle pour garantir que seuls les nœuds autorisés peuvent rejoindre le cluster. Consultez la documentation officielle de Hazelcast pour les meilleures pratiques de configuration TLS et assurez-vous de bien gérer les certificats, y compris la rotation et la révocation.

scala_crypto_rule-TailleDeCléInsuffisanteRsa

Résumé :

Force de cryptage inadéquate

Sévérité : Moyenne

CWE : CWE-326

Description :

L'application utilise KeyPairGenerator.getInstance() ou RSAKeyGenParameterSpec pour générer des clés RSA ou DSA avec une taille de clé inférieure à 2048 bits. Des tailles de clé insuffisantes rendent les opérations cryptographiques asymétriques vulnérables aux attaques de factorisation, où un attaquant disposant de ressources computationnelles suffisantes peut déchiffrer la clé privée et compromettre toutes les garanties de sécurité. Le NIST recommande des tailles de clé minimales de 2048 bits pour RSA et DSA, avec des clés de 3072 bits ou plus préférées pour une sécurité à long terme au-delà de 2030. Les clés de moins de 2048 bits peuvent potentiellement être compromises en utilisant des ressources computationnelles modernes, y compris le cloud computing et du matériel spécialisé.

Remédiation :

Générez des clés RSA d'une taille minimale de 2048 bits en appelant keyPairGen.initialize(2048) ou en utilisant new RSAKeyGenParameterSpec(2048, RSAKeyGenParameterSpec.F4). Pour les applications nécessitant une sécurité à long terme ou une protection d'actifs de grande valeur, utilisez des clés de 3072 bits ou 4096 bits. En alternative, envisagez de migrer vers la cryptographie à courbe elliptique (ECC) en utilisant l'ECDSA avec la courbe P-256 ou supérieure, qui offre une sécurité équivalente à celle du RSA de 3072 bits avec des tailles de clé significativement plus petites et de meilleures performances. Pour les applications Scala, envisagez d'utiliser des bibliothèques de haut niveau comme Tsec qui fournissent des API type-safe pour la génération de clés avec des valeurs par défaut sécurisées. Lors de la génération de nouvelles clés, utilisez un générateur de nombres aléatoires cryptographiquement sécurisé avec java.security.SecureRandom pour garantir l'imprévisibilité des clés.

scala_crypto_rule-NullCipher

Résumé :

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

Gravité : Moyenne

CWE : CWE-327

Description :

L'application utilise new javax.crypto.NullCipher(), qui est une implémentation de chiffre spéciale qui ne fait aucune encryption, retournant un texte chiffré identique au texte clair fourni. Bien que NullCipher puisse être approprié dans des contextes de test restreints ou comme un espace réservé pendant le développement, son utilisation accidentelle dans du code de production introduit un risque critique de confidentialité où des données sensibles sont transmises ou stockées sans protection cryptographique. Le danger est particulièrement aigu car NullCipher implémente l'interface standard Cipher, ce qui facilite son utilisation involontaire à la place d'une véritable encryption sans déclencher d'erreurs évidentes.

Remédiation :

Remplacez NullCipher par une véritable encryption en utilisant javax.crypto.Cipher.getInstance("AES/GCM/NoPadding") pour une encryption authentifiée qui offre à la fois une protection de la confidentialité et de l'intégrité. Si NullCipher est utilisé comme un mock de test, utilisez des cadres de simulation appropriés comme ScalaTest ou Mockito pour simuler le comportement du chiffre plutôt que d'utiliser NullCipher dans le code de test, car cela réduit le risque que NullCipher fuite accidentellement dans la production. Pour les applications Scala, envisagez d'utiliser des bibliothèques comme Tsec qui fournissent des abstractions de chiffre sûres pour les types et rendent impossible l'utilisation accidentelle d'implémentations no-op dans le code de production. Implémentez une validation de configuration qui rejette explicitement les configurations de chiffre nulles ou no-op lorsque l'application démarre, garantissant que l'encryption est correctement configurée avant de traiter des données sensibles.

scala_crypto_rule-RsaNoPadding

Résumé :

Utilisation de l'algorithme RSA sans OAEP

Gravité : Moyenne

CWE : CWE-780

Description :

L'application utilise javax.crypto.Cipher.getInstance() avec le chiffrement RSA mais spécifie le mode "NoPadding", ce qui rend le chiffrement déterministe et vulnérable à plusieurs attaques. RSA sans padding est vulnérable aux attaques par texte chiffré choisi où un attaquant peut fabriquer des entrées spécifiques pour extraire des informations sur le texte en clair ou la clé privée. Sans OAEP (Padding de Chiffrement Asymétrique Optimal), le chiffrement RSA est malléable, ce qui signifie que les attaquants peuvent modifier les textes chiffrés de manière prévisible, et cela fuit des informations lorsque le même texte en clair est chiffré plusieurs fois. Les normes cryptographiques modernes exigent que RSA soit utilisé avec du padding OAEP pour fournir une sécurité sémantique et une protection contre les attaques par texte chiffré choisi adaptatif.

Remédiation :

Remplacez RSA NoPadding par OAEP en utilisant javax.crypto.Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding"), ce qui fournit une sécurité sémantique et une protection contre les attaques par texte chiffré choisi adaptatif. Le padding OAEP ajoute de l'aléa à chaque opération de chiffrement, garantissant que le chiffrement du même texte en clair plusieurs fois produit des textes chiffrés différents. Pour une sécurité encore meilleure, utilisez OAEP avec des fonctions de hachage SHA-256 ou SHA-512 plutôt qu'avec l'ancien SHA-1. Pour les applications Scala, envisagez d'utiliser des bibliothèques comme Tsec ou BouncyCastle qui fournissent des API idiomatiques pour le chiffrement RSA avec des réglages par défaut sécurisés. Notez que RSA est le mieux adapté pour chiffrer de petites quantités de données comme des clés symétriques ; pour le chiffrement de données en masse, utilisez RSA pour chiffrer une clé AES puis utilisez AES-GCM pour chiffrer les données réelles (schéma de chiffrement hybride).

OWASP :

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

scala_crypto_rule-WeakMessageDigest

Résumé :

Force de chiffrement inadéquate

Sévérité : Moyenne

CWE : CWE-326

Description :

L'application utilise MessageDigest.getInstance() ou Signature.getInstance() avec des algorithmes de hachage cryptographiquement faibles tels que MD5, MD4, MD2 ou SHA-1. Ces algorithmes sont cryptographiquement cassés et vulnérables aux attaques par collision, où un attaquant peut élaborer deux entrées différentes produisant la même sortie de hachage. Les attaques par collision contre MD5 sont devenues pratiques depuis 2004, et les attaques par collision SHA-1 ont été démontrées en 2017 avec l'attaque SHAttered. L'utilisation de ces fonctions de hachage faibles mine toute garantie de sécurité pour les signatures numériques, la vérification d'intégrité, le stockage de mots de passe ou la validation de certificats.

Remédiation :

Migrer vers des fonctions de hachage plus robustes comme SHA-256 ou des algorithmes plus forts des familles SHA-2 ou SHA-3. Remplacer les algorithmes faibles par MessageDigest.getInstance("SHA-256") pour la plupart des applications, ou utiliser "SHA-384" ou "SHA-512" pour des exigences de sécurité plus élevées. Pour les signatures numériques, utiliser Signature.getInstance("SHA256withRSA") ou Signature.getInstance("SHA256withECDSA") au lieu des algorithmes de signature basés sur SHA-1. Pour le hachage des mots de passe, utiliser des algorithmes spécialement conçus comme bcrypt, scrypt ou Argon2 plutôt que des fonctions de hachage de usage général. Pour les applications Scala, envisager d'utiliser des bibliothèques comme Tsec qui fournissent des primitives cryptographiques sûres avec des valeurs par défaut sécurisées et empêchent l'utilisation accidentelle d'algorithmes faibles. Lors de la migration depuis MD5 ou SHA-1, assurer un plan de transition pour vérifier les hachages hérités tout en générant de nouveaux hachages avec des algorithmes plus forts.

scala_crypto_rule-WeakTLSProtocol

Résumé :

Validation de certificat incorrecte

Gravité : Moyenne

CWE : CWE-295

Description :

L'application utilise javax.net.ssl.SSLContext.getInstance("SSL") ou instancie DefaultHttpClient(), tous deux utilisant des versions de protocoles SSL/TLS obsolètes et non sécurisées. L'identifiant de protocole générique "SSL" permet la négociation vers SSLv2 et SSLv3, qui présentent des vulnérabilités critiques connues, notamment les attaques POODLE, BEAST et CRIME qui permettent aux attaquants de déchiffrer le trafic chiffré. Ces protocoles hérités manquent de fonctionnalités de sécurité modernes telles que la confidentialité parfaite et le chiffrement authentifié, et ont été officiellement déconseillés par l'IETF. L'utilisation de ces configurations expose le trafic de l'application à des attaques de type homme du milieu et à des attaques de rétrogradation de protocole.

Remédiation :

Remplacez SSLContext.getInstance("SSL") par SSLContext.getInstance("TLSv1.2") ou SSLContext.getInstance("TLSv1.3") pour utiliser des versions modernes et sécurisées du protocole TLS. Pour une compatibilité maximale tout en maintenant la sécurité, utilisez "TLSv1.2" qui est largement soutenu et ne présente pas de vulnérabilités critiques connues. Pour DefaultHttpClient, migrez vers Apache HttpClient 4.5+ en utilisant HttpClients.createDefault() qui utilise par défaut TLS 1.2+. Pour les applications Scala, envisagez d'utiliser des bibliothèques HTTP modernes telles que http4s, sttp ou Akka HTTP qui offrent des paramètres de sécurité TLS par défaut et une configuration sûre par type. De plus, configurez votre contexte SSL pour utiliser des suites de chiffrement fortes qui offrent une confidentialité parfaite en priorisant les algorithmes d'échange de clés ECDHE. Assurez-vous que la validation des certificats est correctement activée et évitez de désactiver la vérification des noms d'hôte ou de faire confiance à tous les certificats, même dans les environnements de développement.

scala_endpoint_rule-JaxRsEndpoint

Résumé :

Utilisation d'une source moins fiable

Gravité : Moyenne

CWE : CWE-348

Description :

Cette méthode est annotée avec des annotations JAX-RS (JSR-311) comme @javax.ws.rs.Path, ce qui en fait un point de terminaison HTTP REST qui accepte des entrées externes. Les points de terminaison REST décorés avec des annotations JAX-RS exposent l'application à des données fournies par des utilisateurs non fiables, ce qui peut introduire diverses vulnérabilités de sécurité si elles ne sont pas correctement validées et sécurisées. Les paramètres du point de terminaison doivent être considérés comme des sources non fiables nécessitant une analyse de sécurité pour l'authentification, l'autorisation, la validation des entrées, l'application de SSL/TLS et la protection CSRF pour les opérations modifiant l'état.

Remédiation :

Envisagez de mettre en place une stratégie de sécurité globale pour les points de terminaison JAX-RS dans votre application Scala. Il est recommandé de renforcer l'authentification en utilisant des filtres JAX-RS ou des annotations de sécurité comme @RolesAllowed pour vérifier l'identité des utilisateurs avant de traiter les demandes. Implémentez des contrôles d'autorisation pour garantir que les utilisateurs authentifiés disposent des autorisations appropriées pour l'opération demandée. Validez tous les paramètres d'entrée en utilisant des annotations de validation de Bean (JSR-380) telles que @NotNull, @Pattern, ou des validateurs personnalisés pour prévenir les attaques par injection. Utilisez exclusivement HTTPS en configurant votre serveur d'applications pour rediriger le trafic HTTP ou rejeter les connexions non TLS. Pour les points de terminaison qui modifient l'état (méthodes POST, PUT, DELETE), mettez en œuvre une protection CSRF en utilisant des tokens de synchronisation ou des modèles de cookies à double soumission. Envisagez d'utiliser JAX-RS ContainerRequestFilter pour une application centralisée de la sécurité sur plusieurs points de terminaison.

scala_file_rule-FilenameUtils

Résumé :

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

Gravité : Moyenne

CWE : CWE-22

Description :

Une vulnérabilité de traversée de chemin a été détectée en utilisant des méthodes de FilenameUtils. Des fonctions comme FilenameUtils.normalize(), getName(), getBaseName(), getExtension() et isExtension() sont utilisées sur des chemins de fichiers potentiellement contrôlés par l'utilisateur. Sans validation appropriée, les attaquants peuvent utiliser des séquences de traversée de chemin comme ../ pour accéder à des fichiers en dehors du répertoire prévu, pouvant ainsi lire des fichiers de configuration sensibles, des identifiants ou du code source.

Remédiation :

Considérez la possibilité de valider les chemins de fichiers par rapport à une liste blanche de fichiers ou de répertoires autorisés avant d'utiliser les méthodes de FilenameUtils. Il est recommandé de vérifier que le chemin résolu commence par le répertoire de base prévu après normalisation. Rejetez explicitement les chemins contenant des séquences .. ou d'autres tentatives de traversée. Utilisez java.nio.file.Paths.get().normalize().startsWith() pour vérifier que le chemin final reste dans les limites autorisées. Évitez d'utiliser directement les entrées utilisateur dans des opérations sur les fichiers sans validation.

OWASP :

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

scala_inject_rule-LDAPInjection

Résumé :

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

Gravité : Moyenne

CWE : CWE-90

Description :

L'application construit des requêtes LDAP en utilisant des paramètres de chaîne contrôlés par l'utilisateur passés à javax.naming.directory.DirContext, javax.naming.Context, javax.naming.ldap.LdapContext, com.unboundid.ldap.sdk.LDAPConnection, ou aux méthodes de Spring LDAP LdapTemplate incluant lookup(), search(), et list(), ainsi que Properties.put() pour les propriétés de connexion LDAP. Contrairement à SQL, LDAP n'a pas d'interfaces de déclarations préparées, ce qui le rend vulnérable à des attaques par injection où des caractères spéciaux (parenthèses, astérisques, barres obliques inverses) peuvent modifier la logique de la requête pour contourner l'authentification, extraire des données non autorisées, ou élever les privilèges.

Remédiation :

Envisagez d'implémenter une validation stricte des entrées qui autorise uniquement les caractères alphanumériques et les modèles attendus avant d'inclure des données dans les requêtes LDAP. Il est recommandé d'échapper les caractères spéciaux LDAP, y compris les parenthèses (), les astérisques *, les barres obliques inverses \, les octets nuls, et les chevrons en utilisant des fonctions d'encodage appropriées. Pour les applications Java, utilisez Encoder.encodeForLDAP() de l'OWASP ESAPI ou échappez manuellement les caractères spéciaux selon la RFC 4515 pour les chaînes de filtre et la RFC 4514 pour les Noms Distingués. Pour les applications Spring LDAP, utilisez LdapEncoder.nameEncode() et LdapEncoder.filterEncode() pour échapper correctement les entrées. Envisagez d'utiliser des filtres paramétrés avec LdapQueryBuilder de Spring LDAP qui fournit une construction de requêtes plus sûre avec échappement automatique des valeurs fournies par l'utilisateur.

scala_inject_rule-OgnlInjection

Résumé :

Injection d'expressions (OGNL)

Sévérité : Moyenne

CWE : CWE-917

Description :

L'application utilise les API d'évaluation d'expressions OGNL (Object-Graph Navigation Language) d'Apache Struts/XWork2, y compris TextParseUtil, OgnlTextParser, OgnlReflectionProvider, OgnlUtil, StrutsUtil, et ValueStack avec des paramètres String ou Map contrôlés par l'utilisateur provenant des arguments de méthode. Ces API évaluent dynamiquement les expressions OGNL, qui peuvent accéder aux objets Java, invoquer des méthodes et manipuler l'état de l'application. Lorsque des données non fiables sont transmises à ces méthodes d'évaluation d'expressions, des attaquants peuvent injecter une syntaxe OGNL malveillante pour exécuter du code à distance, accéder à des données sensibles ou contourner des contrôles de sécurité par le biais des capacités de réflexion Java.

Remédiation :

Envisagez d'éviter complètement l'évaluation dynamique des expressions OGNL avec les entrées utilisateur - utilisez des expressions statiques et transmettez les données via le contexte ValueStack en tant qu'objets plutôt que sous forme de chaînes d'expressions. Il est recommandé de mettre à jour vers Struts 2.5.x ou version ultérieure, qui inclut des contrôles de sécurité améliorés et des restrictions d'évaluation d'expressions. Pour les applications qui doivent évaluer des expressions dynamiques, implémentez une validation stricte sur liste blanche permettant uniquement les noms de propriétés attendus sans opérateurs OGNL spéciaux ni appels de méthodes. Vous pouvez utiliser les options de configuration de sécurité de Struts telles que struts.ognl.excludedClasses et struts.ognl.excludedPackageNames pour limiter les classes et packages accessibles. Envisagez de migrer vers des architectures alternatives plus sûres comme Spring MVC avec SpEL (qui offre un meilleur confinement) ou des APIs REST avec liaison de données JSON qui évitent entièrement l'évaluation du code.

scala_inject_rule-PathTraversalIn

Résumé :

Limitation inappropriée d'un chemin à un répertoire restreint ('Traversée de chemin')

Sévérité : Moyenne

CWE : CWE-22

Description :

L'application ouvre des fichiers pour lecture en utilisant les API de fichiers Java (java.io.File, FileInputStream, FileReader, RandomAccessFile, java.nio.file.Paths.get(), Files.createTempFile()) et les API de fichiers Scala (scala.io.Source.fromFile(), Source.fromString()) avec des noms de fichiers construits à partir de paramètres de chaîne ou d'arguments de ligne de commande. Lorsque des paramètres non filtrés sont passés à ces API de fichiers, les attaquants peuvent injecter des séquences de traversée de chemin (../, ../../, chemins absolus) pour lire des fichiers à partir de lieux arbitraires du système de fichiers en dehors des répertoires prévus, ce qui peut exposer des données sensibles comme des fichiers de configuration, des identifiants ou le code source de l'application.

Remédiation :

Envisagez d'utiliser org.apache.commons.io.FilenameUtils.getName() pour extraire uniquement le composant du nom de fichier, en supprimant toute information de chemin de répertoire y compris les séquences de traversée. Il est recommandé de valider que les chemins de fichiers se résolvent dans des répertoires attendus en utilisant File.getCanonicalPath() et en comparant avec un préfixe de répertoire de base autorisé. Vous pouvez utiliser java.nio.file.Path.normalize() combiné avec des vérifications startsWith() pour garantir que les chemins résolus restent dans les répertoires autorisés. Mettez en œuvre une validation de liste blanche pour les noms de fichiers ou les modèles autorisés, et refusez les chemins contenant des séparateurs de répertoire (/, ) ou des séquences de traversée (..). Pour les applications Scala, envisagez d'utiliser des modèles d'accès aux fichiers plus sûrs avec des limites de répertoire explicites et des composants de nom de fichier validés plutôt que d'accepter des chaînes de chemin arbitraires de la part des utilisateurs.

OWASP :

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

scala_inject_rule-SqlInjection

Résumé :

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

Sévérité : Moyenne

CWE : CWE-89

Description :

L'application construit des requêtes SQL avec des valeurs dynamiques passées à JDO (PersistenceManager.newQuery(), Query.setFilter()), Hibernate (Session.createQuery(), Session.createSQLQuery(), Restrictions.sqlRestriction()), JDBC (Statement.executeQuery(), Statement.execute(), Statement.executeUpdate(), Connection.prepareStatement()), Spring JDBC (JdbcTemplate, méthodes JdbcOperations), JPA (EntityManager.createQuery(), createNativeQuery()), Vert.x SQL Client, Apache Turbine/Torque, et Anorm (anorm.SQL()) sans utiliser de littéraux de chaîne. Lorsque les requêtes sont construites dynamiquement avec des variables au lieu de paramètres liés, les attaquants peuvent injecter du SQL malveillant pour manipuler la logique de la requête, extraire des données sensibles, modifier des enregistrements ou exécuter des opérations administratives.

Remédiation :

Envisagez d'utiliser des requêtes paramétrées avec des variables liées où les valeurs sont passées séparément de la structure de la commande SQL - pour JDBC, utilisez PreparedStatement avec les méthodes setString(), setInt() plutôt que la concaténation de chaînes. Il est recommandé d'utiliser des bibliothèques de bases de données Scala sûres pour les types comme Slick (validation de requête à la compilation), Doobie (composition de requête fonctionnelle), ou ScalikeJDBC (paramétrisation basée sur l'interpolation) qui empêchent l'injection SQL par conception. Pour les applications Play Framework, utilisez l'interpolation des paramètres d'Anorm avec la syntaxe SQL"SELECT * FROM users WHERE id = $userId" qui lie les paramètres en toute sécurité. Pour les applications Spring, utilisez JdbcTemplate avec des méthodes paramétrées qui acceptent les paramètres liés comme arguments séparés. Pour Hibernate, utilisez des paramètres nommés (:paramName) ou des paramètres positionnels (?) avec Query.setParameter(). Ne concaténez jamais ou n'interpolez directement les données utilisateur dans les chaînes de requête - utilisez toujours les mécanismes de paramétrisation du framework.

OWASP :

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

scala_perm_rule-OverlyPermissiveFilePermissionObj

Résumé :

Attribution de permissions incorrectes pour une ressource critique

Gravité : Moyenne

CWE : CWE-732

Description :

L'ajout des permissions OTHERS_READ, OTHERS_WRITE ou OTHERS_EXECUTE à partir de l'énumération PosixFilePermission à un ensemble de permissions utilisé avec java.nio.file.Files.setPosixFilePermissions() crée des fichiers accessibles au monde entier. Ces permissions OTHERS_* accordent l'accès à tout utilisateur sur le système, et pas seulement au propriétaire du fichier ou aux membres du groupe. Cela peut exposer des données sensibles à des utilisateurs non autorisés, permettre la manipulation de fichiers critiques ou autoriser l'exécution de code malveillant par des utilisateurs non privilégiés, entraînant des divulgations d'informations, des violations de l'intégrité des données ou des attaques par élévation de privilèges.

Remédiation :

Envisagez d'utiliser uniquement les permissions OWNER_ et GROUP_ lors de la création d'ensembles de permissions pour des fichiers sensibles. Il est recommandé d'exclure toutes les permissions OTHERS_ (OTHERS_READ, OTHERS_WRITE, OTHERS_EXECUTE) de vos ensembles de PosixFilePermission. Lors de la création d'ensembles de permissions, utilisez des combinaisons comme Set(OWNER_READ, OWNER_WRITE) pour un accès réservé au propriétaire, ou ajoutez GROUP_READ pour un accès de groupe selon les besoins. Pour les répertoires qui doivent être traversables, envisagez GROUP_EXECUTE au lieu de OTHERS_EXECUTE. Révisez vos exigences en matière de permissions de fichiers et appliquez le principe du moindre privilège en accordant l'accès uniquement aux utilisateurs qui en ont absolument besoin. Envisagez de mettre en œuvre des vérifications de permissions dans votre code pour vérifier que les fichiers créés par votre application n'ont jamais de permissions OTHERS_ définies. Pour les fichiers temporaires, utilisez Files.createTempFile() avec des attributs de fichier appropriés plutôt que de définir manuellement les permissions après la création.

scala_script_rule-SpelView

Résumé :

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

Sévérité : Moyenne

CWE : CWE-94

Description :

Vulnérabilité d'injection détectée dans le langage d'expression Spring (SpEL) lors de l'utilisation de SpelExpressionParser.parseExpression() avec des entrées non littérales. SpEL permet l'exécution de code arbitraire par l'évaluation d'expressions, permettant aux attaquants d'accéder aux propriétés du système, d'invoquer des méthodes et de potentiellement réaliser une exécution de code à distance lorsque des valeurs contrôlées par l'utilisateur sont analysées en tant qu'expressions SpEL.

Remédiation :

Il est conseillé d'éviter complètement l'utilisation d'expressions SpEL dynamiques avec des entrées contrôlées par l'utilisateur, car SpEL offre d'importantes capacités pour l'exécution de code arbitraire. Il est recommandé d'utiliser plutôt des configurations statiques ou des approches basées sur des modèles. Si des expressions dynamiques sont nécessaires, envisagez de mettre en œuvre une validation stricte de la liste blanche qui ne permet que des modèles d'expressions prédéfinis spécifiques, et utilisez SimpleEvaluationContext au lieu de StandardEvaluationContext pour restreindre les fonctionnalités disponibles.

OWASP :

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

scala_ssrf_rule-PlaySSRF

Résumé :

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

Sévérité : Moyenne

CWE : CWE-918

Description :

Cette règle a détecté des entrées contrôlées par l'utilisateur passées à la méthode WSClient.url() du Play Framework sans validation appropriée. Le modèle identifie les cas où des valeurs de chaîne non littérales sont utilisées pour construire des requêtes de services web via l'API client Play WS (Web Services). Lorsque l'entrée de l'utilisateur contrôle le paramètre URL dans les appels ws.url(), des vulnérabilités de falsification de requêtes côté serveur (SSRF) apparaissent, permettant aux attaquants de forcer l'application Play à accéder à des ressources internes, à des points de terminaison de métadonnées cloud (169.254.169.254), à des interfaces administratives, ou d'effectuer des requêtes non autorisées qui contournent la segmentation du réseau et les règles de pare-feu.

Remédiation :

Envisagez de mettre en œuvre une liste blanche stricte des URL qui valide l'entrée utilisateur par rapport à des domaines approuvés avant de passer des URL à WSClient.url(). Utilisez java.net.URI de Scala ou les utilitaires d'URL de Play pour analyser et valider les composants de schéma, hôte et port, rejetant toute URL qui ne correspond pas à la liste blanche. Implémentez une protection contre le rebinding DNS en résolvant les noms d'hôte et en bloquant les connexions vers des plages 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). Pour les applications Play, configurez un WSClientConfig personnalisé avec des filtres de requêtes ou des intercepteurs qui appliquent la validation des URL au niveau du client HTTP. Les défenses au niveau réseau peuvent inclure l'exécution de l'application Play dans des environnements conteneurisés avec des règles de filtrage sortant qui empêchent les connexions vers des réseaux internes. Envisagez d'utiliser une approche de mapping côté serveur où l'entrée utilisateur fournit des clés qui correspondent à des URL sûres préconfigurées plutôt que d'accepter des URL arbitraires.

scala_strings_rule-BadHexConversion

Résumé :

Conversion ou cast de type incorrect

Gravité : Moyenne

CWE : CWE-704

Description :

Lors de la conversion d'un tableau d'octets provenant de java.security.MessageDigest.digest() en une chaîne hexadécimale en utilisant Integer.toHexString() dans une boucle, les valeurs d'octets comprises entre 0x00 et 0x0F seront incorrectement converties en chaînes à un caractère (par exemple, "a" au lieu de "0a"), produisant des représentations de hachage non valides. Cela se produit parce que Integer.toHexString() ne remplit pas les zéros, entraînant des chaînes de hachage tronquées ou mal formées qui échoueront aux vérifications de validation ou de comparaison dans des opérations critiques pour la sécurité.

Remédiation :

Envisagez d'utiliser String.format("%02x", byteValue) ou "%02x".format(byteValue) en Scala pour garantir que chaque octet est représenté de manière cohérente comme une chaîne hexadécimale à deux caractères avec un remplissage zéro à gauche. Alternativement, pour de meilleures performances et un code plus propre, il est recommandé d'utiliser des bibliothèques telles que Hex.encodeHexString(byteArray) d'Apache Commons Codec ou BaseEncoding.base16().lowerCase().encode(byteArray) de Guava, qui gèrent la conversion correctement et efficacement. Ces méthodes de bibliothèque évitent l'itération manuelle et la logique de remplissage, réduisant ainsi le risque d'erreurs d'implémentation dans la génération de chaînes de hachage sensibles à la sécurité.

scala_strings_rule-ImproperUnicode

Résumé :

Mauvaise gestion de l'encodage Unicode

Gravité : Moyenne

CWE : CWE-176

Description :

Les transformations de chaînes utilisant String.toLowerCase() ou String.toUpperCase() suivies de méthodes de comparaison telles que equals(), equalsIgnoreCase() ou indexOf(), ainsi que l'utilisation directe de java.text.Normalizer.normalize(), java.net.IDN.toASCII() ou URI.toASCIIString() peuvent conduire à une mauvaise gestion de l'encodage Unicode. Les transformations de cas et la normalisation peuvent produire des correspondances de caractères inattendues, en particulier avec la locale turque où 'i' et 'I' ont des mappages majuscules/minuscules différents, ou avec des formes de normalisation Unicode qui peuvent combiner ou décomposer des caractères dans des contextes sensibles à la sécurité comme les contournements de validation.

Remédiation :

Envisagez d'utiliser des méthodes de comparaison sensibles à la locale ou de spécifier explicitement Locale.ROOT lors des transformations de cas pour éviter les problèmes de mappage de caractères spécifiques à la locale. Pour des comparaisons insensibles à la casse, il est recommandé d'utiliser String.equalsIgnoreCase() directement au lieu de transformer et de comparer, ou d'utiliser Collator avec des réglages de force appropriés pour des scénarios plus complexes. Lors de l'utilisation de la normalisation Unicode pour la validation de sécurité, assurez-vous que la normalisation est appliquée de manière cohérente avant et après les vérifications de validation pour prévenir les contournements via des astuces de composition de caractères. Pour les noms de domaine internationalisés, validez que la sortie de IDN.toASCII() est utilisée de manière cohérente tout au long de la frontière de sécurité, et soyez conscient des attaques homographes où des caractères visuellement similaires provenant de différents scripts peuvent être utilisés pour créer des noms de domaine trompeurs.

scala_xml_rule-SAMLIgnoreComments

Résumé :

Authentification faible

Sévérité : Moyenne

CWE : CWE-1390

Description :

Définir setIgnoreComments(false) sur BasicParserPool lors du traitement des assertions SAML entraîne la préservation des commentaires par le parseur XML pendant la canonicalisation, ce qui peut mener à des vulnérabilités d'esquive d'authentification. Les attaquants peuvent injecter du contenu malveillant dans les commentaires XML qui est traité lors de la vérification de la signature mais interprété différemment lors de l'authentification réelle, leur permettant de contourner les contrôles de sécurité et d'usurper l'identité d'utilisateurs légitimes.

Remédiation :

Envisagez d'utiliser setIgnoreComments(true) lors de la configuration de BasicParserPool pour le traitement SAML afin de vous assurer que les commentaires XML sont supprimés avant la vérification de la signature. C'est la configuration sécurisée recommandée par défaut dans les implémentations OpenSAML et cela prévient les attaques par enveloppement de signature basées sur les commentaires. Lors de l'initialisation du pool de parseurs SAML, il est recommandé d'utiliser StaticBasicParserPool avec des paramètres de sécurité explicites, y compris l'ignorance des commentaires activée, ou d'utiliser le motif BasicParserPool.builder() pour s'assurer que tous les paramètres pertinents en matière de sécurité sont correctement configurés. De plus, assurez-vous que votre implémentation SAML valide les signatures après la canonicalisation pour prévenir d'autres formes d'attaques par enveloppement de signature XML.

scala_xpathi_rule-XpathInjection

Résumé :

Restriction inadéquate de la référence à l'entité externe XML ('XXE')

Sévérité : Moyenne

CWE : CWE-611

Description :

Des données non fiables sont utilisées dans des expressions XPath via XPath.compile() ou XPath.evaluate() sans une sanitation appropriée. Cela permet aux attaquants de manipuler les requêtes XPath pour accéder à des données XML non autorisées ou contourner les contrôles d'accès, exposant potentiellement des informations sensibles.

Remédiation :

Évitez de construire des expressions XPath directement à partir des entrées utilisateur. Envisagez plutôt d'utiliser des requêtes XPath paramétrées avec XPathVariableResolver pour lier en toute sécurité des valeurs contrôlées par l'utilisateur. Cela empêche les attaquants d'injecter une syntaxe XPath malveillante. Si la paramétrisation n'est pas réalisable, mettez en œuvre une validation stricte des entrées en utilisant des listes d'autorisation pour les valeurs attendues et échappez les caractères XPath spéciaux avant leur inclusion dans les requêtes.

scala_xss_rule-RequestWrapper

Résumé :

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

Sévérité : Moyenne

CWE : CWE-79

Description :

L'application implémente une fonction de filtrage XSS personnalisée stripXSS() au sein d'une classe HttpServletRequestWrapper personnalisée en Scala. Les filtres XSS personnalisés sont notoirement difficiles à mettre en œuvre correctement et contiennent souvent des failles dues à des correspondances de motifs incomplètes, des problèmes d'encodage, ou un manque de prise en compte de tous les vecteurs d'injection. Les attaquants découvrent fréquemment des moyens de contourner les assainissements réalisés en interne par des astuces d'encodage, des jeux de caractères inhabituels, des comportements de parsing spécifiques aux navigateurs, ou des mutations basées sur le DOM. De plus, les filtres personnalisés peuvent interférer avec des données légitimes ou créer des faux positifs, tout en manquant toujours de détecter de réelles attaques en raison de la complexité des contextes de parsing HTML et JavaScript.

Remédiation :

Envisagez de supprimer la logique de filtrage XSS personnalisée et utilisez plutôt un encodage de sortie conscient du contexte au moment où les données sont rendues dans les modèles. Pour les applications Scala, utilisez les fonctions spécifiques au contexte de la bibliothèque OWASP Java Encoder comme Encode.forHtml(), Encode.forJavaScript(), ou Encode.forHtmlAttribute() lors de l'affichage des données utilisateur. Si vous utilisez Play Framework, reposez-vous sur l'auto-évasion des modèles Twirl qui gère correctement le contexte. Pour le contenu riche nécessitant du HTML, utilisez un assainisseur basé sur une liste blanche comme OWASP Java HTML Sanitizer avec une liste d'autorisation stricte des balises et attributs permis. La validation des entrées doit se concentrer sur les contraintes de logique métier, et non sur le filtrage de sécurité. Implémentez des en-têtes de Politique de Sécurité du Contenu (CSP) pour fournir une protection en profondeur même si l'encodage de sortie est omis à certains endroits.

scala_xss_rule-WicketXSS

Résumé :

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

Sévérité : Moyenne

CWE : CWE-79

Description :

L'application désactive l'échappement HTML intégré d'Apache Wicket en appelant setEscapeModelStrings(false) sur les composants Wicket Label dans le code Scala. Cela crée une vulnérabilité de type Cross-Site Scripting (XSS) lorsque le Label affiche des données fournies par l'utilisateur, car un JavaScript ou un balisage HTML malveillant sera rendu directement dans le navigateur sans sanitisation. L'échappement automatique par défaut de Wicket protège contre le XSS en encodant les caractères spéciaux HTML dans les composants Label, et désactiver explicitement cette protection supprime un contrôle de sécurité critique. Cela est particulièrement dangereux dans les applications Scala où la sécurité de type peut créer un faux sentiment de sécurité, car le contournement de l'échappement permet l'injection de chaînes indépendamment des vérifications de type.

Remédiation :

Envisagez de garder l'échappement automatique par défaut de Wicket activé en vous assurant que setEscapeModelStrings(true) est appelé ou en vous appuyant sur le comportement par défaut de Wicket qui échappe automatiquement le HTML. Si vous devez rendre du contenu HTML riche provenant de sources dignes de confiance, envisagez d'utiliser le composant Label de Wicket avec une validation explicite du modèle plutôt que de désactiver l'échappement globalement. Pour le contenu généré par les utilisateurs qui doit inclure un formatage, utilisez une bibliothèque de sanitisation HTML basée sur une liste blanche comme OWASP Java HTML Sanitizer ou Jsoup avec une liste d'autorisation restrictive avant de transmettre le contenu aux composants Wicket Label. De plus, mettez en œuvre des en-têtes de Politique de Sécurité de Contenu (CSP) pour fournir une défense en profondeur contre le XSS, même si l'échappement est contourné. Consultez la documentation de l'API des composants Wicket à l'adresse https://nightlies.apache.org/wicket/apidocs/9.x/org/apache/wicket/Component.html pour un usage approprié des fonctionnalités d'échappement dans les applications Scala.

scala_xss_rule-XSSReqParamToServletWriter

Résumé :

Neutralisation incorrecte des entrées lors de la génération de pages Web

Sévérité : Moyenne

CWE : CWE-79

Description :

L'application écrit les données fournies par les utilisateurs à partir des paramètres de requête HTTP directement dans la réponse HTTP via HttpServletResponse.getWriter().write() ou .print() dans le code des servlets Scala. Cela crée une vulnérabilité de type Cross-Site Scripting (XSS) réfléchie où les attaquants peuvent injecter du JavaScript malveillant en façonnant des paramètres de requête obtenus via HttpServletRequest.getParameter() ou getQueryString() qui sont renvoyés dans la réponse HTTP sans encodage HTML. Sans encodage de sortie approprié, des scripts malveillants intégrés dans les paramètres de requête s'exécuteront dans les navigateurs des victimes, pouvant mener à un détournement de session, un vol de crédentiels ou des attaques de défiguration dans des applications Web basées sur Scala.

Remédiation :

Envisagez d'utiliser la fonction Encode.forHtml() de la bibliothèque OWASP Java Encoder pour échapper les entrées utilisateur avant d'écrire dans la réponse du servlet dans le code Scala. Si vous écrivez des réponses en texte brut, définissez le Content-Type sur text/plain avec response.setContentType("text/plain; charset=UTF-8") pour empêcher les navigateurs d'interpréter la sortie comme du HTML. Pour les applications Web Scala modernes, il est préférable d'utiliser des frameworks comme Play Framework avec des modèles Twirl ou Scalatra avec des modèles SSP/Scaml, qui fournissent un échappement contextuel automatique au lieu d'écrire manuellement dans les flux de sortie des servlets. Pour les contextes JavaScript, CSS ou URL, utilisez des fonctions d'encodage spécialisées de l'OWASP Java Encoder (Encode.forJavaScript(), Encode.forCssString(), Encode.forUriComponent()). Implémentez des en-têtes de politique de sécurité de contenu (CSP) comme couche de défense supplémentaire contre les attaques XSS.

scala_xxe_rule-Document

Résumé :

Restriction Inappropriée de la Référence d'Entité Externe XML ('XXE')

Gravité : Moyenne

CWE : CWE-611

Description :

L'application utilise DocumentBuilderFactory.newInstance() pour créer un parseur DOM sans désactiver le traitement des entités externes, ce qui la rend vulnérable aux attaques par Entité Externe XML (XXE). Lorsque le DocumentBuilder traite des entrées XML non fiables avec le support des entités externes activé, les attaquants peuvent en profiter pour lire des fichiers arbitraires depuis le système de fichiers, effectuer des attaques SSRF contre des ressources réseau internes, exfiltrer des données sensibles par des canaux hors bande, ou provoquer un déni de service par des attaques de milliard de rires et d'expansion d'entités.

Remédiation :

Configurez le DocumentBuilderFactory pour désactiver complètement les déclarations DOCTYPE en appelant setFeature("http://apache.org/xml/features/disallow-doctype-decl", true) avant de créer le parseur. Cela empêche toutes les vulnérabilités XXE, les attaques par expansion d'entités et le déni de service par milliard de rires en bloquant complètement le traitement des DTD. Alternativement, activez XMLConstants.FEATURE_SECURE_PROCESSING pour des restrictions de sécurité supplémentaires. Exemple : val factory = DocumentBuilderFactory.newInstance; factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); val builder = factory.newDocumentBuilder; builder.parse(inputStream); Conseils supplémentaires disponibles sur
https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#java

scala_xxe_rule-Trans

Résumé :

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

Gravité : Moyenne

CWE : CWE-611

Description :

L'application utilise TransformerFactory.newTransformer() pour créer un transformateur XSLT sans désactiver le traitement des entités externes, la rendant vulnérable aux attaques par entité externe XML (XXE). Lorsque le transformateur traite des entrées XML ou XSLT non fiables avec l'accès aux entités externes et DTD activé, les attaquants peuvent exploiter cela pour lire des fichiers arbitraires, effectuer des attaques SSRF sur des systèmes internes, exfiltrer des données via des références d'entités externes ou provoquer un déni de service par expansion d'entités et attaques "billion laughs".

Remédiation :

Configurez le transformateur pour désactiver l'accès externe aux DTD et aux schémas en définissant setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, "") et setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "") sur le TransformerFactory avant de créer le transformateur. De plus, activez setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true) pour des restrictions de sécurité complètes. Cela prévient les attaques XXE, les vulnérabilités SSRF et les dénis de service par expansion d'entités. Exemple : val factory = TransformerFactory.newInstance; factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, ""); factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); val transformer = factory.newTransformer; Voir https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#java

scala_xxe_rule-XMLRdr

Résumé :

Restriction incorrecte de la référence XML External Entity ('XXE')

Sévérité : Moyenne

CWE : CWE-611

Description :

L'application utilise XMLReaderFactory.createXMLReader() pour créer un parseur XML sans désactiver le traitement des entités externes, ce qui la rend vulnérable aux attaques XML External Entity (XXE). Lorsque l'XMLReader traite des entrées XML non fiables avec le support des entités externes activé, les attaquants peuvent en profiter pour lire des fichiers arbitraires du système de fichiers, mener des attaques SSRF contre des services réseau internes, exfiltrer des données sensibles ou provoquer des attaques par déni de service (DoS) grâce à des attaques par expansion d'entités. La classe XMLReaderFactory est obsolète et manque d'options de configuration de sécurité modernes.

Remédiation :

Migrer vers SAXParserFactory au lieu de l'obsolète XMLReaderFactory et le configurer pour désactiver les déclarations DOCTYPE en utilisant setFeature("http://apache.org/xml/features/disallow-doctype-decl", true). Cela empêche les attaques XXE, les vulnérabilités par expansion d'entités et les attaques DoS par billion laughs en bloquant complètement le traitement DTD. Alternativement, activez XMLConstants.FEATURE_SECURE_PROCESSING pour des restrictions de sécurité complètes. Exemple : val factory = SAXParserFactory.newInstance; factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); val parser = factory.newSAXParser; parser.parse(inputStream, handler); Voir https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#java

scala_xxe_rule-XMLStreamRdr

Résumé :

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

Sévérité : Moyenne

CWE : CWE-611

Description :

L'application utilise XMLInputFactory.newFactory() et createXMLStreamReader() pour créer un parseur XML StAX sans désactiver le traitement des entités externes, la rendant vulnérable aux attaques par entité externe XML (XXE). Lorsque le XMLStreamReader traite des entrées XML non fiables avec prise en charge DTD et entités externes activées, les attaquants peuvent en tirer parti pour lire des fichiers arbitraires, effectuer des attaques SSRF vers des systèmes internes, exfiltrer des données via des références DTD externes, ou provoquer un déni de service par des attaques de billion laughs et d'expansion d'entités de soufflage quadratique.

Remédiation :

Configurer le XMLInputFactory pour désactiver à la fois le support DTD et les entités externes avant de créer le lecteur de flux en définissant setProperty(XMLInputFactory.SUPPORT_DTD, false) et setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false). Désactiver le support DTD empêche les attaques XXE, les vulnérabilités d'expansion d'entité et le déni de service de billion laughs en bloquant tout traitement DTD. Exemple : val factory = XMLInputFactory.newFactory; factory.setProperty(XMLInputFactory.SUPPORT_DTD, false); factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false); val reader = factory.createXMLStreamReader(inputStream); Informations complémentaires sur https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#java

scala_xxe_rule-XPathXXE

Résumé :

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

Gravité : Moyenne

CWE : CWE-611

Description :

L'application utilise DocumentBuilderFactory.newInstance() et newDocumentBuilder() pour créer un parseur DOM pour l'évaluation XPath sans désactiver le traitement des entités externes, ce qui la rend vulnérable aux attaques d'entité externe XML (XXE). Lorsque des expressions XPath sont évaluées sur des documents DOM analysés à partir d'une entrée XML non fiable avec le support des entités externes activé, des attaquants peuvent en profiter pour lire des fichiers arbitraires, réaliser des attaques SSRF contre des systèmes internes, exfiltrer des données ou provoquer un déni de service par des attaques d'expansion d'entité.

Remédiation :

Configurer le DocumentBuilderFactory pour désactiver l'accès aux DTD et schémas externes avant de créer le constructeur de document en appelant setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, ""), setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""), et setFeature("http://apache.org/xml/features/disallow-doctype-decl", true). Cela prévient les attaques XXE, les vulnérabilités d'expansion d'entité, et les dénis de service "billion laughs" en bloquant tout traitement d'entité externe et les déclarations DTD. Exemple : val factory = DocumentBuilderFactory.newInstance; factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, ""); factory.setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); val builder = factory.newDocumentBuilder; val doc = builder.parse(inputStream); Voir https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#java

Résumé :

Cookie sensible sans le drapeau 'HttpOnly'

Gravité : Faible

CWE : CWE-1004

Description :

L'application crée une instance de javax.servlet.http.Cookie sans appeler setHttpOnly(true) ou la définit explicitement sur false avec setHttpOnly(false), ce qui rend le cookie accessible au code JavaScript côté client. Cela expose des données de cookie sensibles à des attaques Cross-Site Scripting (XSS), où des scripts malveillants injectés dans la page peuvent lire des identifiants de session et d'autres informations sensibles. Sans le drapeau HttpOnly, les attaquants qui exploitent avec succès des vulnérabilités XSS peuvent voler des sessions utilisateurs et usurper l'identité des utilisateurs légitimes.

Remédiation :

Appelez toujours setHttpOnly(true) sur les instances de javax.servlet.http.Cookie avant de les ajouter à la réponse avec addCookie(). Cela empêche les scripts côté client d'accéder au cookie via document.cookie, réduisant ainsi considérablement le risque de détournement de session via des attaques XSS. Pour les applications Play Framework, utilisez le paramètre httpOnly = true lors de la création de cookies avec le constructeur Cookie() ou définissez-le dans application.conf avec play.http.session.httpOnly = true pour les cookies de session. Envisagez également d'activer le drapeau Secure avec setSecure(true) pour garantir que les cookies sont uniquement transmis via HTTPS, et mettez en œuvre l'attribut SameSite en utilisant cookie.setAttribute("SameSite", "Strict") pour fournir une protection supplémentaire contre les CSRF.

Résumé :

Exposition d'informations via des cookies persistants

Sévérité : Faible

CWE : CWE-539

Description :

L'application crée une instance de javax.servlet.http.Cookie sans appeler setSecure(true) ou la définit explicitement sur false avec setSecure(false), ce qui permet au cookie d'être transmis sur des connexions HTTP non cryptées. Cela expose des données sensibles des cookies à des attaques basées sur le réseau, telles que l'interception de l'homme du milieu (MITM), où des attaquants sur le même réseau peuvent capturer des jetons de session et d'autres informations confidentielles. Sans le drapeau Secure, toute requête HTTP vers le domaine inclura le cookie en texte clair, le rendant vulnérable à l'écoute, même si HTTPS est disponible.

Remédiation :

Appelez toujours setSecure(true) sur les instances de javax.servlet.http.Cookie pour garantir que les cookies ne sont transmis que sur des connexions HTTPS chiffrées. Cela protège les données sensibles contre l'interception réseau et les attaques MITM. Pour les applications Play Framework, configurez des cookies sécurisés globalement dans application.conf avec play.http.session.secure = true ou utilisez le paramètre secure = true dans le constructeur Cookie(). Envisagez également d'activer les en-têtes HSTS (HTTP Strict Transport Security) pour forcer toutes les connexions à utiliser HTTPS. De plus, implémentez le drapeau HttpOnly avec setHttpOnly(true) et l'attribut SameSite en utilisant cookie.setAttribute("SameSite", "Strict") pour une sécurité complète des cookies.

scala_cors_rule-PermissiveCORSInjection

Résumé :

Politique Inter-domaines permissive avec des domaines non fiables

Gravité : Faible

CWE : CWE-942

Description :

Une entrée contrôlée par l'utilisateur est utilisée pour définir l'en-tête CORS Access-Control-Allow-Origin sans validation. Cela permet aux attaquants de contourner les protections de la politique de même origine, permettant ainsi à des sites Web malveillants de faire des requêtes inter-domaines authentifiées et de voler des données sensibles de votre application.

Remède :

Évitez de définir l'en-tête Access-Control-Allow-Origin en utilisant des entrées non fiables directement à partir des paramètres de la requête. À la place, maintenez une liste d'autorisation statique de domaines fiables et validez les requêtes d'origine entrantes par rapport à cette liste avant de définir l'en-tête. Si l'origine correspond à un domaine autorisé, définissez l'en-tête sur cette origine spécifique. Ne réfléchissez jamais l'entrée utilisateur directement et n'utilisez pas de jokers trop permissifs comme "*" lorsqu'il s'agit de credentials.

scala_inject_rule-CustomInjection

Résumé :

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

Sévérité : Faible

CWE : CWE-89

Description :

L'application utilise java.sql.Statement.executeQuery() avec des requêtes SQL construites par concaténation de chaînes, mise en forme de chaînes avec String.format(), ou StringBuilder.toString(), ce qui rend le code vulnérable aux attaques par injection SQL. Lorsque des variables contrôlées par l'utilisateur sont concaténées directement dans des chaînes de requête SQL sans paramétrisation, les attaquants peuvent injecter des fragments SQL malveillants pour manipuler la logique de requête, extraire des données sensibles, modifier ou supprimer des enregistrements, ou dans certains cas exécuter des commandes système via des fonctionnalités spécifiques à la base de données.

Remédiation :

Envisagez de migrer vers java.sql.PreparedStatement avec des requêtes paramétrées utilisant la syntaxe de remplacement (?) où les entrées utilisateur sont liées comme paramètres plutôt que concaténées dans des chaînes de requête. Il est recommandé d'utiliser des bibliothèques de base de données Scala comme Slick ou Doobie qui fournissent une construction de requête vérifiée à la compilation et sûre sur le plan des types, ce qui prévient les injections SQL par défaut. Pour les applications Play Framework, utilisez Anorm avec interpolation de paramètres ou les API d'accès à la base de données intégrées qui imposent la paramétrisation. Ne construisez jamais de SQL par concaténation de chaînes ou mise en forme - utilisez toujours le liaison de paramètres où les valeurs sont correctement échappées par le pilote de base de données. Si la construction dynamique de requêtes est inévitable, validez les entrées contre des listes blanches strictes et utilisez des guillemets d'identifiant, mais les requêtes paramétrées restent la solution préférée.

scala_ssrf_rule-SSRF

Résumé :

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

Sévérité : Faible

CWE : CWE-918

Description :

Cette règle a détecté des entrées contrôlées par l'utilisateur utilisées pour construire des connexions réseau Scala via java.net.URL, java.net.URI ou java.net.InetSocketAddress sans validation appropriée. Les modèles identifient les cas où des valeurs non-littérales sont passées aux constructeurs comme new URL(), new URI() ou new InetSocketAddress(), suivis de méthodes telles que connect(), openConnection(), openStream() ou getContent(). Lorsque l'entrée utilisateur contrôle les URLs ou les noms d'hôtes dans ces opérations réseau, des vulnérabilités de falsification de requêtes côté serveur (SSRF) émergent, permettant aux attaquants de forcer le serveur à accéder à des ressources internes, des points de terminaison de métadonnées cloud (169.254.169.254), des interfaces administratives, ou d'effectuer une analyse réseau qui contourne les protections du pare-feu et la segmentation du réseau.

Remédiation :

Envisagez de mettre en œuvre une liste blanche stricte d'URLs qui valide les entrées utilisateur par rapport aux domaines approuvés avant de construire des objets URL ou URI. Utilisez la classe java.net.URI de Scala pour analyser et valider les composants de schéma, d'hôte et de port, en rejetant toute URL ne correspondant pas à la liste blanche. Mettez en œuvre une protection contre le rebinding DNS en résolvant les noms d'hôtes avec InetAddress.getByName() et en bloquant les connexions vers des plages IP privées (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) et les adresses de métadonnées cloud (169.254.169.254). Pour les applications Scala utilisant Akka HTTP ou d'autres clients HTTP, configurez des pools de connexions personnalisés ou des paramètres clients qui imposent un filtrage des adresses IP au niveau du réseau. Les défenses au niveau du réseau peuvent inclure l'exécution de l'application dans des segments de réseau isolés avec des règles de filtrage de sortie. Envisagez d'utiliser une approche de mappage côté serveur où les entrées utilisateur fournissent des clés qui correspondent à des URLs sûres préconfigurées plutôt que d'accepter des URLs arbitraires.

scala_unsafe_rule-InformationExposure

Résumé :

Exposition d'information par un message d'erreur

Sévérité : Faible

CWE : CWE-209

Description :

Une exposition d'information à travers des traces de pile d'exception a été détectée. L'appel à Exception.printStackTrace() génère des informations de débogage détaillées, y compris des noms de classes, des noms de méthodes, des numéros de ligne et des chemins de fichiers sur l'erreur standard ou d'autres flux. Cela expose la structure interne de l'application, les chemins d'installation et les détails d'implémentation que les attaquants peuvent utiliser pour identifier des vulnérabilités, planifier des attaques ciblées ou acquérir des connaissances sur l'architecture du système. Les traces de pile peuvent également révéler involontairement des données sensibles présentes dans les messages d'exception ou les noms de variables.

Remédiation :

Envisagez de remplacer les appels à printStackTrace() par des mécanismes de journalisation appropriés en utilisant des frameworks comme Logback, SLF4J ou Scala Logging. Il est recommandé de consigner les exceptions à des niveaux appropriés (ERREUR, AVERTISSEMENT) avec des informations contextuelles tout en excluant les traces de pile de la sortie en production. Envisagez de mettre en œuvre une journalisation structurée qui capture les détails des exceptions en toute sécurité sans les exposer aux utilisateurs finaux ou aux parties non fiables. Dans les environnements de production, configurez les journaux pour écrire des traces de pile complètes dans des fichiers de log sécurisés accessibles uniquement au personnel autorisé, tout en présentant des messages d'erreur génériques aux utilisateurs. Envisagez d'utiliser des services de suivi des erreurs qui agrègent les exceptions en toute sécurité sans exposer les détails à travers la sortie de l'application. Il est recommandé de mettre en œuvre un traitement des erreurs distinct pour les environnements de développement et de production en utilisant des approches basées sur la configuration.

Résumé :

Cookie sensible dans la session HTTPS sans attribut 'Secure'

Gravité : Info

CWE : CWE-614

Description :

L'application appelle setMaxAge() sur une instance de Cookie avec une valeur de 31 536 000 secondes (un an) ou plus, créant un cookie persistant à longue durée de vie qui reste sur le système client pendant une période prolongée. Stocker des données sensibles dans des cookies persistants avec de telles durées de vie augmente la fenêtre d'opportunité pour les attaquants de compromettre les données par divers vecteurs d'attaque, y compris XSS, logiciels malveillants ou accès physique à l'appareil. Plus un cookie persiste longtemps, plus le risque qu'il soit exposé par le vol d'appareil, l'utilisation partagée de l'ordinateur ou les attaques de vol de cookies est élevé.

Remédiation :

Envisagez d'utiliser des cookies de session (en omettant setMaxAge() ou en le réglant sur -1) pour les données sensibles afin qu'ils expirent lorsque le navigateur se ferme, ou définissez des temps d'expiration significativement plus courts en fonction de vos exigences de sécurité. Pour les cookies d'authentification, les âges maximaux recommandés varient de 15 à 30 minutes pour les applications à haute sécurité à quelques heures pour les applications standards. Ne stockez jamais d'informations sensibles telles que des mots de passe, des numéros de carte de crédit ou des informations personnelles identifiables directement dans des cookies, quel que soit le temps d'expiration. Au lieu de cela, stockez uniquement des identifiants de session dans des cookies et conservez les données sensibles côté serveur. Pour Play Framework, configurez le délai d'expiration de la session dans application.conf avec play.http.session.maxAge pour contrôler la durée par défaut de la session.

Résumé :

Cookie sensible dans une session HTTPS sans attribut 'Secure'

Gravité : Info

CWE : CWE-614

Description :

L'application lit les données des cookies en utilisant des méthodes comme Cookie.getName(), Cookie.getValue(), ou Cookie.getPath() sur les résultats de HttpServletRequest.getCookies(), ce qui peut exposer des informations sensibles si elles sont mal stockées dans les cookies. Les cookies personnalisés ne doivent jamais contenir de données sensibles telles que des mots de passe, des jetons d'authentification, des informations personnellement identifiables ou l'état de session, car les cookies sont stockés côté client et vulnérables au vol via des attaques XSS, des logiciels malveillants ou une interception de réseau. Lire et faire confiance aux valeurs des cookies sans validation appropriée peut entraîner des vulnérabilités de sécurité si les données des cookies ont été altérées par un attaquant.

Remédiation :

Stockez uniquement des identifiants de session dans les cookies et gardez toutes les données sensibles côté serveur dans le magasin de sessions ou la base de données. Utilisez la gestion de session de framework comme HttpSession.setAttribute() pour stocker en toute sécurité des données spécifiques à l'utilisateur. Pour les applications Play Framework, utilisez l'API de session intégrée avec des cookies de session chiffrés via request.session pour stocker un minimum de données. Si vous devez utiliser des cookies personnalisés pour des préférences non sensibles ou l'état de l'interface utilisateur, assurez-vous qu'ils sont correctement validés et assainis avant utilisation. Envisagez d'implémenter des cookies signés ou chiffrés en utilisant session.sign() de Play ou les utilitaires de cookies de Spring Security pour détecter toute tentative de falsification. Considérez toujours les données des cookies comme des entrées utilisateur non fiables et validez-les par rapport aux formats et valeurs attendus avant de prendre des décisions de sécurité.

Résumé :

Neutralisation inadéquate des séquences CRLF dans les en-têtes HTTP ('HTTP Response Splitting')

Gravité : Info

CWE : CWE-113

Description :

L'application construit un javax.servlet.http.Cookie en utilisant des données non fiables provenant de HttpServletRequest.getParameter() ou définit les valeurs de cookie avec Cookie.setValue() en utilisant des paramètres de requête sans une sanitation appropriée des CRLF. Lorsque des entrées contrôlées par l'utilisateur contenant des caractères de retour chariot et de saut de ligne sont utilisées pour créer ou modifier des cookies, des attaquants peuvent injecter des en-têtes HTTP arbitrés par le biais d'attaques de séparation de réponse. Cette vulnérabilité permet aux attaquants de réaliser un empoisonnement de cache, d'injecter des cookies malveillants, de rediriger les utilisateurs vers des sites de phishing ou d'exécuter des attaques par script intersites en contrôlant la structure de la réponse HTTP.

Remédiation :

Ne jamais utiliser directement les paramètres de requête pour construire des valeurs de cookie sans validation stricte et sanitisation. Supprimez tous les caractères CRLF en utilisant replaceAll("[\r\n]", "") avant de définir les valeurs de cookie, ou utilisez l'encodage URL avec java.net.URLEncoder.encode(value, "UTF-8") pour neutraliser les caractères spéciaux. Envisagez d'utiliser la méthode Encode.forUriComponent() de la bibliothèque OWASP Java Encoder qui offre une protection complète contre les attaques par injection. Validez les entrées par rapport à une liste blanche stricte de caractères attendus plutôt que d'essayer de filtrer les modèles malveillants. Pour Play Framework, tirez parti de la gestion sécurisée des sessions du framework au lieu de créer des cookies à partir de paramètres de requête bruts. De plus, mettez en œuvre des en-têtes de Politique de Sécurité du Contenu et utilisez la protection CSRF fournie par le framework pour ajouter une défense en profondeur.

Résumé :

Violation de la frontière de confiance

Gravité : Info

CWE : CWE-501

Description :

L'application appelle HttpServletRequest.setAttribute() ou HttpSession.putValue() avec des valeurs non littérales, mélangeant potentiellement les entrées non fiables des utilisateurs avec les données d'application fiables dans le même contexte de session ou de requête. Cela crée une violation de la frontière de confiance où les données passent du côté non fiable du client vers le côté fiable du serveur sans validation ou distinction appropriées. Lorsque des données non fiables et fiables sont stockées ensemble dans des attributs de session sans séparation claire, les développeurs peuvent, par erreur, faire confiance aux entrées non validées des utilisateurs dans des opérations critiques pour la sécurité, menant à un contournement d'autorisation, une élévation de privilèges ou des vulnérabilités d'injection.

Remédiation :

Validez et assainissez toujours les entrées des utilisateurs avant de les stocker dans des attributs de session ou de requête, et maintenez une séparation claire entre les données fiables et non fiables. Utilisez des conventions de nommage distinctes, comme préfixer les attributs de données non fiables avec "user_" ou "untrusted_", pour rendre la frontière de confiance explicite. Envisagez de créer des objets de transfert de données (DTO) séparés pour les données validées et non validées plutôt que de les mélanger dans le même contexte de session. Pour les applications Play Framework, tirez parti des mécanismes de validation des formulaires et de liaison des données du framework pour garantir que les données sont validées avant le stockage. Implémentez une validation côté serveur pour toutes les entrées des utilisateurs en utilisant des bibliothèques comme Hibernate Validator ou une logique de validation personnalisée. Ne prenez jamais de décisions de sécurité basées uniquement sur des attributs de session qui pourraient avoir été dérivés d'entrées utilisateur sans avoir re-validé les données au moment de l'utilisation.

scala_cors_rule-PermissiveCORS

Résumé :

Politique Cross-domain permissive avec des domaines non fiables

Gravité : Info

CWE : CWE-942

Description :

Une politique de partage de ressources d'origine croisée (CORS) permissive a été détectée. L'en-tête Access-Control-Allow-Origin est défini sur un caractère générique (*), null, ou reflète les entrées non fiables de l'utilisateur. Cela permet aux sites web malveillants d'effectuer des requêtes cross-origin vers cette application en utilisant les identifiants d'une victime, ce qui peut mener à des vols de données, du spoofing et d'autres attaques.

Remédiation :

Envisagez d'utiliser une liste blanche statique de domaines de confiance au lieu d'un caractère générique (*), null, ou de refléter l'origine de la requête dans l'en-tête Access-Control-Allow-Origin. Il est recommandé de valider l'origine par rapport à un ensemble prédéfini de domaines autorisés (par exemple, example.com, trusted.com) avant de définir l'en-tête. Ne jamais utiliser de caractère générique avec des identifiants, car Access-Control-Allow-Credentials: true combiné avec Access-Control-Allow-Origin: * est rejeté par les navigateurs.

scala_crypto_rule-DefaultHTTPClient

Résumé :

Force de cryptage inadéquate

Sévérité : Info

CWE : CWE-326

Description :

L'application utilise new org.apache.http.impl.client.DefaultHttpClient() qui n'est pas compatible avec TLS 1.2 ou supérieur par défaut. DefaultHttpClient est une classe obsolète de Apache HttpClient 4.x qui utilise une configuration SSL/TLS vieillissante et ne prend pas en charge les protocoles de transport sécurisés modernes. Les connexions établies avec ce client peuvent retomber sur TLS 1.0 ou même SSLv3, qui sont connus pour avoir des vulnérabilités de sécurité y compris les attaques POODLE et BEAST. De plus, l'équipe Apache HttpComponents a officiellement déprécié cette classe et recommande de migrer vers des implémentations plus récentes.

Remédiation :

Migrer vers Apache HttpClient 4.5 ou ultérieur en utilisant HttpClients.createDefault() ou HttpClients.custom(), qui prennent en charge TLS 1.2 et TLS 1.3 par défaut. Pour une configuration TLS explicite en Scala, utilisez HttpClients.custom().setSSLContext(sslContext).build() avec un SSLContext configuré pour TLS 1.2 ou supérieur. En alternative, envisagez d'utiliser des bibliothèques HTTP modernes conçues pour Scala telles que sttp, http4s ou Akka HTTP, qui offrent des API sûres en type et des valeurs par défaut sécurisées pour la configuration TLS. Lorsque vous configurez TLS explicitement, assurez-vous d'utiliser SSLContext.getInstance("TLSv1.2") ou SSLContext.getInstance("TLSv1.3") et évitez les protocoles hérités comme SSLv3, TLS 1.0, et TLS 1.1 qui ont des vulnérabilités connues.

scala_endpoint_rule-JaxWsEndpoint

Résumé :

Utilisation d'une source moins fiable

Sévérité : Info

CWE : CWE-348

Description :

Cette méthode est annotée avec @javax.jws.WebMethod, la marquant comme un point de terminaison de service web SOAP (JSR-224) qui traite des requêtes XML externes. Les points de terminaison SOAP décorés avec des annotations JAX-WS exposent l'application à des données fournies par des utilisateurs non fiables dans les charges utiles des messages SOAP, ce qui peut introduire des vulnérabilités de sécurité, y compris l'injection XML, les attaques XXE (XML External Entity) et l'accès non autorisé si elles ne sont pas correctement sécurisées. Les paramètres de méthode dérivés des messages SOAP doivent être considérés comme des sources non fiables nécessitant une validation de sécurité approfondie.

Remédiation :

Envisagez de mettre en œuvre des normes WS-Security pour les points de terminaison SOAP JAX-WS afin de garantir une authentication et une autorisation appropriées. Il est recommandé d'utiliser le jeton d'identifiant WS-Security ou des jetons SAML pour l'authentification plutôt que de s'appuyer uniquement sur la sécurité au niveau du transport. Configurez votre analyseur XML pour désactiver le traitement DTD et la résolution des entités externes afin de prévenir les attaques XXE en définissant des fonctionnalités appropriées sur le SAXParserFactory ou le DocumentBuilderFactory. Validez tout le contenu des messages SOAP à l'aide de la validation XML Schema et d'une validation de logique métier supplémentaire avant traitement. Utilisez exclusivement HTTPS/TLS pour la communication SOAP en configurant les URL des points de terminaison avec le schéma https:// et en imposant TLS 1.2 ou supérieur. Envisagez de mettre en œuvre le chiffrement au niveau des messages en utilisant le chiffrement WS-Security pour les données sensibles dans les charges utiles SOAP. Appliquez une limitation de débit et des restrictions de taille des messages pour prévenir les attaques par déni de service contre les points de terminaison SOAP.

OWASP :

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

scala_endpoint_rule-UnencryptedSocket

Résumé :

Transmission en clair d'informations sensibles

Gravité : Info

CWE : CWE-319

Description :

L'application crée une connexion socket en utilisant new java.net.Socket() qui établit une connexion réseau non chiffrée permettant de transmettre des données en clair. Cela expose toutes les données transmises, y compris des informations potentiellement sensibles, à l'interception et à l'écoute via des attaques de type homme du milieu. Les sockets non chiffrés n'offrent aucune protection de confidentialité ou d'intégrité, permettant aux attaquants ayant accès au réseau de lire ou de modifier des données en transit.

Remédiation :

Envisagez d'utiliser SSLSocket ou SSLSocketFactory au lieu de java.net.Socket pour les connexions réseau qui transmettent des données sensibles. Il est recommandé de créer des sockets SSL/TLS en utilisant SSLSocketFactory.getDefault().createSocket() qui utilise le contexte SSL par défaut du système avec une validation adéquate des certificats. Pour des configurations SSL personnalisées, créez un SSLContext avec des gestionnaires de confiance appropriés et utilisez-le pour créer des instances de SSLSocketFactory. Assurez-vous d'une validation correcte des certificats en utilisant l'implémentation de TrustManager par défaut plutôt qu'en créant des gestionnaires de confiance personnalisés qui contournent la validation. Configurez le socket pour utiliser exclusivement TLS 1.2 ou TLS 1.3 en appelant setEnabledProtocols() avec les versions de protocole appropriées. Pour la vérification des noms d'hôte dans les connexions client, cast le socket en SSLSocket et vérifiez que le nom d'hôte correspond au certificat après l'établissement de la connexion. Consultez la feuille de conseils de protection de la couche de transport d'OWASP pour des conseils complets sur l'implémentation de sockets sécurisés.

OWASP :

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

scala_endpoint_rule-RéponseNonValidée

Résumé :

Redirection d'URL vers un site non fiable ('Redirection ouverte')

Sévérité : Info

CWE : CWE-601

Description :

L'application utilise des méthodes HttpServletResponse telles que sendRedirect(), addHeader(), encodeURL() ou encodeRedirectUrl() avec des paramètres fournis par l'utilisateur qui ne sont pas validés ou restreints à des valeurs sûres. Ces méthodes de redirection et de manipulation d'URL peuvent introduire des vulnérabilités de redirection ouverte lorsqu'elles traitent des entrées non fiables, permettant aux attaquants de créer des URLs qui redirigent les utilisateurs vers des sites externes malveillants. Les redirections ouvertes sont couramment exploitées dans des campagnes de phishing où les attaquants tirent parti de la réputation d'un domaine de confiance pour tromper les utilisateurs en les incitant à visiter des sites contrôlés par les attaquants.

Remédiation :

Envisagez de mettre en œuvre une approche de validation basée sur une liste blanche pour les URLs de redirection avant de les passer aux méthodes de redirection HttpServletResponse. Il est recommandé de maintenir une liste prédéfinie d'URLs de destination ou de préfixes de chemin autorisés et de valider l'entrée utilisateur par rapport à cette liste blanche avant d'effectuer des redirections. Pour les chemins relatifs, assurez-vous que la destination de la redirection commence par "/" et ne contient pas "://" pour éviter les redirections d'URL absolues vers des domaines externes. Utilisez l'analyse URI (java.net.URI) pour extraire et valider le composant nom d'hôte, en rejetant toute redirection pointant vers un domaine externe, sauf si elle est explicitement ajoutée à la liste blanche. Envisagez d'utiliser des cartes de référence indirectes où l'entrée utilisateur spécifie une clé qui correspond à une URL sûre prédéterminée plutôt que d'accepter des URLs complètes directement. Évitez d'utiliser des entrées utilisateur dans les en-têtes Location ou les paramètres de redirection sans validation. Pour les applications nécessitant des redirections flexibles, implémentez une page de confirmation de redirection qui affiche la destination et requiert la reconnaissance de l'utilisateur avant de procéder.

scala_endpoint_rule-WeakHostNameVerification

Résumé :

Validation de certificat incorrecte

Gravité : Info

CWE : CWE-295

Description :

L'application implémente un HostnameVerifier ou X509TrustManager personnalisé qui accepte tous les certificats en renvoyant true à partir des méthodes verify(), en laissant les méthodes de vérification vides, ou en retournant des tableaux nuls/vides à partir de getAcceptedIssuers(). Ces implementations de confiance totale désactivent complètement la validation des certificats SSL/TLS, rendant l'application vulnérable aux attaques de type man-in-the-middle où des attaquants peuvent intercepter et déchiffrer le trafic HTTPS en présentant n'importe quel certificat. Bien que souvent mises en œuvre pour contourner la réutilisation de certificats entre plusieurs hôtes ou des problèmes d'environnement de développement, ces implémentations éliminent les garanties de sécurité que TLS est censé fournir.

Remédiation :

Envisagez d'utiliser la validation de certificat SSL/TLS par défaut fournie par la JVM plutôt que d'implémenter des classes personnalisées HostnameVerifier ou X509TrustManager. Il est recommandé de supprimer les implémentations de confiance totale et de s'appuyer sur SSLContext.getDefault() qui effectue une validation correcte de la chaîne de certificats et de la vérification du nom d'hôte. Pour les cas légitimes nécessitant une validation personnalisée, implémentez un contrôle approprié des certificats en validant la chaîne de certificats, les dates d'expiration et la correspondance des noms d'hôte plutôt qu'en acceptant tous les certificats. Si vous travaillez avec des certificats auto-signés dans des environnements non productifs, créez un truststore personnalisé contenant uniquement les certificats de confiance spécifiques et chargez-le à l'aide de KeyStore et TrustManagerFactory plutôt que de désactiver complètement la validation. Utilisez HttpsURLConnection.setDefaultHostnameVerifier() ou HttpsURLConnection.setDefaultSSLSocketFactory() avec des contextes SSL correctement configurés pour la configuration globale du client HTTPS. Pour la réutilisation de certificats entre plusieurs noms d'hôte, configurez les Subject Alternative Names (SAN) dans les certificats plutôt que de désactiver la vérification des noms d'hôte.

scala_file_rule-FileUploadFileName

Résumé :

Limitation incorrecte d'un chemin vers un répertoire restreint ('Traversée de chemin')

Gravité : Info

CWE : CWE-22

Description :

Vulnérabilité de traversée de chemin dans la gestion des téléchargements de fichiers détectée à l'aide de 'FileItem.getName()'. Cette méthode renvoie des noms de fichiers directement à partir des demandes des clients, qui peuvent être manipulés pour inclure des séquences de traversée de chemin comme '../' ou des chemins absolus. Utiliser des noms de fichiers non assainis peut permettre aux attaquants d'écrire des fichiers à des emplacements arbitraires sur le système de fichiers du serveur, pouvant potentiellement écraser des fichiers critiques.

Remédiation :

Envisagez d'extraire uniquement le nom de fichier de base sans composants de chemin à partir des résultats de 'getName()'. Il est recommandé de supprimer tous les caractères de séparation de chemin tels que '/', '\', et les séquences '..' avant d'utiliser le nom de fichier. Validez les extensions de fichier par rapport à une liste stricte de types autorisés. Générez des noms de fichiers aléatoires au lieu d'utiliser des noms fournis par le client lorsque cela est possible, en stockant le nom d'origine séparément dans les métadonnées.

OWASP :

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

scala_form_rule-FormValidate

Résumé :

Validation incorrecte des équivalences non sécurisées dans les entrées

Gravité : Info

CWE : CWE-1289

Description :

Méthode de validation manquante dans la classe de formulaire détectée. Cette classe étend ActionForm ou ValidatorForm mais n'implémente pas de méthode validate(), laissant les entrées utilisateur non vérifiées. Sans validation appropriée, les entrées malveillantes peuvent contourner les contrôles de sécurité et mener à des attaques par injection, à la corruption de données ou à des opérations non autorisées. La validation des formulaires fournit une défense essentielle en profondeur contre diverses menaces basées sur les entrées.

Remédiation :

Envisagez d'implémenter une méthode validate() dans les classes de formulaire qui étendent ActionForm ou ValidatorForm pour assurer une validation adéquate des entrées. Il est recommandé de valider toutes les données fournies par l'utilisateur, y compris les contraintes de longueur, de format, de type, et de gamme avant le traitement. Utilisez des listes d'autorisation pour les valeurs acceptables lorsque c'est possible, et nettoyez les entrées pour prévenir les attaques par injection. La validation doit se faire côté serveur, même s'il existe des vérifications côté client.

scala_inject_rule-AWSQueryInjection

Résumé :

Neutralisation incorrecte des éléments spéciaux dans la logique de requête de données

Gravité : Info

CWE : CWE-943

Description :

L'application utilise com.amazonaws.services.simpledb.model.SelectRequest pour construire des requêtes AWS SimpleDB avec des entrées utilisateur non fiable, ce qui peut permettre à un attaquant de modifier la logique de la requête et de visualiser des enregistrements non autorisés. Cette vulnérabilité d'injection NoSQL se produit lorsque des données contrôlées par l'utilisateur sont concaténées directement dans des chaînes SelectExpression sans validation ou paramétrage appropriés, permettant aux attaquants d'injecter des caractères spéciaux et de manipuler la structure de la requête pour accéder à des données sensibles à travers des domaines.

Remédiation :

Envisagez de mettre en œuvre une validation stricte des entrées qui autorise uniquement les caractères et motifs attendus pour les paramètres de requête. Il est recommandé d'utiliser des requêtes paramétrées lorsque cela est possible, ou d'échapper les caractères spéciaux de SimpleDB tels que les apostrophes simples, les accents graves et les opérateurs qui pourraient altérer la logique de la requête. Pour une protection plus robuste, validez que les entrées utilisateur correspondent aux formats attendus (par exemple, UUID, IDs alphanumériques) et rejetez toute entrée contenant des mots-clés ou des opérateurs semblables à SQL. Envisagez de migrer vers DynamoDB qui offre un meilleur support des requêtes paramétrées via ses opérations Query et Scan avec un bon lien de valeur d'attribut.

scala_inject_rule-BeanPropertyInjection

Résumé :

Contrôle externe du système ou des paramètres de configuration

Sévérité : Info

CWE : CWE-15

Description :

L'application utilise org.apache.commons.beanutils.BeanUtils.populate() ou BeanUtilsBean.populate() avec des données de Map contrôlées par l'utilisateur, peuplées à partir de HttpServletRequest.getParameter() ou HttpServletRequest.getParameterValues(), ce qui permet aux attaquants de définir des propriétés de bean arbitraires et de compromettre l'intégrité du système. Les attaquants peuvent exploiter cela pour accéder à des propriétés dangereuses comme class.classLoader qui permettent de remplacer des propriétés système et potentiellement d'atteindre l'exécution de code arbitraire par manipulation de classloader.

Remédiation :

Envisagez de mettre en œuvre une approche basée sur une liste blanche où seuls les noms de propriétés de bean explicitement autorisés peuvent être définis à partir des entrées utilisateur. Il est recommandé d'éviter d'utiliser BeanUtils.populate() directement avec des paramètres de requête et de mapper manuellement uniquement les propriétés spécifiques dont votre application a besoin. Vous pouvez utiliser un motif d'Objet de Transfert de Données (DTO) avec des mappages de champs explicites plutôt qu'une population automatique. Pour des frameworks comme Spring MVC, utilisez @InitBinder avec WebDataBinder.setAllowedFields() pour restreindre les propriétés pouvant être liées aux requêtes HTTP. Ne laissez jamais les entrées utilisateur contrôler les noms de propriétés - seules les valeurs de propriété doivent provenir des utilisateurs, et les noms de propriété doivent être codés en dur dans votre application.

scala_inject_rule-CLRFInjectionLogs

Résumé :

Neutralisation incorrecte des séquences CRLF ('Injection CRLF')

Sévérité : Information

CWE : CWE-93

Description :

L'application journalise les entrées utilisateur de HttpServletRequest.getParameter() en utilisant des frameworks de journalisation (Log4j, SLF4J, java.util.logging, Apache Commons Logging, TinyLog) sans neutraliser les séquences CRLF, ce qui permet aux attaquants de falsifier des entrées de journal ou d'injecter du contenu malveillant. Les attaquants peuvent injecter des caractères de nouvelle ligne (\r\n) pour créer de fausses entrées de journal qui faussent les statistiques, distraient les administrateurs ou impliquent d'autres dans des actes malveillants. Si les fichiers journaux sont traités automatiquement, les attaquants peuvent corrompre les formats de fichiers ou injecter des commandes exploitant des vulnérabilités dans les utilitaires de traitement des journaux via des injections de commandes ou des attaques XSS.

Remédiation :

Envisagez de nettoyer toutes les entrées utilisateur avant de les journaliser en remplaçant ou en supprimant les caractères CRLF (\r et \n). Il est recommandé d'utiliser replaceAll("[\r\n]", "") ou des fonctions d'encodage d'URL comme java.net.URLEncoder.encode() ou forUriComponent() de l'OWASP Encoder avant de transmettre les données aux méthodes de journalisation. Pour une journalisation structurée, vous pouvez utiliser la journalisation paramétrée avec un évasion appropriée (par exemple, les messages paramétrés de SLF4J) qui aide à séparer les données du journal des chaînes de format. Envisagez de mettre en œuvre un utilitaire centralisé de nettoyage des entrées qui normalise toutes les entrées utilisateur avant la journalisation. Certains frameworks de journalisation comme Logback offrent des options d'encodage intégrées qui peuvent automatiquement échapper aux nouvelles lignes dans les données journalisées.

scala_inject_rule-InjectionDeCommande

Résumé :

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

Sévérité : Info

CWE : CWE-78

Description :

L'application utilise Runtime.getRuntime().exec() ou ProcessBuilder.command() pour exécuter des commandes système avec des entrées contrôlées par l'utilisateur passées via des paramètres de chaîne, une concaténation ou des modèles d'invocation de shell. Lorsque des entrées non filtrées sont passées à ces API, surtout en utilisant des interprètes de shell (sh, bash, ksh, csh, tcsh, zsh) ou des méthodes de formatage/concaténation de chaînes, des attaquants peuvent injecter des métacaractères et des opérateurs de shell pour exécuter des commandes arbitraires. Cette vulnérabilité permet un compromis total du système, car les commandes s'exécutent avec le niveau de privilège de l'application.

Remédiation :

Envisagez d'éviter complètement les interprètes de shell en utilisant ProcessBuilder avec des arguments sous forme de tableau où chaque argument est un élément de tableau séparé, empêchant ainsi l'interprétation des métacaractères par le shell. Il est recommandé de valider et de mettre sur liste blanche les entrées de l'utilisateur contre un ensemble strict de valeurs autorisées (par exemple, uniquement des caractères alphanumériques) si elles doivent être incluses dans les commandes. Pour une exécution plus sûre, utilisez des API de niveau supérieur comme Apache Commons Exec avec une sanitation appropriée des arguments, ou envisagez des bibliothèques natives à la langue qui évitent les appels système (par exemple, utilisez Java NIO pour les opérations sur les fichiers au lieu de commandes système). Si des fonctionnalités de shell sont absolument nécessaires, utilisez des frameworks d'exécution paramétrés qui gèrent l'échappement automatiquement, et ne permettez jamais à une entrée utilisateur de spécifier des noms ou des chemins de commande - uniquement des arguments contraints pour des commandes prédéterminées.

scala_inject_rule-FileDisclosure

Résumé :

Fichiers ou Répertoires Accessibles aux Parties Externes

Sévérité : Info

CWE : CWE-552

Description :

L'application construit des chemins de redirection ou de transfert côté serveur en utilisant des données d'entrée utilisateur provenant de HttpServletRequest.getParameter() dans les constructeurs ModelAndView du Spring Framework ou setViewName(), dans les constructeurs ActionForward d'Apache Struts ou setPath(), ou dans les méthodes RequestDispatcher.include()/forward() des Servlets. Cela permet aux attaquants de manipuler les chemins de vue pour télécharger des binaires d'application (y compris les classes d'application, les fichiers JAR, ou les fichiers de configuration) ou de voir des fichiers arbitraires dans des répertoires protégés via des attaques par traversée de chemin ou accès direct aux fichiers.

Remédiation :

Envisagez de mettre en œuvre une approche basée sur une liste blanche où les entrées utilisateur sont mappées à des noms de vue prédéfinis via une table de correspondance ou une énumération, n'autorisant jamais la construction directe de chemins à partir des données utilisateur. Il est recommandé d'utiliser des références indirectes telles que des ID de vue qui se mappent à des chemins réels côté serveur (par exemple, l'utilisateur fournit "dashboard" qui se mappe à "/WEB-INF/views/dashboard.jsp"). Pour Spring MVC, configurez des résolveurs de vue avec des préfixes et suffixes fixes afin que l'entrée utilisateur détermine uniquement le nom de la vue, et non le chemin complet. Pour Struts, utilisez les définitions de transfert dans struts-config.xml plutôt que de définir le chemin par programmation. Validez que tous les composants de chemin contrôlés par l'utilisateur ne contiennent que des caractères alphanumériques et n'incluent pas de séquences de traversée de chemin (../, ..\, etc.). Envisagez d'utiliser des mécanismes de résolution de vue au niveau du framework qui restreignent les chemins accessibles à des répertoires spécifiques.

scala_inject_rule-HttpParameterPollution

Résumé :

Neutralisation incorrecte des délimiteurs d'arguments dans une commande ('Injection d'arguments')

Sévérité : Info

CWE : CWE-88

Description :

L'application concatène des entrées utilisateur non validées provenant de HttpServletRequest.getParameter() dans des URLs HTTP utilisées dans les constructeurs HttpGet d'Apache HttpClient ou GetMethod d'Apache Commons HttpClient et setQueryString(), ce qui permet des attaques par Pollution de Paramètres HTTP (HPP). Les attaquants peuvent injecter des délimiteurs de chaîne de requête codés (&, =, ?) dans les valeurs des paramètres pour remplacer des paramètres existants, injecter de nouveaux paramètres ou exploiter des variables en dehors de l'accès direct. Sans une codification d'URL appropriée, les attaquants peuvent compromettre la logique de l'application pour réaliser des attaques côté client ou côté serveur en manipulant les paramètres de requête envoyés aux systèmes backend.

Remédiation :

Envisagez d'utiliser java.net.URLEncoder.encode() avec le jeu de caractères UTF-8 pour coder correctement toutes les entrées utilisateur avant de les concaténer dans des URLs ou des chaînes de requête. Il est recommandé d'utiliser des utilitaires de construction d'URL comme URIBuilder d'Apache HttpClient qui gère automatiquement le codage des paramètres via les méthodes addParameter(). Pour un codage plus robuste, vous pouvez utiliser UrlEscapers.urlPathSegmentEscaper().escape() de Guava qui fournit un échappement complet. Encodez toujours les noms et valeurs des paramètres séparément avant la concaténation - coder l'URL entière après construction est insuffisant. Envisagez de valider que les entrées utilisateur correspondent à des motifs attendus (alphanumériques, ensembles de caractères spécifiques) et de rejeter les entrées contenant des métacaractères d'URL comme &, =, ?, #, ou %.

scala_inject_rule-SpotbugsPathTraversalAbsolute

Résumé :

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

Sévérité : Info

CWE : CWE-22

Description :

L'application construit des chemins de fichiers à partir de HttpServletRequest.getParameter() et les utilise dans des opérations sur des fichiers, y compris java.io.File, java.io.FileInputStream, java.io.FileReader, java.io.FileWriter, java.io.FileOutputStream, java.io.RandomAccessFile, javax.activation.FileDataSource, java.nio.file.Paths.get(), et les APIs de création de fichiers temporaires. L'application ne neutralise pas correctement les séquences de chemin absolu (comme "/etc/passwd" ou "C:\Windows\System32\config\sam") qui contournent les restrictions de chemin relatif. Lorsque les utilisateurs fournissent des chemins absolus, ils peuvent accéder ou modifier des fichiers n'importe où sur le système de fichiers, indépendamment des restrictions de répertoire prévues.

Remédiation :

Envisagez d'utiliser org.apache.commons.io.FilenameUtils.getName() qui extrait uniquement le composant nom du fichier et supprime toutes les informations de chemin de répertoire, y compris les chemins absolus. Il est recommandé de rejeter toute saisie utilisateur commençant par des séparateurs de chemin (/, ) ou des lettres de lecteur Windows (C:, D:) avant le traitement. On peut valider que les chemins construits utilisent File.isAbsolute() et rejeter les chemins absolus, en veillant à n'accepter que des chemins relatifs dans un répertoire de base désigné. Pour une protection robuste, utilisez File.getCanonicalPath() pour résoudre le chemin complet et vérifier qu'il commence par votre répertoire de base prévu à l'aide de startsWith(). Envisagez d'utiliser des références indirectes où les utilisateurs fournissent des identifiants qui correspondent à des noms de fichiers côté serveur, éliminant ainsi le contrôle direct des chemins. Configurez l'accès aux fichiers avec le principe du moindre privilège - exécutez l'application avec les permissions de système de fichiers minimales.

OWASP :

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

scala_inject_rule-SpotbugsPathTraversalRelative

Résumé :

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

Sévérité : Info

CWE : CWE-22

Description :

L'application construit des chemins de fichiers en concaténant HttpServletRequest.getParameter() avec d'autres chaînes à l'aide d'opérateurs de concaténation de chaînes, puis utilise ces chemins dans des opérations de fichier incluant java.io.File, java.io.FileInputStream, java.io.FileReader, java.io.FileWriter, java.io.FileOutputStream, java.io.RandomAccessFile, javax.activation.FileDataSource, java.nio.file.Paths.get(), et la création de fichiers temporaires. L'application ne neutralise pas correctement les séquences de traversal de chemin relatives comme "../" ou "..\" qui peuvent résoudre à des emplacements en dehors des répertoires restreints. Les attaquants peuvent remonter les hiérarchies de répertoires pour accéder ou modifier des fichiers sensibles, des données de configuration ou des fichiers système.

Remédiation :

Considérez l'utilisation de org.apache.commons.io.FilenameUtils.getName() qui supprime les composants de répertoire y compris les références de répertoire parent (..). Il est recommandé d'utiliser java.nio.file.Path.normalize() pour réduire les séquences de traversal, puis de vérifier que le chemin normalisé se trouve toujours dans le répertoire de base prévu à l'aide de startsWith(). Vous pouvez mettre en œuvre une validation qui rejette toute entrée utilisateur contenant des séquences "..", des séparateurs de chemin (/, ), ou d'autres métacaractères de chemin avant la concaténation. Pour une protection accrue, utilisez File.getCanonicalPath() pour résoudre complètement le chemin y compris les liens symboliques et vérifiez que le résultat est un descendant de votre répertoire autorisé. Envisagez d'utiliser des modèles plus sûrs comme la génération de noms de fichiers aléatoires côté serveur et le maintien d'une correspondance séparée avec les noms fournis par l'utilisateur, éliminant ainsi le contrôle de l'utilisateur sur les chemins réels du système de fichiers.

OWASP :

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

scala_ldap_rule-AnonymousLDAP

Résumé :

Vérification de sécurité mal implémentée pour la norme

Sévérité : Info

CWE : CWE-358

Description :

Définir 'Context.SECURITY_AUTHENTICATION' sur "none" désactive l'authentification pour les connexions LDAP, permettant des liaisons anonymes au serveur de répertoires. Cela expose le serveur LDAP à un accès non autorisé et permet aux attaquants de consulter, modifier ou extraire des informations sensibles du répertoire sans identifiants. L'authentification LDAP anonyme ne doit jamais être utilisée dans des environnements de production.

Remédiation :

Ne jamais définir 'Context.SECURITY_AUTHENTICATION' sur "none" pour les connexions LDAP. Il est recommandé d'utiliser une authentification "simple" avec des identifiants appropriés (nom d'utilisateur et mot de passe) ou des mécanismes plus solides comme SASL pour les liaisons LDAP. Envisagez de mettre en œuvre une authentification par certificat ou Kerberos pour une sécurité renforcée. Validez toujours que les connexions LDAP sont authentifiées et utilisez des transports cryptés (LDAPS) pour protéger les identifiants en transit.

scala_perm_rule-DangerousPermissions

Résumé :

Permissions héritées non sécurisées

Gravité : Info

CWE : CWE-277

Description :

Accorder des permissions de sécurité Java dangereuses telles que RuntimePermission avec createClassLoader ou ReflectPermission avec suppressAccessChecks via PermissionCollection.add() peut compromettre la sécurité de l'application. La permission createClassLoader permet au code d'instancier des chargeurs de classes personnalisés pouvant contourner les restrictions de sécurité, tandis que suppressAccessChecks désactive les vérifications de contrôle d'accès de Java, permettant un accès non autorisé aux champs et méthodes privés par réflexion. Ces permissions peuvent être exploitées pour escalader les privilèges, accéder à des données sensibles ou exécuter du code arbitraire.

Remédiation :

Envisagez d'utiliser le principe du moindre privilège lors de la configuration des permissions de sécurité. Il est recommandé d'accorder uniquement les permissions minimales nécessaires au bon fonctionnement de votre application. Au lieu d'accorder des permissions larges telles que createClassLoader ou suppressAccessChecks, envisagez d'utiliser des permissions plus spécifiques et restreintes qui limitent la portée d'accès. Si la réflexion est nécessaire, envisagez d'utiliser des handles de méthode ou d'autres alternatives plus sûres qui ne nécessitent pas de suppression des vérifications d'accès. Pour le chargement de classes, envisagez d'utiliser le chargeur de classes par défaut de l'application ou de mettre en œuvre une politique de sécurité personnalisée qui restreint les classes pouvant être chargées. Passez en revue votre fichier de politique de sécurité et assurez-vous que les permissions dangereuses ne sont accordées qu'à des sources de code de confiance avec une signature et une vérification appropriées. Envisagez de mettre en œuvre une surveillance de sécurité à l'exécution pour détecter et prévenir les tentatives d'escalade de privilèges.

scala_script_rule-ScriptInjection

Résumé :

Contrôle inadéquat de la génération de code ('Injection de code')

Sévérité : Info

CWE : CWE-94

Description :

Les entrées contrôlées par l'utilisateur sont transmises à 'ScriptEngine.eval()', permettant aux attaquants d'exécuter un code arbitraire dans le contexte de l'application. Cela peut potentiellement mener à un compromis total du système, à l'exfiltration de données ou à une élévation de privilèges. Les vulnérabilités d'injection de script sont particulièrement dangereuses car elles offrent des capacités d'exécution de code direct.

Remédiation :

Envisagez d'éviter complètement l'utilisation de l'évaluation de script dynamique avec des entrées utilisateur. Il est recommandé de refactoriser le code pour utiliser des appels de méthode statiques ou des opérations prédéfinies à la place. Si l'évaluation de script est absolument nécessaire, mettez en œuvre une validation stricte de liste blanche pour les noms de fonctions et les paramètres. Ne jamais transmettre d'entrées utilisateur non assainies à 'eval()' car cette fonction exécute du code arbitraire avec les privilèges de l'application.

OWASP :

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

scala_strings_rule-FormatStringManipulation

Résumé :

Utilisation de chaînes de format externes

Sévérité : Info

CWE : CWE-134

Description :

Utiliser une entrée non fiable provenant de javax.servlet.http.HttpServletRequest.getParameter() directement dans des méthodes de chaînes de format telles que String.format(), java.util.Formatter.format(), ou System.out.printf() permet aux attaquants de contrôler les spécificateurs de format. Les attaquants peuvent injecter des chaînes de format malveillantes telles que %n (qui écrit des données), %s (pour fuir des arguments non utilisés), ou des spécificateurs invalides pour provoquer des exceptions non interceptées qui font planter l'application. Cela est particulièrement dangereux lorsque des données sensibles sont passées dans les arguments variadiques, car les attaquants peuvent manipuler la chaîne de format pour révéler des informations qui n'étaient pas destinées à être affichées.

Remédiation :

Considérez l'utilisation de journaux paramétrés ou de concaténation de chaînes au lieu de chaînes de format lors de l'incorporation d'entrées utilisateur dans la sortie. Si les chaînes de format sont nécessaires, il est recommandé d'utiliser une approche de liste blanche où seuls des modèles de format sûrs et prédéfinis sont utilisés et où l'entrée utilisateur est strictement limitée aux arguments de données (jamais à la chaîne de format elle-même). Pour les scénarios de journalisation, envisagez d'utiliser SLF4J avec des messages paramétrés comme logger.info("Action de l'utilisateur : {}", userInput) qui gère de manière sécurisée la substitution. Validez et the sanitize toujours les entrées utilisateur avant utilisation, et mettez en œuvre un traitement des exceptions approprié pour éviter les plantages de l'application dus à des spécificateurs de format mal formés. Si un formatage dynamique est absolument nécessaire, envisagez de mettre en œuvre une validation stricte des entrées qui rejette toute chaîne contenant des caractères de spécification de format comme %.

scala_strings_rule-ModifierAprèsValidation

Résumé :

Contraction des données en une valeur non sécurisée

Gravité : Info

CWE : CWE-182

Description :

Le code applique une validation à l'aide d'un Pattern.matcher() regex sur une variable chaîne, puis modifie ensuite cette même chaîne en utilisant String.replace() ou des méthodes de transformation similaires. Cela viole le principe de modification des chaînes avant la validation, tel que décrit dans la directive CERT IDS11-J. Modifier les chaînes après validation peut invalider les contrôles de sécurité, permettant à des entrées malveillantes de contourner la validation en introduisant des caractères ou des motifs dangereux durant la transformation qui n'étaient pas présents lors de la vérification de validation initiale, ce qui peut conduire à des attaques par injection ou d'autres vulnérabilités de sécurité.

Remédiation :

Envisagez d'effectuer toutes les transformations de chaînes, y compris replace(), replaceAll(), toLowerCase(), toUpperCase(), et les opérations de normalisation Unicode avant d'appliquer les contrôles de validation avec des correspondances regex ou d'autres logiques de validation. Il est recommandé d'établir d'abord une forme canonique de la chaîne d'entrée à travers toutes les transformations nécessaires, puis de valider la chaîne canonisée pour s'assurer que la validation reflète avec précision la forme finale qui sera utilisée. Si la modification après la validation est inévitable, re-validez la chaîne après la transformation pour garantir qu'elle respecte toujours les exigences de sécurité. Cette approche de défense en profondeur empêche les attaquants d'exploiter le fossé entre la validation et l'utilisation en injectant un contenu malveillant à travers les opérations de transformation de chaînes.

scala_strings_rule-NormalizeAfterValidation

Résumé :

Consolidation des données en une valeur non sécurisée

Gravité : Info

CWE : CWE-182

Description :

Le code valide une variable de chaîne en utilisant Pattern.matcher() pour vérifier la présence de caractères dangereux tels que '<' ou '>', puis normalise la chaîne ultérieurement en utilisant java.text.Normalizer.normalize(). Cela viole la directive CERT IDS01-J qui exige la normalisation des chaînes avant la validation. La normalisation Unicode peut combiner ou décomposer des caractères, créant potentiellement des caractères dangereux comme '<' ou '>' à partir de séquences de caractères qui semblaient sûres lors de la validation. Par exemple, le caractère Unicode U+FF1C (moins de largeur complète) se normalise en '<', permettant aux attaquants de contourner la validation et d'injecter des métacaractères HTML/XML pouvant mener à des vulnérabilités de type cross-site scripting ou autres injections.

Remédiation :

Envisagez d'appliquer java.text.Normalizer.normalize() avec une forme de normalisation appropriée (généralement NFC ou NFKC) avant d'effectuer des vérifications de validation pour garantir que la validation s'effectue sur la forme canonique de la chaîne. Il est recommandé d'utiliser NFKC (Forme de Normalisation KC) pour les validations sensibles à la sécurité, car elle effectue à la fois la décomposition de compatibilité et la composition canonique, empêchant les contournements de validation basés sur Unicode. Établissez toujours une politique de normalisation cohérente à travers votre application où les entrées non fiables sont normalisées immédiatement à leur réception, puis validées dans leur forme normalisée. Soyez conscient que les différentes formes de normalisation (NFC, NFD, NFKC, NFKD) ont des implications sécuritaires différentes - NFKC est généralement préféré pour les frontières de sécurité, car elle traite la plus large gamme de représentations de caractères équivalentes, empêchant les attaquants d'utiliser des caractères Unicode obscurs pour contourner les filtres.

scala_templateinjection_rule-TemplateInjection

Résumé :

Contrôle inadéquat de la génération de code ('Injection de code')

Gravité : Info

CWE : CWE-94

Description :

Vulnérabilité d'injection de modèle détectée dans les méthodes de traitement des modèles. Les entrées contrôlées par l'utilisateur sont transmises aux moteurs de templates via Velocity.evaluate(), getTemplate(), ou process() sans une sanitation appropriée. Si un attaquant peut contrôler le contenu du modèle ou les noms des modèles, il peut exécuter un code arbitraire sur le serveur, accéder à des données sensibles, ou compromettre l'ensemble de l'application. Les moteurs de templates devraient traiter les modèles comme du code exécutable, et non comme des données.

Remédiation :

Envisagez d'utiliser des noms ou des chemins de modèle codés en dur au lieu d'accepter les entrées utilisateur pour la sélection de modèles. Il est recommandé d'utiliser VelocityContext pour passer en toute sécurité des données aux modèles plutôt que d'évaluer directement des chaînes de modèle contrôlées par l'utilisateur. Si des modèles dynamiques sont nécessaires, mettez en œuvre une validation stricte de liste autorisée pour les noms de modèles et assurez-vous que le contenu des modèles ne peut pas être modifié par les utilisateurs. Envisagez d'utiliser un environnement de modèle sandboxé avec des permissions restreintes.

scala_unsafe_rule-SensitiveDataExposure

Résumé :

Exposition d'informations sensibles du système à une sphère de contrôle non autorisée.

Sévérité : Info

CWE : CWE-497

Description :

Une exposition de données de configuration sensibles dans le Play Framework a été détectée. Les valeurs de configuration récupérées via Configuration.underlying.getString() sont retournées directement dans les réponses HTTP via Ok(). Cela expose la configuration interne du système, y compris les identifiants de base de données, les clés API, les URLs internes, les paramètres de sécurité et d'autres paramètres confidentiels à des utilisateurs non autorisés. Les attaquants peuvent tirer parti de ces informations pour compromettre l'application, accéder aux systèmes backend ou identifier des faiblesses de sécurité dans l'environnement de déploiement.

Remédiation :

Envisagez de mettre en œuvre des contrôles d'accès stricts pour empêcher l'exposition des données de configuration dans les réponses HTTP. Il est recommandé de séparer les valeurs de configuration accessibles au public des paramètres internes sensibles, en utilisant différents espaces de noms ou fichiers de configuration. Évitez de retourner des valeurs de configuration brutes directement aux utilisateurs ; au lieu de cela, transformez et nettoyez les données avant de les inclure dans les réponses. Envisagez de mettre en œuvre une liste d'autorisation de clés de configuration sûres qui peuvent être exposées, en rejetant les demandes pour toute paramètre non listé. Il est recommandé d'utiliser les méthodes de l'API de configuration du Play Framework qui prennent en charge les valeurs par défaut et la sécurité de type, évitant l'accès direct à Typesafe Config sous-jacent. Envisagez de chiffrer les valeurs de configuration sensibles au repos et de les déchiffrer uniquement lorsque cela est nécessaire en interne, jamais dans des contextes accessibles aux utilisateurs. Mettez en œuvre une journalisation et un suivi complets des tentatives d'accès à la configuration pour détecter d'éventuelles activités de reconnaissance par des attaquants.

scala_xml_rule-ApacheXmlRpc

Résumé :

Désérialisation de données non fiables

Sévérité : Info

CWE : CWE-502

Description :

Appeler setEnabledForExtensions(true) sur XmlRpcServerConfigImpl() ou XmlRpcClientConfigImpl() dans Apache XML-RPC active des extensions de sérialisation dangereuses qui permettent la désérialisation arbitraire d'objets Java. Cela crée une vulnérabilité critique d'exécution de code à distance lors du traitement de demandes XML-RPC non fiables, car les attaquants peuvent concevoir des charges utiles malveillantes pour instancier des classes arbitraires et exécuter du code sur le serveur.

Remédiation :

Envisagez de maintenir les extensions désactivées (le comportement par défaut) en ne appelant jamais setEnabledForExtensions(true) sur les objets de configuration XML-RPC. Si des types de données étendus sont nécessaires, il est recommandé d'utiliser un mapping de type explicite avec TypeFactory et de n'enregistrer que les types spécifiques nécessaires via TypeConverterFactory.createTypeConverter(). Pour les applications nécessitant des structures de données complexes, envisagez de migrer vers des frameworks RPC modernes comme gRPC ou des API REST avec JSON, qui offrent de meilleurs contrôles de sécurité et une sécurité de type sans risques de désérialisation. Si XML-RPC doit être utilisé, mettez en œuvre une validation stricte des entrées et envisagez de faire fonctionner le service XML-RPC dans un environnement isolé avec des permissions restreintes pour limiter l'impact des exploits potentiels.

scala_xss_rule-MVCApi

Résumé :

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

Sévérité : Info

CWE : CWE-79

Description :

L'application renvoie des données fournies par les utilisateurs à partir des paramètres d'Action de Scala Play Framework directement dans une réponse Ok() sans un encodage HTML approprié. Cela crée une vulnérabilité de Cross-Site Scripting (XSS) où les attaquants peuvent injecter du JavaScript malveillant en élaborant des paramètres de requête qui sont renvoyés dans la réponse HTTP. La règle détecte le flux de taint des paramètres String de la fonction Action vers le constructeur de réponse Ok() de Play, qui rendra le contenu non fiable sans évasion automatique à moins que des modèles ne soient utilisés. Cela est particulièrement dangereux dans les applications Scala où la sécurité de type peut créer un faux sentiment de sécurité, car la concaténation de chaînes et la construction directe de réponses contournent les mécanismes d’auto-évasion des modèles de Play.

Remédiation :

Envisagez d'utiliser le moteur de modèles Twirl du Play Framework qui offre une évasion HTML automatique par défaut pour toutes les variables de modèle. Si vous devez construire des réponses directement avec Ok(), utilisez org.owasp.encoder.Encode.forHtml() pour échapper l'entrée utilisateur avant de l'inclure dans la réponse. Pour les réponses HTML, préférez renvoyer Ok(views.html.mytemplate(data)) où Twirl échappera automatiquement les variables. Si vous devez rendre du HTML brut provenant de sources de confiance, marquez-le explicitement comme sûr avec le constructeur Html(), mais n'appliquez jamais cela à l'entrée utilisateur. Pour les réponses JSON, utilisez la bibliothèque JSON intégrée de Play qui gère l'évasion automatiquement. Mettez en œuvre des en-têtes de Politique de sécurité du contenu (CSP) en utilisant les filtres de Play pour fournir une protection en profondeur contre les attaques XSS.

scala_xss_rule-XSSServlet

Résumé :

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

Sévérité : Info

CWE : CWE-79

Description :

L'application écrit les données fournies par l'utilisateur à partir des paramètres de requête HTTP directement dans la réponse HTTP via HttpServletResponse.getWriter().write() dans le code de servlet Scala. Cela crée une vulnérabilité de Cross-Site Scripting (XSS) où des attaquants peuvent injecter du JavaScript malveillant en élaborant des paramètres de requête obtenus via HttpServletRequest.getParameter() qui sont renvoyés sans encodage HTML. La règle détecte le flux de contamination des paramètres de requête de servlet vers les méthodes de l'écrivain de réponse, un modèle classique de XSS réfléchi. Sans un encodage de sortie approprié, des scripts malveillants s'exécuteront dans les navigateurs des victimes, potentiellement menant au détournement de session, au vol de crédentials, à la défiguration ou à d'autres attaques côté client dans les applications de servlet basées sur Scala.

Remédiation :

Envisagez d'utiliser la fonction Encode.forHtml() de la bibliothèque OWASP Java Encoder pour échapper les entrées utilisateur avant d'écrire dans la réponse du servlet dans le code Scala. Si vous écrivez des réponses en texte brut, définissez le Type de Contenu sur text/plain avec response.setContentType("text/plain; charset=UTF-8") pour empêcher les navigateurs d'interpréter la sortie comme du HTML. Pour les applications web Scala modernes, préférez utiliser des frameworks comme Play Framework avec des modèles Twirl ou Scalatra avec des modèles SSP/Scaml qui fournissent un échappement contextuel automatique au lieu d'écrire manuellement dans les flux de sortie de servlet. Pour les contextes JavaScript, CSS ou URL, utilisez des fonctions d'encodage spécialisées de l'OWASP Java Encoder (Encode.forJavaScript(), Encode.forCssString(), Encode.forUriComponent()). Implémentez des en-têtes de politique de sécurité de contenu (CSP) comme couche de défense supplémentaire contre les attaques XSS.

scala_xxe_rule-SaxParserXXE

Résumé :

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

Gravité : Info

CWE : CWE-611

Description :

L'application utilise SAXParserFactory.newInstance() et newSAXParser() pour créer un parseur XML sans désactiver le traitement des entités externes, ce qui la rend vulnérable aux attaques par entité externe XML (XXE). Lorsque le parseur SAX traite une entrée XML non fiable sans les fonctionnalités de sécurité appropriées configurées, les attaquants peuvent exploiter les références d'entités externes pour lire des fichiers arbitraires, effectuer des attaques SSRF contre des services internes, exfiltrer des données par des canaux hors bande, ou déclencher des dénis de service par des attaques d'expansion d'entité comme les "billion laughs".

Remédiation :

Configurez le SAXParserFactory pour désactiver complètement les déclarations DOCTYPE en appelant setFeature("http://apache.org/xml/features/disallow-doctype-decl", true) avant de créer le parseur. Cela empêche toutes les vulnérabilités XXE, les attaques d'expansion d'entité, et les attaques DoS "billion laughs" en bloquant complètement le traitement DTD. Alternativement, activez XMLConstants.FEATURE_SECURE_PROCESSING pour des restrictions de sécurité supplémentaires. Exemple : val factory = SAXParserFactory.newInstance; factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); val parser = factory.newSAXParser; parser.parse(inputStream, handler); Orientations supplémentaires sur https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#java