Règles Semgrep pour Java¶

java_password_rule-ConstantDBPassword¶

Résumé :

Utilisation de mots de passe codés en dur

Gravité : Critique

Description :

L'application utilise java.sql.DriverManager.getConnection() avec un mot de passe codé en dur en tant que chaîne littérale dans le troisième paramètre. Les mots de passe codés en dur intégrés directement dans le code source créent des risques de sécurité significatifs car ils ne peuvent pas être renouvelés sans modifications du code, sont visibles dans l'historique de contrôle de version et rendent impossible l'audit d'accès. Si le code source est compromis ou exposé par inadvertance, les informations d'identification de la base de données sont immédiatement accessibles aux attaquants. Ce schéma est particulièrement dangereux pour les connexions à la base de données car il fournit un accès direct aux magasins de données sensibles.

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 coder en dur dans l'application. Pour les applications de production, il est recommandé d'utiliser un Système de Gestion de Clés (KMS) qui fournit des audits, des contrôles d'accès et une rotation simplifiée des informations d'identification. Pour Google Cloud Platform, utilisez Cloud Key Management (https://cloud.google.com/kms/docs) ; pour AWS, utilisez AWS Secrets Manager ou AWS KMS (https://aws.amazon.com/kms/) ; pour des solutions sur site ou agnostiques au cloud, envisagez HashiCorp Vault (https://www.vaultproject.io/). Alternativement, des variables d'environnement ou des fichiers de configuration sécurisés avec des permissions de système de fichiers restreintes peuvent être utilisés pour des déploiements plus simples. Lors de l'utilisation de Spring Boot, tirez parti des configurations application.properties ou application.yml avec des valeurs externalisées et envisagez Spring Cloud Config pour la gestion centralisée des informations d'identification à travers plusieurs services.

OWASP :

A2:2017-Authentication Brisée
A07:2021-Echecs d'Identification et d'Authentification

java_password_rule-EmptyDBPassword¶

Résumé :

Authentification manquante pour une fonction critique (base de données)

Gravité : Critique

CWE : CWE-306

Description :

L'application utilise java.sql.DriverManager.getConnection() avec une chaîne vide comme paramètre de mot de passe, ce qui entraîne des connexions à la base de données sans authentification. Cela contourne complètement les mécanismes d'authentification de la base de données et permet un accès non restreint à la base de données depuis n'importe quel chemin de code qui peut invoquer cette connexion. Les connexions à la base de données sans authentification sont extrêmement dangereuses car elles ne fournissent aucun contrôle d'accès, aucune trace d'audit des opérations effectuées et aucune possibilité de révoquer l'accès sans modifications de code. Même dans les environnements de développement, les connexions non authentifiées devraient être évitées pour prévenir la propagation de modèles non sécurisés aux déploiements en production.

Remédiation :

Il est recommandé de configurer le serveur de base de données pour exiger une authentification et de créer des utilisateurs de base de données dédiés avec les permissions minimales nécessaires pour l'application. Consultez la documentation de votre serveur de base de données pour la configuration de l'authentification (par exemple, pg_hba.conf de PostgreSQL, gestion des utilisateurs de MySQL, méthodes d'authentification d'Oracle). Une fois l'authentification activée, chargez les identifiants à partir de sources externes sécurisées, telles que des variables d'environnement, des fichiers de configuration sécurisés avec des permissions restreintes ou un Système de Gestion des Clés. Pour les environnements de production, envisagez d'utiliser AWS Secrets Manager, Google Cloud Secret Manager, Azure Key Vault ou HashiCorp Vault pour une gestion centralisée des identifiants avec des capacités de rotation automatique. Lors de l'utilisation de bibliothèques de mise en pool de connexions comme HikariCP ou Apache DBCP, configurez les identifiants via leurs propriétés DataSource plutôt que de les passer directement au DriverManager.

OWASP :

A2:2017-Autentification cassée
A07:2021-Échecs d'identification et d'authentification

règles_lgpl_java_webview_règle-webview-stockage-externe¶

Résumé :

Méthode ou fonction dangereuse exposée

Gravité : Critique

CWE : CWE-749

Description :

L'application appelle WebView.loadUrl() avec des chemins obtenus à partir de Environment.getExternalStorageDirectory() ou getExternalFilesDir(), chargeant des fichiers HTML ou JavaScript directement depuis le stockage externe dans un WebView. Le stockage externe sur Android est lisible et modifiable par toutes les applications ayant des autorisations de stockage (sur les appareils avant l'API 29) ou accessible par des applications malveillantes à travers des vulnérabilités de stockage scopé. Un attaquant peut remplacer des fichiers HTML/JS légitimes par un contenu malveillant qui s'exécute dans le contexte de sécurité du WebView, ce qui peut mener à des attaques XSS, au vol de credentials, ou à un accès non autorisé aux APIs accessibles via le WebView, y compris les interfaces JavaScript exposées via addJavascriptInterface().

Remédiation :

Envisagez de stocker le contenu web dans le stockage interne de l'application en utilisant Context.getFilesDir() ou emballez le contenu dans le répertoire d'actifs de l'application et chargez-le en utilisant des URLs file:///android_asset/. Le stockage interne est privé à l'application et protégé par les mécanismes de sandboxing d'Android, empêchant d'autres applications de modifier le contenu. Si vous devez charger du contenu fourni par l'utilisateur, il est recommandé d'utiliser un ContentProvider avec FileProvider pour servir des fichiers via des URIs content:// avec des autorisations explicites, ce qui fournit un accès contrôlé et empêche les modifications de fichiers arbitraires. Pour le contenu web dynamique qui change fréquemment, envisagez de charger depuis des points de terminaison HTTPS avec une validation de certificat appropriée et de mettre en œuvre des en-têtes Content Security Policy pour atténuer les risques d'injection. Ne jamais utiliser le stockage externe pour un contenu web sensible à la sécurité tel que des pages d'authentification, des formulaires de paiement ou des pages avec des interfaces JavaScript qui se rattachent à la fonctionnalité native d'Android.

OWASP :

A1:2017-Injection
A03:2021-Injection

java_cookie_rule-HttpResponseSplitting¶

Résumé :

Neutralisation inappropriée des séquences CRLF dans les en-têtes HTTP ('Séparation de réponse HTTP')

Gravité : Élevée

CWE : CWE-113

Description :

L'application transmet les entrées fournies par l'utilisateur à partir des méthodes HttpServletRequest telles que getParameter() ou getHeader() directement dans un constructeur javax.servlet.http.Cookie ou un appel à setValue() sans validation appropriée. La séparation de réponse HTTP se produit lorsque des caractères de retour chariot (CR \r) et de saut de ligne (LF \n) sont injectés dans les valeurs des cookies, permettant aux attaquants d'injecter la séquence \r\n pour manipuler les réponses HTTP. Cela pourrait permettre des attaques de pollution de cache ou de Cross-Site Scripting (XSS) en injectant des en-têtes supplémentaires ou des corps de réponse qui seront interprétés par le client ou les proxys de mise en cache intermédiaires.

Remédiation :

Envisagez de valider toutes les entrées fournies par l'utilisateur avant de les utiliser dans les valeurs de cookie en rejetant tous les caractères inférieurs à 0x21 ou les caractères : '"' ',' ';' '\' et 0x7f comme spécifié dans le RFC 6265. Les serveurs d'applications Java modernes tels qu'Apache Tomcat 8.0+ et les versions plus récentes de Jetty rejettent automatiquement les caractères \r et \n dans les cookies, mais une validation explicite fournit une défense en profondeur et assure la compatibilité entre les environnements. Il est recommandé d'implémenter une méthode de validation qui lance IllegalArgumentException pour les caractères invalides, ou d'utiliser org.apache.commons.text.StringEscapeUtils.escapeJava() pour échapper l'entrée avant de définir les valeurs de cookie. Soyez conscient que certains serveurs d'applications plus anciens peuvent ne pas fournir de protection automatique, rendant la validation des entrées critique pour la sécurité. Plus d'informations sur https://owasp.org/www-community/attacks/HTTP_Response_Splitting

OWASP :

A1:2017-Injection
A03:2021-Injection

java_cookie_rule-RequestParamToHeader¶

Résumé :

Neutralisation incorrecte des séquences CRLF dans les en-têtes HTTP ('Fractionnement de la réponse HTTP')

Gravité : Élevée

CWE : CWE-113

Description :

L'application transmet directement les entrées fournies par l'utilisateur depuis des méthodes HttpServletRequest comme getParameter() ou getHeader() aux appels HttpServletResponse.setHeader() ou addHeader() sans validation appropriée. Le fractionnement de la réponse HTTP se produit lorsque les caractères de Retour Chariot (CR \r) et de Saut de Ligne (LF \n) sont injectés dans les en-têtes HTTP, permettant aux attaquants d'injecter la séquence \r\n pour diviser la réponse et injecter des en-têtes supplémentaires ou du contenu de réponse. Cela pourrait permettre des attaques de contamination du cache, de fixation de session, ou de Cross-Site Scripting (XSS) en manipulant la façon dont la réponse est interprétée par les clients ou les services de mise en cache en aval.

Remédiation :

Envisagez de valider toutes les entrées fournies par l'utilisateur avant de les utiliser dans les en-têtes de réponse HTTP en rejetant tous les caractères inférieurs à 0x21 ou les caractères : '"' ',' ';' '\' et 0x7f. Bien que certains serveurs d'applications Java comme Apache Tomcat encodent automatiquement les caractères CRLF en espace (0x20) dans les en-têtes de réponse, une validation explicite fournit une défense en profondeur et garantit la compatibilité entre différentes implémentations de serveur. Il est recommandé de mettre en œuvre une méthode de validation qui lance IllegalArgumentException pour les caractères invalides, ou d'utiliser org.apache.commons.text.StringEscapeUtils.escapeJava() pour sanitiser l'entrée avant d'appeler setHeader() ou addHeader(). Soyez conscient que certains anciens serveurs d'applications ou moins courants peuvent ne pas fournir de protection CRLF automatique, rendant la validation des entrées critique. Plus d'informations sur https://owasp.org/www-community/attacks/HTTP_Response_Splitting

OWASP :

A1:2017-Injection
A03:2021-Injection

java_inject_rule-CommandInjection¶

Résumé :

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

Gravité : Élevée

CWE : CWE-78

Description :

L'application utilise Runtime.exec(), ProcessBuilder.command(), ou le constructeur ProcessBuilder avec des entrées contrôlées par l'utilisateur, ce qui permet des attaques par injection de commandes OS. Cette vulnérabilité critique permet aux adversaires d'exécuter des commandes système arbitraires, pouvant mener à une compromission totale du système, une exfiltration de données, ou une déni de service. L'injection de commandes peut se produire lorsque l'entrée utilisateur est intégrée dans des chaînes de commandes, des arguments de commande, ou même des noms de fichiers passés à ces API Java sans validation ou assainissement appropriés.

Remédiation :

Envisagez d'utiliser ProcessBuilder avec une approche basée sur une liste d'arguments où chaque argument est un élément séparé du tableau, ce qui empêche l'interprétation du shell et l'injection de méta-caractères. Ne jamais passer les entrées utilisateur directement dans les chaînes de commandes ou utiliser la concaténation de chaînes pour construire des commandes. Lorsque des noms de fichiers provenant de téléchargements d'utilisateur doivent être traités, générez des noms de fichiers aléatoires en utilisant UUID.randomUUID() et conservez le nom de fichier original séparément dans une base de données ou un fichier de métadonnées. Il est fortement recommandé d'utiliser des bibliothèques Java natives au lieu de faire appel à des commandes externes chaque fois que possible, afin d'éliminer complètement la surface d'attaque. Si les commandes OS sont inévitables, utilisez des chemins absolus vers les binaires (par exemple, /usr/bin/convert au lieu de convert) pour prévenir les vulnérabilités de recherche de chemin non fiable (CWE-426). Envisagez de mettre en œuvre une liste blanche de commandes et d'arguments autorisés, et validez toutes les entrées contre des modèles stricts avant utilisation. Plus de détails sur https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html

OWASP :

A1:2017-Injection
A03:2021-Injection

java_inject_rule-DemandeDeDiffusionDeFichier¶

Résumé :

Fichiers ou répertoires accessibles aux parties externes

Gravité : Élevée

CWE : CWE-552

Description :

L'application utilise HttpServletRequest.getRequestDispatcher() suivi de RequestDispatcher.include() ou RequestDispatcher.forward() avec une entrée contrôlée par l'utilisateur, ce qui peut exposer des fichiers sensibles dans le contexte de l'application web. Ces méthodes résolvent et retournent tout fichier accessible à l'application, y compris les fichiers de configuration web.xml, les fichiers .class compilés, le code source JSP, les archives JAR/WAR et d'autres ressources qui devraient rester internes. Cette vulnérabilité de divulgation de fichiers permet aux adversaires de lire le code source de l'application, d'extraire les identifiants de base de données des fichiers de configuration, de découvrir la structure de l'application et de rassembler des informations pour des attaques ultérieures.

Remédiation :

Envisagez d'utiliser une approche de table de recherche où l'entrée utilisateur est validée par rapport à une HashMap ou à une énumération de noms de vues autorisés, puis mappée à des chemins de ressources codés en dur avant d'appeler getRequestDispatcher(). Ne jamais passer les entrées de l'utilisateur directement à getRequestDispatcher() ou autoriser les segments de chemin contrôlés par l'utilisateur. En alternative, utilisez HttpServletResponse.sendRedirect() pour effectuer des redirections HTTP 301/302 qui sont plus sûres que les transferts internes car elles n'exposent pas la structure interne de l'application et forcent un nouveau cycle de requête. Lors de l'utilisation d'une table de recherche, utilisez HashMap.getOrDefault() pour fournir une vue de secours sûre lorsque l'entrée de l'utilisateur ne correspond à aucune valeur autorisée. Pour les applications Spring MVC, reposez-vous sur le mécanisme de résolution des vues du framework avec des méthodes de contrôleur retournant des noms de vues logiques plutôt que de construire directement des chemins. Envisagez de mettre en œuvre une validation stricte de liste blanche qui n'autorise que les caractères alphanumériques pour tout identifiant de vue fourni par l'utilisateur, et enregistrez toutes les tentatives d'accès à des ressources en dehors de l'ensemble autorisé pour le suivi de la sécurité.

OWASP :

A5:2017-Contrôle d'Accès Fissuré
A01:2021-Contrôle d'Accès Fissuré

java_inject_rule-FinDeFichierSpringFramework¶

Résumé :

Fichiers ou répertoires accessibles aux parties externes

Sévérité : Élevée

CWE : CWE-552

Description :

L'application utilise le constructeur org.springframework.web.servlet.ModelAndView ou la méthode ModelAndView.setViewName() avec une entrée contrôlée par l'utilisateur, ce qui peut exposer des fichiers JSP restreints et d'autres ressources de vue. La classe ModelAndView de Spring résout les noms de vue via des ViewResolvers configurés, en recherchant généralement des fichiers .jsp ou d'autres ressources de template. Lorsque les noms de vue sont dérivés d'une entrée utilisateur sans validation, des adversaires peuvent manipuler le chemin pour accéder aux fichiers JSP, fichiers de configuration ou autres ressources qui ne devraient pas être accessibles directement. Cette vulnérabilité est particulièrement critique dans les applications Spring MVC où le mécanisme de résolution de vue pourrait permettre un traversal de répertoire ou l'accès à des vues internes de l'application qui ne sont pas destinées aux utilisateurs externes.

Remédiation :

Envisagez d'utiliser le modèle standard de contrôleur de Spring MVC où les méthodes retournent des noms de vue logiques qui sont résolus via des ViewResolvers configurés, et utilisez une table de recherche ou une énumération pour mapper l'entrée de l'utilisateur aux noms de vue autorisés avant de construire des objets ModelAndView. Ne passez jamais directement l'entrée utilisateur au constructeur ModelAndView ou à la méthode setViewName(). Lorsque différentes vues doivent être sélectionnées en fonction de l'entrée de l'utilisateur, validez l'entrée par rapport à une liste blanche d'identifiants de vue autorisés en utilisant HashMap.getOrDefault() ou une instruction switch avec seulement des noms de vue sûrs connus. Envisagez d'utiliser des préfixes de redirection comme redirect:/path dans les noms de vue pour effectuer des redirections HTTP plutôt que des transferts internes, ce qui offre une meilleure isolation. Pour les applications utilisant Thymeleaf, FreeMarker ou d'autres moteurs de template, assurez-vous que la configuration du ViewResolver restreint la résolution des templates à des répertoires spécifiques et n'autorise pas les séquences de traversal de chemin. Implémentez une journalisation des demandes de noms de vue invalides pour détecter d'éventuelles tentatives d'exploitation. Les applications Spring modernes devraient envisager d'utiliser @ResponseBody avec des points de terminaison REST et un routage côté client plutôt que la résolution de vue côté serveur pour améliorer la sécurité et l'architecture.

OWASP :

A5:2017-Contrôle d'Accès Rompu
A01:2021-Contrôle d'Accès Rompu

java_inject_rule-OgnlInjection¶

Résumé :

Injection d'expressions (OGNL)

Sévérité : Élevée

CWE : CWE-917

Description :

L'application utilise les méthodes d'évaluation du langage de navigation dans les graphiques d'objets (OGNL) des packages Apache Struts2 tels que OgnlUtil.getValue(), OgnlUtil.setValue(), OgnlUtil.compile(), TextParseUtil.translateVariables(), ValueStack.findValue(), OgnlReflectionProvider.setProperty(), ou StrutsUtil.findValue() avec des entrées contrôlées par l'utilisateur, ce qui permet des attaques par injection OGNL. OGNL est un langage d'expression puissant utilisé par Struts2 pour accéder aux objets et propriétés Java dans le ActionContext, mais lorsque l'entrée de l'utilisateur est évaluée comme des expressions OGNL, cela permet aux adversaires d'exécuter du code Java arbitraire, y compris des commandes OS, par le biais de la réflexion et de la manipulation à l'exécution. Cette classe de vulnérabilité a été responsable de nombreuses exploits critiques d'exécution de code à distance dans les applications Struts2 et doit être considérée comme extrêmement dangereuse.

Remédiation :

Envisagez d'utiliser des balises Struts2 standard et des opérations sur la pile de valeurs au lieu de méthodes d'évaluation OGNL de bas niveau. Ne passez jamais directement l'entrée de l'utilisateur aux fonctions d'évaluation OGNL des packages com.opensymphony.xwork2.ognl, com.opensymphony.xwork2.util, com.opensymphony.xwork2.util.reflection, ou org.apache.struts2.util. En suivant les directives de sécurité officielles de Struts2, évitez d'utiliser des expressions brutes ${} dans les pages JSP et les modèles avec des données fournies par l'utilisateur. Lorsque l'accès dynamique aux propriétés est nécessaire, utilisez des setters et getters d'Action avec des noms de propriétés validés à partir d'une liste d'autorisation plutôt que d'évaluer des expressions OGNL arbitraires. Assurez-vous d'exécuter la dernière version corrigée de Struts2, car de nombreuses vulnérabilités d'injection OGNL ont été traitées par des mises à jour de framework et des correctifs de sécurité. Envisagez de migrer vers des frameworks plus modernes comme Spring MVC ou Jakarta EE qui ne reposent pas sur l'évaluation des expressions OGNL. Si vous devez prendre en charge des expressions dynamiques, mettez en œuvre une validation stricte des entrées et utilisez les fonctionnalités SecurityMemberAccess dans Struts2 pour restreindre l'accès aux classes et méthodes via OGNL. Plus d'informations sur https://struts.apache.org/security/#do-not-use-incoming-untrusted-user-input-in-forced-expression-evaluation

OWASP :

A1:2017-Injection
A03:2021-Injection

java_ldap_rule-AnonymousLDAP¶

Résumé :

Authentification manquante pour une fonction critique (LDAP)

Gravité : Élevée

CWE : CWE-306

Description :

L'application configure l'authentification LDAP anonyme en définissant Context.SECURITY_AUTHENTICATION sur "none" dans l'environnement de contexte JNDI. Cela désactive l'authentification lors de la communication avec le serveur LDAP, permettant à tout client de se connecter sans identifiants. L'accès LDAP anonyme expose le répertoire à des requêtes non autorisées et à une possible exfiltration de données, car il n'y a aucun contrôle d'accès pour restreindre quelles informations peuvent être récupérées ou quelles opérations peuvent être effectuées. Cette configuration viole le principe du moindre privilège et crée un risque de sécurité significatif, surtout lorsque le répertoire LDAP contient des données sensibles des utilisateurs, des identifiants ou des informations organisationnelles.

Remédiation :

Envisagez de configurer des identifiants d'authentification appropriés lors de l'établissement de connexions LDAP utilisant JNDI. Il est recommandé d'utiliser Context.SECURITY_PRINCIPAL et Context.SECURITY_CREDENTIALS pour spécifier le nom distinctif (DN) et le mot de passe pour l'authentification, plutôt que de définir Context.SECURITY_AUTHENTICATION sur "none". Envisagez de récupérer les identifiants LDAP à partir d'un magasin d'identifiants sécurisé ou d'un système de gestion de clés (KMS) plutôt que de les coder en dur. De plus, il est recommandé d'utiliser des arguments de recherche paramétrés avec InitialDirContext.search() pour prévenir les attaques par injection LDAP lors du traitement des entrées fournies par les utilisateurs.

Exemple de connexion LDAP sécurisée avec authentification et traitement de requêtes sûr :

// Créer des propriétés pour la configuration de la connexion LDAP
Properties props = new Properties();
props.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
props.put(Context.PROVIDER_URL, "ldap://ldap.example.org:3889");

// Configurer les identifiants d'authentification (récupérer depuis un magasin sécurisé)
props.put(Context.SECURITY_PRINCIPAL, "cn=admin,dc=example,dc=org");
String ldapPassword = getAccountPasswordFromSecureStoreOrKMS();
props.put(Context.SECURITY_CREDENTIALS, ldapPassword);

// Établir une connexion LDAP authentifiée
InitialDirContext ldapContext = new InitialDirContext(props);

// Configurer les paramètres de recherche
SearchControls searchControls = new SearchControls();
searchControls.setSearchScope(SearchControls.SUBTREE_SCOPE);

// Utiliser des requêtes paramétrées pour éviter l'injection LDAP
String userQuery = someUserInput;
Object[] searchArguments = new Object[]{userQuery};

// Exécuter la recherche avec encodage des paramètres automatique
NamingEnumeration answer = ldapContext.search(
  "dc=example,dc=org",
  "(cn={0})",
  searchArguments,
  searchControls
);

Pour plus d'informations sur les meilleures pratiques de sécurité LDAP, consultez : LDAP_Injection_Prevention_Cheat_Sheet.html

OWASP :

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

java_password_rule-HardcodePassword¶

Résumé :

Utilisation de mots de passe en dur

Sévérité : Élevée

CWE : CWE-259

Description :

L'application utilise des chaînes de caractères de mots de passe en dur avec des API Java sensibles à la sécurité, y compris java.security.KeyStore.PasswordProtection(), KeyStore.load(), KeyManagerFactory.init(), javax.security.auth.callback.PasswordCallback.setPassword(), javax.crypto.spec.PBEKeySpec, java.net.PasswordAuthentication, javax.security.auth.kerberos.KerberosKey, java.sql.DriverManager.getConnection(), io.vertx.ext.web.handler.CSRFHandler.create(), et des méthodes génériques setPassword(). Les mots de passe en dur créent de nombreuses vulnérabilités de sécurité : ils sont visibles dans les dépôts de code source et l'historique de contrôle de version, ne peuvent pas être changés sans redéployer l'application, rendent impossible la tenue de registres d'audit, et ne fournissent aucun mécanisme de révocation d'accès. Ce modèle affecte des composants de sécurité critiques, y compris le chiffrement des keystores, la gestion des certificats SSL/TLS, l'authentification des bases de données, l'authentification Kerberos et les systèmes de chiffrement basés sur des mots de passe.

Remédiation :

Envisagez de charger les identifiants à partir de sources de configuration externes sécurisées plutôt que de les intégrer dans le code source. Pour les environnements de production, il est recommandé d'utiliser un système de gestion des clés (KMS) qui fournit des audits des identifiants, des contrôles d'accès et une rotation automatisée - comme AWS Secrets Manager, Google Cloud Secret Manager, Azure Key Vault ou HashiCorp Vault. Pour des déploiements plus simples, utilisez des variables d'environnement accessibles via System.getenv() ou des fichiers de propriétés sécurisées avec des permissions de système de fichiers restreintes chargées via java.util.Properties. Lorsque vous travaillez avec des keystores et des certificats SSL/TLS, envisagez d'utiliser le type de keystore JCEKS de Java avec des mots de passe externalisés, et tirez parti d'outils comme keytool pour une gestion sécurisée des keystores. Pour les identifiants de base de données dans les applications Spring, utilisez la configuration externalisée de Spring Boot avec des propriétés chiffrées via Jasypt ou Spring Cloud Config Server. Pour le chiffrement PBE, dérivez les clés à partir de phrases de passe fournies par l'utilisateur à l'exécution plutôt que de les coder en dur. Important : assurez-vous que tout plan de migration inclut la rotation de tous les identifiants précédemment codés en dur, car ils doivent être considérés comme compromis dès qu'ils sont engagés dans le contrôle de version.

OWASP :

A2:2017-Authentification rompue
A07:2021-Failles d'identification et d'authentification

java_rule_sql_injection¶

Résumé :

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

Sévérité : Élevée

CWE : CWE-89

Description :

Une vulnérabilité d'injection SQL a été détectée où des entrées contrôlées par l'utilisateur sont intégrées de manière non sécurisée dans une requête SQL par concaténation de chaînes (en utilisant +), formatage de chaînes (en utilisant .format() ou .formatted()), ou espaces réservés entre guillemets ('%s'). La requête est exécutée à l'aide de méthodes telles que executeQuery(), executeUpdate(), execute(), ou d'autres fonctions d'exécution SQL similaires dans JDBC, Spring JdbcTemplate, ou d'autres API de base de données. L'injection SQL se produit lorsque des données non fiables sont directement intégrées dans des déclarations SQL sans une désinfection ou une paramétrisation appropriée, permettant aux attaquants de manipuler la logique de la requête, de contourner l'authentification, d'extraire des données sensibles, de modifier ou de supprimer des enregistrements, ou d'exécuter des commandes SQL arbitraires contre la base de données.

Remédiation :

Envisagez d'utiliser des requêtes paramétrées (également connues sous le nom de déclarations préparées) avec des espaces réservés de paramètres positionnels (?) ou nommés (:param) au lieu de méthodes de concaténation de chaînes ou de formatage de chaînes. Il est recommandé d'utiliser des frameworks établis qui offrent une protection intégrée contre les injections SQL, tels que JDBC PreparedStatement, Spring JdbcTemplate, JPA/Hibernate Query API, ou d'autres bibliothèques ORM réputées. Ces frameworks traitent les entrées utilisateurs séparément de la structure de commande SQL, garantissant que les données utilisateurs sont correctement échappées et ne peuvent pas altérer la logique de la requête. Envisagez de valider et de désinfecter toutes les entrées contrôlées par l'utilisateur avant utilisation, même en utilisant des requêtes paramétrées, comme mesure de défense supplémentaire en profondeur.

Exemple de requête SQL sécurisée utilisant JDBC PreparedStatement avec des paramètres positionnels :

// Non sécurisé : La concaténation de chaînes permet l'injection SQL
// String query = "SELECT * FROM users WHERE username = '" + username + "'";

// Sécurisé : Utilisez PreparedStatement avec des paramètres positionnels
String query = "SELECT * FROM users WHERE username = ?";
PreparedStatement stmt = connection.prepareStatement(query);
stmt.setString(1, username);
ResultSet results = stmt.executeQuery();

Exemple de requête SQL sécurisée utilisant Spring JdbcTemplate avec des paramètres positionnels :

// Non sécurisé : La concaténation de chaînes ou .format()
// String query = String.format("INSERT INTO EMPLOYEE VALUES ('%s', '%s')",
//                              id, name);

// Sécurisé : Utilisez des paramètres positionnels avec JdbcTemplate
jdbcTemplate.update(
  "INSERT INTO EMPLOYEE VALUES (?, ?, ?, ?)",
  id, "Bill", "Gates", "USA"
);

Exemple de requête SQL sécurisée utilisant JPA avec des paramètres nommés :

// Sécurisé : Utilisez des paramètres nommés dans les requêtes JPA
String jpql = "SELECT u FROM User u WHERE u.username = :username";
TypedQuery<User> query = entityManager.createQuery(jpql, User.class);
query.setParameter("username", username);
List<User> results = query.getResultList();

OWASP :

A1:2017-Injection
A03:2021-Injection

java_script_rule-InjectionDeScript¶

Résumé :

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

Sévérité : Élevée

CWE : CWE-94

Description :

Les entrées contrôlées par l'utilisateur sont passées aux méthodes javax.script.ScriptEngine.eval() ou javax.script.Invocable sans une sanitation appropriée. Cela permet aux attaquants d'exécuter du code arbitraire, y compris des commandes système via des expressions comme java.lang.Runtime.getRuntime().exec('/bin/sh'), conduisant à un compromis complet du système.

Remédiation :

Ne jamais passer directement des entrées fournies par l'utilisateur aux méthodes ScriptEngine.eval() ou Invocable. Envisagez de coder en dur tout le contenu du script ou d'utiliser une table de correspondance pour mapper les entrées de l'utilisateur à des valeurs sûres prédéfinies. Si des valeurs dynamiques sont nécessaires, il est recommandé d'utiliser javax.script.Bindings pour passer les entrées de l'utilisateur en tant que données plutôt qu'en tant que code (par exemple, bindings.put("name", userInput); eval(script, bindings)). Cela garantit que les entrées de l'utilisateur sont traitées comme des données de chaîne et ne peuvent pas être exécutées en tant que code.

OWASP :

A1:2017-Injection
A03:2021-Injection

java_script_rule-SpringSpelExpressionParser¶

Résumé :

Neutralisation incorrecte des éléments spéciaux utilisés dans une déclaration de langage d'expression ('Injection de langage d'expression')

Sévérité : Élevée

CWE : CWE-917

Description :

L'entrée contrôlée par l'utilisateur est transmise aux méthodes SpelExpressionParser.parseExpression() ou parseRaw() du Spring Framework sans validation appropriée. Cela permet aux attaquants d'injecter et d'exécuter des expressions SpEL arbitraires, accédant potentiellement à des objets Java sensibles à l'exécution, invoquant des méthodes et exécutant des commandes système, ce qui peut mener à un compromis total du système.

Remédiation :

Ne jamais transmettre directement l'entrée fournie par l'utilisateur aux méthodes parseExpression() ou parseRaw(). Envisagez d'utiliser une table de correspondance pour mapper l'entrée utilisateur à des expressions sûres prédéfinies. Si une évaluation dynamique est nécessaire, il est recommandé d'utiliser SimpleEvaluationContext (Spring 4.3+) au lieu de StandardEvaluationContext lors de l'appel à getValue() sur des expressions analysées (par exemple, parsedExpr.getValue(SimpleEvaluationContext.forReadOnlyDataBinding().build())). Notez qu' même avec SimpleEvaluationContext, les attaquants peuvent accéder aux propriétés publiques des objets liés, donc utilisez avec prudence et minimisez les données exposées.

OWASP :

A1:2017-Injection
A03:2021-Injection

java_templateinjection_rule-TemplateInjection¶

Résumé :

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

Gravité : Élevée

CWE : CWE-94

Description :

L'application permet de contrôler les chaînes de modèles en passant dynamiquement les entrées utilisateur aux méthodes Velocity.evaluate(), getTemplate() ou process(). Cela permet aux adversaires d'exécuter du code Java arbitraire, y compris des commandes système OS, par le biais d'attaques par injection de template.

Remédiation :

Considérez l'utilisation d'un objet VelocityContext pour lier en toute sécurité les données fournies par l'utilisateur au lieu de les passer directement dans les chaînes de modèles. N'appelez jamais Velocity.evaluate() avec les entrées utilisateur dans le paramètre de modèle. Il est recommandé d'utiliser context.put(key, value) pour passer les données utilisateur, ce qui les traite comme des données plutôt que comme du code de modèle exécutable. Pour les moteurs FreeMarker et Pebble, utilisez des noms de modèles codés en dur avec getTemplate("fixed-name") et passez les entrées utilisateur uniquement par le biais du contexte de données.

OWASP :

A1:2017-Injection
A03:2021-Injection

java_xml_rule-XmlDecoder¶

Résumé :

Désérialisation de données non fiables

Sévérité : Élevée

CWE : CWE-502

Description :

L'application utilise java.beans.XMLDecoder.readObject() pour désérialiser des données XML, ce qui est vulnérable aux attaques d'exécution de code arbitraire. XMLDecoder interprète le XML comme du code Java exécutable en utilisant les conventions JavaBeans, permettant aux adversaires de créer des XML malveillants qui instancient des classes arbitraires et invoquent des méthodes lors de la désérialisation. Cela peut conduire à une exécution de code à distance, car les attaquants peuvent appeler des constructeurs ou des méthodes de définition qui déclenchent des opérations dangereuses. Contrairement à la désérialisation Java standard, XMLDecoder traite le XML non fiable directement lors de l'instanciation d'objets sans protections intégrées, ce qui le rend particulièrement dangereux pour le traitement des entrées contrôlées par l'utilisateur. Des exploits publics existent (comme ysoserial) qui peuvent générer automatiquement des charges utiles pour exploiter les vulnérabilités de XMLDecoder.

Remédiation :

Envisagez de migrer complètement de XMLEncoder et XMLDecoder, car ces API sont intrinsèquement non sécurisées et obsolètes pour des raisons de sécurité. Les alternatives recommandées incluent des bibliothèques de sérialisation JSON comme Jackson ou Gson, qui fournissent une désérialisation sûre en type avec des restrictions configurables sur les classes autorisées. Si vous devez continuer à utiliser XMLDecoder temporairement, implémentez un ClassLoader personnalisé qui met explicitement sur liste blanche uniquement les classes de bean spécifiques dont votre application a besoin, rejetant toutes les autres tentatives de chargement de classe. Même avec un ClassLoader personnalisé, soyez conscient qu'il s'agit d'une mesure de défense en profondeur et non d'une solution complète, car des vulnérabilités subtiles peuvent encore exister. Assurez-vous de ne jamais désérialiser vers des types de base comme Object, de toujours caster vers le type exact attendu, et envisagez de créer des DTO intermédiaires avec uniquement les champs nécessaires pour se protéger contre les attaques de masse d'attribution. Des conseils supplémentaires sont disponibles dans la OWASP Deserialization Cheat Sheet à l'adresse suivante : https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html

OWASP :

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

scala_xml_rule-XsltTransform¶

Résumé :

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

Sévérité : Moyenne

CWE : CWE-91

Description :

L'utilisation de TransformerFactory.newTransformer() ou Transformer.transform() avec des feuilles de style XSLT provenant de sources non fiables peut conduire à des vulnérabilités d'exécution de code à distance. Les processeurs XSLT prennent en charge les fonctions d'extension et le chargement de ressources externes que les attaquants peuvent exploiter pour exécuter du code arbitraire, lire des fichiers sensibles ou effectuer des attaques de falsification de requêtes côté serveur. Lorsque la source ou le contenu de la feuille de style est contrôlé par l'entrée utilisateur via la concaténation de chaînes ou des chemins de fichiers externes, les attaquants peuvent injecter des directives XSLT malveillantes pour compromettre l'application.

Remédiation :

Envisagez de mettre en œuvre une validation stricte des entrées et d'éviter la construction dynamique de chemins de feuilles de style XSLT à partir de l'entrée utilisateur. Il est recommandé d'utiliser une approche par liste blanche où seules les fichiers de feuilles de style prédéfinis et fiables peuvent être chargés à partir d'un répertoire sécurisé. Lors de la création de la `TransformerFactory`, désactivez le traitement des entités externes et les fonctions d'extension en définissant `XMLConstants.FEATURE_SECURE_PROCESSING` sur true et en utilisant `TransformerFactory.setFeature()` pour désactiver les fonctionnalités dangereuses. Pour les applications nécessitant des transformations dynamiques, envisagez d'utiliser des moteurs de template comme FreeMarker ou Thymeleaf qui offrent de meilleurs contrôles de sécurité. Si XSLT doit être utilisé avec du contenu fourni par l'utilisateur, mettez en œuvre des politiques de sécurité de contenu, exécutez les transformations dans des environnements isolés avec des permissions restreintes, et validez toute sortie avant de l'utiliser dans des contextes sensibles en matière de sécurité.¶

java_cookie_rule-CookieInsecure¶

Résumé :

Cookie sensible dans une session HTTPS sans attribut 'Secure'

Sévérité : Faible

CWE : CWE-614

Description :

L'application crée un objet javax.servlet.http.Cookie sans appeler setSecure(true) avant de l'ajouter à la HttpServletResponse. L'attribut Secure lorsqu'il est défini sur true protège la valeur du cookie contre une transmission via des chemins de communication en texte clair tels que HTTP, garantissant que le cookie ne sera envoyé que par HTTPS. Sans cette protection, les cookies de session et d'autres données sensibles peuvent être interceptés par des attaquants effectuant des attaques d'écoute réseau.

Remédiation :

Envisagez d'appeler setSecure(true) sur tous les objets Cookie avant de les ajouter à la réponse via addCookie(). Cela garantit que les cookies ne sont transmit que sur des connexions HTTPS chiffrées. Par exemple : Cookie cookie = new Cookie("session", value); cookie.setSecure(true); response.addCookie(cookie);. En plus du drapeau Secure, les cookies de session doivent également être configurés avec setHttpOnly(true) pour empêcher l'accès par JavaScript et envisager d'utiliser des attributs SameSite pour atténuer les attaques CSRF. Pour les applications modernes Spring Boot, vous pouvez configurer cela globalement via server.servlet.session.cookie.secure=true dans les propriétés d'application. Plus de détails sur https://jakarta.ee/specifications/servlet/4.0/apidocs/javax/servlet/http/cookie#setSecure-boolean-

OWASP :

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

java_cors_rule-PermissiveCORSInjection¶

Résumé :

Politique de cross-domain permissive avec des domaines non fiables

Gravité : Faible

CWE : CWE-942

Description :

L'application permet à l'entrée fournie par l'utilisateur de contrôler la valeur de l'en-tête de réponse Access-Control-Allow-Origin via HttpServletResponse.setHeader ou HttpServletResponse.addHeader. Cet en-tête fait partie de la spécification Cross-Origin Resource Sharing (CORS) qui détermine quels domaines externes peuvent accéder aux ressources de ce serveur. En permettant à l'entrée utilisateur de spécifier des domaines de confiance, un attaquant pourrait exploiter cette faiblesse pour forcer les clients à envoyer des identifiants (comme des identifiants de session ou des cookies) au serveur de l'attaquant. Cette vulnérabilité devient exploitable lorsqu'elle est combinée à d'autres faiblesses telles que le Cross-Site Scripting (XSS), permettant aux attaquants de contourner les protections de la politique de même origine et de voler des données sensibles.

Remédiation :

Considérez d'éviter l'utilisation de l'entrée fournie par l'utilisateur lors de la définition de la valeur de l'en-tête Access-Control-Allow-Origin dans HttpServletResponse.setHeader ou HttpServletResponse.addHeader. Il est recommandé de maintenir une liste blanche codée en dur des domaines de confiance et d'utiliser un mécanisme de recherche pour valider et sélectionner le domaine approprié. Cette approche garantit que seuls les domaines explicitement approuvés peuvent être définis dans l'en-tête CORS, empêchant les attaquants d'injecter des origines malveillantes. Envisagez d'implémenter une validation des domaines en maintenant une Map ou un Set de domaines autorisés et en utilisant l'entrée utilisateur uniquement comme clé pour rechercher la valeur de confiance, plutôt que de l'insérer directement dans l'en-tête.

Exemple de mise en œuvre d'une configuration d'en-tête CORS basée sur une liste blanche sécurisée :

// Définir les domaines autorisés dans le constructeur ou à partir d'une source de configuration fiable
Map<String, String> allowedDomains = new HashMap();
allowedDomains.put("sub1", "sub1.example.com");
allowedDomains.put("sub2", "sub2.example.com");

// Utiliser l'entrée de l'utilisateur uniquement comme clé de recherche, avec une valeur de secours par défaut sûre
String headerValue = allowedDomains.getOrDefault(
  request.getParameter("allowedDomain"),
  allowedDomains.get("sub1")
);

// Définir l'en-tête avec une valeur de domaine validée et de confiance
response.addHeader("Access-Control-Allow-Origin", headerValue);

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

OWASP :

A1:2017-Injection
A03:2021-Injection

java_smtp_rule-SmtpClient¶

Résumé :

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

Sévérité : Faible

CWE : CWE-77

Description :

L'application appelle les méthodes MimeMessage (setSubject, addHeader, setDescription ou setDisposition) avec des données contrôlées par l'utilisateur qui peuvent contenir des séquences CRLF (\r\n). SMTP est un protocole basé sur du texte qui utilise des en-têtes pour contrôler le routage des e-mails et les métadonnées. Un attaquant peut injecter des séquences CRLF pour ajouter des en-têtes d'e-mail arbitraires (comme CC, BCC ou des destinataires supplémentaires), ce qui peut entraîner l'envoi de messages à des destinataires non voulus ou contourner les contrôles de sécurité.

Remédiation :

Envisagez de désinfecter toutes les entrées contrôlées par l'utilisateur avant de les transmettre aux méthodes MimeMessage pour prévenir les attaques par injection d'en-têtes d'e-mail. Il est recommandé de supprimer ou d'encoder les séquences CRLF (\r et \n) dans toute donnée non fiable utilisée dans setSubject(), addHeader(), setDescription() ou setDisposition(). Vous pouvez utiliser StringEscapeUtils.escapeJava() d'Apache Commons Text, ou mettre en œuvre une validation qui rejette les entrées contenant ces caractères. Cela empêche les attaquants d'injecter des en-têtes d'e-mail supplémentaires qui pourraient rediriger les messages.

OWASP :

A1:2017-Injection
A03:2021-Injection

java_unsafe_rule-ExternalConfigControl¶

Résumé :

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

Gravité : Faible

CWE : CWE-15

Description :

L'application utilise des entrées fournies par l'utilisateur dans les appels à java.sql.Connection.setCatalog(), permettant aux adversaires de fournir un catalogue de base de données différent pour la durée de la connexion. Le contrôle externe des paramètres système peut perturber le service ou causer un comportement imprévu et potentiellement malveillant de l'application.

Remédiation :

Envisagez d'utiliser des noms de catalogue de base de données codés en dur plutôt que d'accepter des entrées utilisateur pour les appels à setCatalog(). Il est recommandé de définir les noms de catalogue autorisés dans la configuration de l'application et de valider contre une liste blanche avant utilisation. Ne passez jamais les entrées fournies par l'utilisateur directement de HttpServletRequest.getParameter() à Connection.setCatalog(). Si une sélection dynamique de catalogue est requise, utilisez une énumération ou une table de correspondance pour traduire les entrées utilisateur en valeurs sûres et prédéfinies.

OWASP :

A1:2017-Injection
A03:2021-Injection

java_endpoint_rule-RédirectionNonValidée¶

Résumé :

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

Sévérité : Info

CWE : CWE-601

Description :

L'application utilise HttpServletResponse.sendRedirect() ou HttpServletResponse.addHeader("Location", ...) avec des entrées fournies par l'utilisateur à partir des méthodes HttpServletRequest telles que getParameter(), getHeader(), ou getRequestURI() sans validation appropriée. Cela crée une vulnérabilité de redirection non validée où un attaquant peut concevoir des URL malveillantes qui redirigent les utilisateurs vers des sites externes arbitraires. De telles vulnérabilités sont souvent exploitées dans des attaques de phishing, où les victimes croient naviguer vers un domaine de confiance mais sont en réalité redirigées vers un site contrôlé par l'attaquant, conçu pour voler des identifiants ou délivrer des logiciels malveillants.

Remédiation :

Envisagez d'implémenter une approche de liste blanche où les URL de redirection sont validées par rapport à une collection prédéfinie (comme List<String> ou Set<String>) de chemins de destination sûrs avant d'appeler sendRedirect(). Par exemple, maintenez une liste de cibles de redirection approuvées telles que /home, /dashboard, /user/profile et redirigez uniquement lorsque safeUrls.contains(redirectUrl) retourne vrai, sinon redirigez vers une page par défaut sécurisée. Il est recommandé d'utiliser des chemins relatifs (commençant par /) plutôt que des URL absolues pour éviter complètement les redirections vers des domaines externes. Si votre application doit prendre en charge des redirections dynamiques, validez que l'URL de destination appartient au domaine de votre application en analysant l'URL et en vérifiant que le nom d'hôte correspond à vos domaines attendus. Pour les applications utilisant Spring Security, envisagez d'utiliser RedirectStrategy avec validation de domaine ou d'utiliser l'annotation @Valid avec des validateurs personnalisés. Évitez d'utiliser directement les paramètres de requête dans les opérations de redirection sans une validation et une désinfection approfondies.

OWASP :

A1:2017-Injection
A03:2021-Injection

java_file_rule-FileUploadFileName¶

Résumé :

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

Gravité : Info

CWE : CWE-22

Description :

Le nom de fichier obtenu à partir de Part.getSubmittedFileName() ou FileItem.getName() peut être manipulé par le client, ce qui pourrait entraîner des vulnérabilités de traversée de chemin, un accès non autorisé aux fichiers ou une inclusion de fichiers arbitraires. Les noms de fichiers fournis par le client sont des entrées non fiables et peuvent contenir des caractères de chemin malveillants (tels que des barres obliques /, des barres obliques inverses \, ou des séquences de traversée de chemin ../ ou ..\) qui pourraient permettre aux attaquants d'écrire des fichiers en dehors du répertoire prévu ou d'accéder à des fichiers restreints.

Remédiation :

Envisagez de procéder à une validation rigoureuse des noms de fichiers fournis par les clients pour vous assurer qu'ils respectent une structure prédéfinie, qu'ils sont dépourvus de caractères potentiellement dangereux, et qu'ils correspondent uniquement à des fichiers autorisés. Les stratégies recommandées incluent : (1) Assainir les noms de fichiers en créant une fonction pour supprimer ou remplacer les caractères non autorisés, y compris les séquences de traversée de chemin (../ ou ..\). Par exemple, utilisez Paths.get(fileName).getFileName() pour stripper les composants de répertoire. (2) Implémentez une validation par liste blanche, autorisant uniquement les noms de fichiers qui correspondent à un motif spécifique tel que [a-zA-Z0-9._-]+. (3) Envisagez de générer des noms de fichiers uniques côté serveur en utilisant UUID.randomUUID() plutôt que de vous fier aux noms fournis par le client pour le stockage des fichiers. (4) Vérifiez les chemins des fichiers à l'aide de Path.resolve() et assurez-vous que les fichiers sont enregistrés dans le répertoire correct prévu afin d'éviter les redirections vers des répertoires non autorisés.

Exemple de remédiation :

public class FileUploadHandler {
    protected void doPost(HttpServletRequest request,
                          HttpServletResponse response)
          throws ServletException, IOException {

        Part filePart = request.getPart("file");
        String fileName = filePart.getSubmittedFileName();

        // Supprime toute information de chemin du nom de fichier
        String sanitizedFileName = sanitizeFileName(fileName);
        if (!isFileNameAllowed(sanitizedFileName)) {
            throw new SecurityException("Nom de fichier invalide");
        }

        // Générer un nom de fichier unique pour le stockage
        String storedFileName = UUID.randomUUID().toString() + ".txt";

        Path targetPath = Paths.get("uploads").resolve(storedFileName);
        Files.copy(filePart.getInputStream(), targetPath,
                   StandardCopyOption.REPLACE_EXISTING);
    }

    private String sanitizeFileName(String fileName) {
        return Paths.get(fileName).getFileName().toString();
    }

    private boolean isFileNameAllowed(String fileName) {
        return fileName.matches("[a-zA-Z0-9._-]+");
    }
}

OWASP :

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

java_file_rule-FilenameUtils¶

Résumé :

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

Sévérité : Info

CWE : CWE-22

Description :

Des entrées contrôlées par l'utilisateur sont transmises aux méthodes FilenameUtils d'Apache Commons IO telles que FilenameUtils.concat(), FilenameUtils.normalize() ou FilenameUtils.getFullPath() sans validation appropriée. Lorsque des données non fiables provenant de sources comme les paramètres HttpServletRequest sont utilisées pour construire des chemins de fichiers, des attaquants peuvent exploiter des séquences de traversée de chemin (par exemple, ../ ou ..\) pour accéder à des fichiers ou les manipuler en dehors du répertoire prévu. Cela peut conduire à un accès non autorisé aux fichiers, à la divulgation d'informations ou à des opérations de fichiers arbitraires sur des emplacements de système de fichiers restreints.

Remédiation :

Considérez le traitement de toutes les entrées de l'utilisateur comme potentiellement malveillantes et implémentez une stratégie de validation des entrées "accepter uniquement les bonnes connues". Les approches recommandées incluent : (1) Utiliser FilenameUtils.getName() pour extraire uniquement le composant du nom de fichier, ce qui supprime toute information de chemin de répertoire avant de l'utiliser avec FilenameUtils.concat() pour le combiner en toute sécurité avec un répertoire de base. (2) Envisagez de valider les chemins de fichiers en utilisant Path.resolve() associé à Path.startsWith() pour vérifier que le chemin résolu reste dans le répertoire de base prévu, en lançant une exception si la validation échoue. (3) Implémentez une validation par liste blanche pour garantir que les noms de fichiers correspondent à des modèles attendus et ne contiennent que des caractères autorisés. Par exemple, si l'application construit des chemins comme "images/userprofiles/" + username, une entrée malveillante telle que "../../../etc/passwd" pourrait permettre un accès non autorisé à des fichiers sensibles.

Exemple de limitation de la traversée de chemin en utilisant getName() :

protected void doPut(HttpServletRequest req, HttpServletResponse resp)
      throws ServletException, IOException {

    String input = req.getHeader("input");

    // Extraire uniquement le nom de fichier, en supprimant tout composant de chemin
    input = FilenameUtils.getName(input);

    String safePath = FilenameUtils.concat(basePath, input);

    // Lire le contenu du fichier
    File file = new File(safePath);
}

Exemple de validation de chemin en utilisant resolve() et startsWith() :

protected void doGet(HttpServletRequest req, HttpServletResponse resp)
      throws ServletException, IOException {

    String userInput = req.getParameter("filename");
    Path basePath = Paths.get("/var/www/uploads");

    Path resolvedPath = basePath.resolve(userInput).normalize();

    if (!resolvedPath.startsWith(basePath)) {
        throw new SecurityException("Tentative de traversée de chemin détectée");
    }

    File file = resolvedPath.toFile();
}

OWASP :

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

java_inject_rule-ELInjection¶

Résumé :

Neutralisation incorrecte des éléments spéciaux utilisés dans une instruction de langage d'expression ('Injection de langage d'expression')

Gravité : Info

CWE : CWE-917

Description :

L'application utilise des méthodes de langage d'expression (EL) telles que ExpressionFactory.createValueExpression(), ExpressionFactory.createMethodExpression(), ELProcessor.eval(), ELProcessor.getValue(), ou ELProcessor.setValue() avec des entrées non codées en dur, ce qui permet des attaques par injection EL. Lorsque createValueExpression() crée un objet ValueExpression, il est évalué lors de l'appel des méthodes getValue(), setValue(), ou de Lambda invoke(). De même, createMethodExpression() crée un MethodExpression qui s'évalue lors des appels à invoke() ou getMethodInfo(). Ces méthodes d'évaluation peuvent permettre à des adversaires d'exécuter du code Java arbitraire, y compris des commandes système lorsque des expressions contrôlées par l'utilisateur sont traitées. L'injection EL est particulièrement dangereuse car les attaquants peuvent accéder à l'environnement d'exécution Java et exécuter des commandes système via la réflexion.

Remédiation :

Envisagez d'utiliser une approche basée sur une liste d'autorisation où les entrées utilisateur sont validées par rapport à un ensemble prédéfini de valeurs autorisées en utilisant Set.contains() ou une table de recherche avant toute traitement EL. Ne passez jamais directement des chaînes fournies par l'utilisateur aux méthodes d'évaluation EL. Lorsque un comportement dynamique est nécessaire, utilisez ELProcessor.defineBean() pour lier des objets de données pré-validés au contexte EL, puis référencez ces beans dans des expressions EL codées en dur plutôt que de construire des expressions à partir des entrées utilisateur. Pour afficher des données utilisateur dans des vues JSP ou JSF, utilisez des balises JSTL standard comme <c:out> qui échappent automatiquement la sortie, ou définissez les beans via des propriétés de bean gérées plutôt que d'évaluer des chaînes d'expressions fournies par l'utilisateur. Si vous devez prendre en charge une certaine configuration dynamique, implémentez un analyseur strict qui n'autorise l'accès qu'à des propriétés spécifiques des beans sans capacités d'invocation de méthodes. Assurez-vous que votre application utilise la dernière version de l'implémentation EL pour bénéficier des correctifs de sécurité et des fonctionnalités de confinement améliorées.

OWASP :

A1:2017-Injection
A03:2021-Injection

java_strings_rule-BadHexConversion¶

Résumé :

Conversion ou cast de type incorrect

Sévérité : Info

CWE : CWE-704

Description :

L'application utilise Integer.toHexString() pour convertir les tableaux d'octets de hachage provenant de MessageDigest.digest() en chaînes hexadécimales, ce qui peut donner des résultats incorrects lorsque les valeurs d'octets contiennent des zéros en tête. La méthode Integer.toHexString() omet les zéros en tête pour les valeurs d'octets inférieures à 0x10, aboutissant à des représentations hexadécimales à un caractère au lieu du format requis à deux caractères. Cela entraîne des chaînes de hachage mal formées qui ne peuvent pas être correctement comparées ou validées, ce qui peut causer des vulnérabilités de sécurité dans les systèmes d'authentification, de vérification d'intégrité ou de vérification de signatures.

Remédiation :

Envisagez de migrer vers java.util.HexFormat introduit dans Java 17, qui fournit une méthode fiable et efficace pour l'encodage hexadécimal avec un bon remplissage de zéros. Pour les applications fonctionnant sur des versions de Java antérieures à 17, les alternatives recommandées incluent javax.xml.bind.DatatypeConverter.printHexBinary() ou Hex.encodeHexString() de Apache Commons Codec. L'approche HexFormat.of().formatHex(byteArray) est préférée pour les applications modernes car elle gère correctement tous les cas particuliers et produit par défaut des chaînes hexadécimales en minuscules. Lors de l'utilisation de DatatypeConverter, sachez qu'il produit des chaînes hexadécimales en majuscules et a été déprécié dans Java 9, bien qu'il reste disponible dans Java 11. Pour une compatibilité maximale entre les versions de Java, Apache Commons Codec offre un comportement cohérent et est largement testé dans des environnements de production.

OWASP :

A6:2017-Mésconfiguration de Sécurité
A05:2021-Mésconfiguration de Sécurité

java_strings_rule-ModifyAfterValidation¶

Résumé :

Concentration des données dans une valeur non sécurisée

Gravité : Info

CWE : CWE-182

Description :

L'application valide une chaîne en utilisant Pattern.matcher() puis la modifie avec replace(), replaceAll(), replaceFirst(), ou concat() après la validation. Cela crée une vulnérabilité de type temps de vérification/temps d'utilisation où les attaquants peuvent concevoir une entrée qui passe la validation mais devient malveillante après modification. Par exemple, valider contre ../ puis le retirer permet à un attaquant de soumettre ..../, qui devient ../ après suppression, contournant ainsi le contrôle de sécurité. Ce modèle viole le principe de codage sécurisé IDS11-J des directives CERT de Carnegie Mellon et peut entraîner des traversées de chemin, des attaques par injection ou d'autres contournements de sécurité en fonction du contexte de validation.

Remédiation :

Envisagez toujours de procéder aux modifications de chaînes telles que replaceAll(), replace(), replaceFirst(), ou concat() avant d'appliquer la validation avec Pattern.matcher(). La séquence correcte est : (1) normaliser/sanitiser l'entrée, (2) valider le résultat, (3) utiliser la chaîne validée sans modification supplémentaire. Il est recommandé d'utiliser replaceAll() au lieu de replace() pour supprimer des motifs, car un remplacement en une seule passe peut laisser du contenu malveillant résiduel. Pour la prévention des traversées de chemin spécifiquement, évitez totalement la manipulation de chaînes et utilisez plutôt Path.normalize() suivi d'une validation pour s'assurer que le chemin normalisé reste dans les limites autorisées en utilisant Path.startsWith(). Dans la plupart des contextes critiques pour la sécurité, envisagez de rejeter les entrées contenant des caractères suspects plutôt que d'essayer de les sanitiser. Lorsqu'une modification est nécessaire, envisagez d'utiliser des fonctions d'encodage telles que URLEncoder.encode() ou un échappement approprié au contexte plutôt que la suppression, car l'encodage conserve l'intention tout en empêchant l'interprétation. Voir https://wiki.sei.cmu.edu/confluence/display/java/IDS11-J pour des conseils détaillés.

OWASP :

A1:2017-Injection
A03:2021-Injection

java_strings_rule-NormalizeAfterValidation¶

Résumé :

Ordre de comportement incorrect : valider avant de normaliser

Gravité : Info

CWE : CWE-180

Description :

L'application effectue une validation en utilisant Pattern.matcher() puis appelle Normalizer.normalize() après que la validation a eu lieu. Cela crée une vulnérabilité de sécurité où les attaquants peuvent utiliser des équivalents Unicode ou des caractères de compatibilité pour contourner la validation. Par exemple, le caractère Unicode U+FE64 (﹤) se normalise en '<' sous la normalisation NFKC, permettant à un attaquant de contourner la validation des chevrons et d'injecter des balises HTML ou XML. Cela viole le principe de codage sécurisé IDS01-J des directives CERT de Carnegie Mellon et peut mener à des scripts intersites, des attaques d'injection, ou des contournements de contrôles de sécurité selon comment la chaîne validée est ensuite utilisée.

Remédiation :

Il est conseillé d'effectuer toujours Normalizer.normalize() avant la validation en utilisant Pattern.matcher() ou toute autre logique de validation. La séquence correcte est : (1) normaliser l'entrée en utilisant la forme NFKC ou NFC, (2) valider le résultat normalisé, (3) utiliser la chaîne validée. Envisagez d'utiliser Normalizer.Form.NFKC pour une normalisation de compatibilité qui convertit les caractères de compatibilité comme les variantes en pleine largeur et en demi-largeur en leurs formes canoniques, bien qu'il soit important de noter que cela soit plus agressif que Normalizer.Form.NFC. Pour des contextes critiques en matière de sécurité tels que la sortie HTML ou les requêtes SQL, envisagez d'utiliser des fonctions d'encodage appropriées au contexte provenant de bibliothèques telles que OWASP Java Encoder après normalisation, plutôt que de compter uniquement sur la validation des caractères. Soyez conscient que certains caractères Unicode n'ont pas d'équivalents normalisés et nécessitent un traitement explicite dans votre logique de validation. Consultez https://wiki.sei.cmu.edu/confluence/display/java/IDS01-J pour des conseils détaillés et des exemples supplémentaires de contournements de validation basés sur Unicode.

OWASP :

A1:2017-Injection
A03:2021-Injection