Règles Semgrep pour Kotlin¶
kotlin_cookie_rule-RequestParamToHeader¶
Résumé :
Neutralisation incorrecte des séquences CRLF dans les en-têtes HTTP ('HTTP Response Splitting')
Gravité : Critique
CWE : CWE-113
Description :
L'application passe des entrées contrôlées par l'utilisateur à partir des méthodes HttpServletRequest (comme
getParameter(), getHeader(), getParameterMap(), ou getPathInfo()) directement aux
méthodes HttpServletResponse.setHeader() ou HttpServletResponse.addHeader() sans
sanitisation appropriée des caractères CR (\r) et LF (\n). Cela crée une vulnérabilité critique
de division de réponse HTTP où des attaquants peuvent injecter des séquences CRLF pour terminer
la section d'en-tête actuelle et injecter des en-têtes HTTP arbitraires ou même des réponses HTTP complètes.
Les attaquants peuvent exploiter cela pour effectuer du Cross-Site Scripting (XSS) en injectant
du contenu malveillant, empoisonner le cache en manipulant les en-têtes de contrôle de cache, fixer
la session en définissant des cookies, ou réaliser des attaques de déplacement de requêtes HTTP qui peuvent contourner les contrôles de sécurité.
Remédiation :
Envisagez de mettre en œuvre une validation stricte des entrées et une sanitisation avant de passer
des données contrôlées par l'utilisateur aux méthodes setHeader() ou addHeader(). Utilisez
String.replace() avec un motif regex pour supprimer les caractères CR et LF :
val sanitized = userInput.replace(Regex("[\\r\\n]+"), ""). Vous pouvez également utiliser
org.apache.commons.text.StringEscapeUtils.unescapeJava() pour un échappement approprié des caractères de contrôle.
Il est recommandé d'utiliser une approche par liste blanche où vous validez que les valeurs d'en-tête correspondent à des motifs attendus (par exemple, uniquement des caractères alphanumériques) plutôt que d'essayer de sanitiser des entrées arbitraires.
Considérez si l'entrée utilisateur doit jamais contrôler directement les en-têtes HTTP - dans la plupart des cas, un design plus sûr utilise l'entrée de l'utilisateur pour sélectionner parmi des valeurs d'en-tête sûres pré définies plutôt que d'incorporer directement l'entrée.
Les conteneurs de servlets modernes offrent certaines protections contre la division de réponse, mais la validation au niveau de l'application est critique car ces protections ne sont pas complètes et peuvent être contournées.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_cors_rule-PermissiveCORSInjection¶
Résumé :
Politique cross-domain permissive avec des domaines non fiables
Sévérité : Critique
CWE : CWE-942
Description :
Les entrées contrôlées par l'utilisateur sont utilisées pour définir l'en-tête Access-Control-Allow-Origin via
HttpServletResponse.setHeader() ou addHeader(). Cela permet aux attaquants d'injecter
des origines malveillantes, permettant ainsi des attaques inter-domaines pouvant entraîner le vol de données, le spoofing,
et l'accès non autorisé à des informations sensibles.
Remédiation :
Envisagez de maintenir une liste blanche statique d'origines fiables et de valider
les valeurs d'origine entrantes par rapport à cette liste avant de définir l'en-tête
Access-Control-Allow-Origin. Il est recommandé de ne jamais refléter directement
l'en-tête d'origine de la requête sans validation. Évitez d'utiliser le joker *
lorsque des informations d'identification sont impliquées, car cela crée des vulnérabilités de sécurité.
Mettez en œuvre une validation côté serveur pour garantir que seules les domaines approuvés peuvent accéder
à vos ressources.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_crypto_rule-CipherECBMode¶
Résumé :
Force de chiffrement inadéquate
Gravité : Critique
CWE : CWE-326
Description :
L'application utilise javax.crypto.Cipher.getInstance() avec le mode ECB (Electronic Code Book), qui ne fournit pas de sécurité sémantique. Le mode ECB chiffre des blocs de texte clair identiques en blocs de texte chiffré identiques, révélant ainsi des motifs dans les données chiffrées. Cela permet aux attaquants d'identifier des données répétées, de réaliser des attaques par substitution de blocs et, dans de nombreux cas, de déduire des informations sur le texte clair sans briser le chiffrement. L'image célèbre du pingouin en ECB illustre comment le mode ECB préserve les motifs visuels même après le chiffrement, le rendant complètement inapproprié pour le chiffrement de données structurées ou à motifs.
Remédiation :
Remplacez le mode ECB par le mode GCM pour un chiffrement authentifié en utilisant javax.crypto.Cipher.getInstance("AES/GCM/NoPadding"). Le GCM offre une protection à la fois de la confidentialité et de l'authenticité, ce qui en fait le choix recommandé pour les applications modernes. Générez un nonce unique de 12 octets pour chaque opération de chiffrement en utilisant java.security.SecureRandom et passez-le au cipher via GCMParameterSpec. Ne réutilisez jamais les nonces avec la même clé, car cela compromet gravement la sécurité du GCM. Si le GCM n'est pas disponible dans votre environnement, utilisez le mode CBC avec authentification HMAC comme solution de repli, mais assurez-vous d'une génération correcte de l'IV et d'une construction MAC-then-encrypt. Pour les projets Kotlin, envisagez d'utiliser la bibliothèque Tink de Google qui fournit des primitives de chiffrement authentifié sûres avec des valeurs par défaut sécurisées.¶
kotlin_crypto_rule-CipherIntegrity¶
Résumé :
Utilisation d'un algorithme cryptographique défaillant ou risqué
Sévérité : Critique
CWE : CWE-327
Description :
L'application utilise javax.crypto.Cipher.getInstance() avec des modes de chiffrement (CBC, OFB, CTR ou ECB) qui ne fournissent aucune protection d'intégrité, rendant le texte chiffré susceptible d'être modifié par des adversaires. Sans authentification, les attaquants peuvent modifier des bits du texte chiffré pour altérer le texte en clair résultant de manière prévisible, permettant des attaques de flipping de bit, des attaques d'oracle de padding et des attaques par choix de texte chiffré. Ces modes fournissent uniquement la confidentialité, mais la sécurité moderne exige à la fois la confidentialité et l'authenticité pour prévenir les modifications non détectées des données chiffrées.
Remédiation :
Utilisez un chiffrement authentifié avec des données associées (AEAD) en migrant vers le mode AES-GCM avec javax.crypto.Cipher.getInstance("AES/GCM/NoPadding"). GCM offre à la fois le chiffrement et l'authentification en une seule opération, protégeant contre les modifications sans nécessiter une implémentation manuelle de MAC. Générez des nonces uniques de 12 octets à l'aide de java.security.SecureRandom pour chaque chiffrement et passez-les via GCMParameterSpec. Ne réutilisez jamais de nonces avec la même clé. Si AES-GCM n'est pas disponible, implémentez un chiffrement puis un MAC en utilisant le mode CBC avec HMAC-SHA256, mais notez que cela nécessite une mise en œuvre soigneuse pour éviter les attaques par temporisation. Pour les applications Kotlin, envisagez fortement d'utiliser la bibliothèque Tink de Google qui fournit des primitives AEAD sûres avec des valeurs par défaut sécurisées et prévient les erreurs d'implémentation courantes.
OWASP :
- A3:2017-Exposition de données sensibles
- A02:2021-Failles cryptographiques
kotlin_crypto_rule-CipherPaddingOracle¶
Résumé :
Utilisation d'un algorithme cryptographique cassé ou à risque
Sévérité : Critique
CWE : CWE-327
Description :
L'application utilise javax.crypto.Cipher.getInstance() avec le mode CBC et PKCS5Padding, qui est vulnérable aux attaques par oracle de remplissage. Les adversaires peuvent potentiellement déchiffrer des messages en exploitant les différences de temps ou les messages d'erreur qui révèlent si le remplissage est valide ou invalide après le déchiffrement. En modifiant à plusieurs reprises le texte chiffré et en observant la réponse du système à la validation du remplissage, les attaquants peuvent déchiffrer les données octet par octet sans connaître la clé de chiffrement. Cette vulnérabilité est particulièrement dangereuse lorsque les messages d'erreur distinguent entre les erreurs de remplissage et les échecs de MAC, ou lorsque les différences de temps révèlent les résultats de la validation du remplissage.
Remédiation :
Migrer vers un chiffrement authentifié en utilisant le mode AES-GCM avec javax.crypto.Cipher.getInstance("AES/GCM/NoPadding"), ce qui élimine les vulnérabilités par oracle de remplissage en utilisant un mode de chiffrements par flux qui ne nécessite pas de remplissage. GCM fournit une authentification intégrée qui détecte toute modification du texte chiffré avant que le déchiffrement ne commence. Générer des nonces uniques de 12 octets à l'aide de java.security.SecureRandom pour chaque opération de chiffrement et les transmettre via GCMParameterSpec. Si le mode CBC doit être maintenu pour des raisons de compatibilité avec les anciennes versions, mettre en œuvre encrypt-then-MAC avec une comparaison en temps constant et s'assurer que toutes les erreurs de déchiffrement renvoient des messages d'erreur identiques et des caractéristiques temporelles similaires. Pour les applications Kotlin, considérer fortement l'utilisation de la bibliothèque Tink de Google qui fournit des primitives AEAD immunisées contre les attaques par oracle de remplissage.
OWASP :
- A3:2017-Exposition de données sensibles
- A02:2021-Échecs cryptographiques
kotlin_endpoint_rule-UnvalidatedRedirect¶
Résumé :
Redirection d'URL vers un site non fiable ('Redirection ouverte')
Sévérité : Critique
CWE : CWE-601
Description :
Vulnérabilité de redirection ouverte détectée dans la gestion des réponses HTTP. Cette règle identifie les entrées contrôlées par l'utilisateur (provenant des paramètres de la requête, des en-têtes ou des cookies) qui sont passées directement à HttpServletResponse.sendRedirect() ou addHeader("Location") sans validation. Les attaquants peuvent créer des URL malveillantes qui redirigent les utilisateurs vers des sites de phishing tout en semblant provenir d'un domaine de confiance, facilitant ainsi le vol de données d'identification et les attaques d'ingénierie sociale.
Remédiation :
Envisagez de valider les URL de redirection contre une liste d'autorisation de domaines ou de chemins de confiance avant d'effectuer la redirection. Il est recommandé d'utiliser des chemins relatifs (par exemple, /dashboard) plutôt que des URL absolues lors de la redirection au sein de la même application. Si des redirections externes sont nécessaires, maintenez une liste d'autorisation de domaines approuvés et vérifiez que l'URL de redirection correspond en utilisant allowedDomains.any { url.startsWith(it) }. Alternativement, utilisez des références indirectes (par exemple, des ID de redirection associés à des URL sûres) plutôt que d'accepter des URL brutes provenant des entrées utilisateur.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_file_rule-FileUploadFileName¶
Résumé :
Limitation inadéquate d'un chemin d'accès à un répertoire restreint ('Traversée de chemin')
Gravité : Critique
CWE : CWE-22
Description :
Vulnérabilité de traversée de chemin dans le traitement des téléchargements de fichiers détectée à l'aide de méthodes comme 'FileItem.getName()' ou 'Part.getSubmittedFileName()'. Ces méthodes retournent des noms de fichiers directement issus des requêtes des clients, qui peuvent être manipulés pour inclure des séquences de traversée de chemin comme '../' ou des chemins absolus. L'utilisation de noms de fichiers non assainis peut permettre aux attaquants d'écrire des fichiers à des emplacements arbitraires sur le système de fichiers du serveur, potentiellement en écrasant 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()' ou 'getSubmittedFileName()'. 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 d'autorisation stricte des types permis. Générer des noms de fichiers aléatoires plutôt que d'utiliser les noms fournis par le client lorsque cela est possible, en stockant le nom original séparément dans les métadonnées.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_inject_rule-DivulgationDeFichier¶
Résumé :
Fichiers ou répertoires accessibles à des parties externes
Sévérité : Critique
CWE : CWE-552
Description :
L'application utilise des entrées contrôlées par l'utilisateur provenant de HttpServletRequest.getParameter() pour
construire des chemins de vue dans le constructeur ModelAndView de Spring MVC ou setViewName(), des chemins ActionForward de Struts, ou des appels RequestDispatcher.forward()/include(), ce qui
permet une divulgation de fichiers arbitraire. Lorsque les attaquants contrôlent le chemin de vue ou de transfert, ils
peuvent le manipuler pour accéder à des fichiers sensibles en dehors du répertoire de vue prévu, y compris
des binaires de l'application (fichiers JAR, fichiers de classe), des fichiers de configuration, ou d'autres ressources protégées. Cela se produit car les frameworks résolvent les noms de vue en chemins de fichiers, et
une validation insuffisante permet à des séquences de traversal de chemin ou des références directes à des fichiers de contourner
les frontières de sécurité. La vulnérabilité est particulièrement grave dans les applications Spring MVC et Struts
où les mécanismes de résolution de vue peuvent être exploités pour accéder à des fichiers arbitraires sur
le système de fichiers du serveur.
Remédiation :
Ne jamais utiliser directement l'entrée de l'utilisateur pour construire des noms de vue ou des chemins de transfert. Utilisez plutôt un
mapping de référence indirect où l'entrée de l'utilisateur sélectionne parmi un ensemble prédéfini de noms de vue valides (par exemple, une Map.., /, \) ou des indicateurs de chemin absolu. Envisagez d'utiliser RedirectView de Spring avec l'option setContextRelative(true) pour des redirections plus sûres, ou utilisez
des redirections HTTP vers des URL prédéfinies au lieu de transferts côté serveur. Pour les applications Struts, définissez tous les mappings de transfert dans des fichiers de configuration plutôt que de les construire dynamiquement. Des frameworks modernes comme Spring Boot avec Thymeleaf ou
FreeMarker offrent une meilleure isolation entre l'entrée utilisateur et la résolution de vue, réduisant ce
risque lorsqu'ils sont configurés correctement.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_inject_rule-HttpParameterPollution¶
Résumé :
Neutralisation incorrecte des délimiteurs d'arguments dans une commande ('Injection d'arguments')
Gravité : Critique
CWE : CWE-88
Description :
L'application concatène l'entrée de l'utilisateur provenant de HttpServletRequest.getParameter() dans des URLs HTTP utilisées avec les constructeurs HttpGet ou GetMethod d'Apache HttpClient sans encodage approprié, ce qui permet des attaques de Pollution de Paramètres HTTP (HPP). Lorsque l'entrée de l'utilisateur contenant des caractères spéciaux d'URL comme &, =, ? ou % est directement incorporée dans des chaînes de requête, les attaquants peuvent injecter des paramètres supplémentaires ou remplacer ceux existants. Par exemple, si l'entrée de l'utilisateur admin&role=user est concaténée dans une URL, cela pourrait être divisé en deux paramètres, contournant potentiellement les contrôles d'autorisation ou manipulant la logique de l'application. Cette vulnérabilité est particulièrement dangereuse car différentes technologies côté serveur traitent les paramètres dupliqués de manière différente (première valeur, dernière valeur, ou tableau), permettant aux attaquants d'exploiter le parsing incohérent des paramètres pour contourner les contrôles de sécurité ou altérer le comportement de l'application.
Remédiation :
Utilisez toujours des fonctions d'encodage d'URL appropriées comme java.net.URLEncoder.encode() ou UrlEscapers.urlPathSegmentEscaper().escape() de Google Guava pour nettoyer l'entrée de l'utilisateur avant de l'incorporer dans des URLs. Pour les applications Kotlin modernes, envisagez d'utiliser URIBuilder d'Apache HttpComponents qui fournit une API plus sûre pour construire des URLs avec un encodage automatique des paramètres (par exemple, URIBuilder(baseUrl).addParameter("key", userInput).build()). Cette approche sépare les noms des paramètres et leurs valeurs, empêchant les attaques par injection. Lors de l'utilisation de Kotlin avec le RestTemplate de Spring ou WebClient, utilisez des variables d'URI avec le paramètre uriVariables qui gère l'encodage automatiquement. Mettez en œuvre une validation des entrées pour rejeter toute entrée de l'utilisateur contenant des caractères spéciaux d'URL (&, =, ?, #, %) avant l'encodage. Pour les clients API, envisagez d'utiliser des bibliothèques HTTP de niveau supérieur comme Ktor Client ou OkHttp, qui fournissent des modèles de construction avec un encodage de paramètres intégré. Ne comptez jamais sur une concaténation manuelle de chaînes pour construire des URLs avec du contenu dynamique.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_inject_rule-SqlInjection¶
Résumé :
Mauvaise neutralisation des éléments spéciaux utilisés dans une commande SQL ('Injection SQL')
Sévérité : Critique
CWE : CWE-89
Description :
L'application construit des requêtes SQL en utilisant des entrées contrôlées par l'utilisateur avec concaténation de chaînes ou des modèles de chaînes Kotlin dans des API telles que java.sql.Statement.executeQuery(), Connection.prepareStatement(), la méthode Session.createQuery() de Hibernate, JdbcTemplate.query() de Spring JDBC, ou EntityManager.createQuery() de JPA, ce qui permet des attaques par injection SQL. Lorsque l'entrée de l'utilisateur est directement intégrée dans des chaînes de requêtes SQL (par exemple, statement.executeQuery("SELECT * FROM users WHERE id = $userId") ou en utilisant String.format() ou StringBuilder), les attaquants peuvent injecter du SQL malveillant pour contourner l'authentification, extraire des données sensibles, modifier le contenu de la base de données ou exécuter des opérations administratives. Contrairement aux langages avec des déclarations préparées, la concaténation de chaînes ne fournit pas de séparation entre le code SQL et les données, permettant aux attaquants de manipuler la logique des requêtes avec des caractères spéciaux tels que des guillemets, des commentaires (--) ou des mots-clés SQL. Cette vulnérabilité affecte toutes les opérations de base de données y compris les requêtes, les mises à jour et les appels de procédures stockées.
Remédiation :
Utilisez des requêtes paramétrées avec des variables de liaison via PreparedStatement JDBC, NamedParameterJdbcTemplate de Spring, ou le binding de paramètres dans JPA/Hibernate. Pour JDBC, remplacez la concaténation de chaînes par des espaces réservés : connection.prepareStatement("SELECT * FROM users WHERE id = ?").apply { setInt(1, userId) }. Pour Spring JDBC, utilisez des paramètres nommés : jdbcTemplate.queryForObject("SELECT * FROM users WHERE id = :id", mapOf("id" to userId), ...). Pour JPA/Hibernate, utilisez le binding de paramètres dans JPQL : entityManager.createQuery("... WHERE id = :id").setParameter("id", userId). Le framework Exposed de Kotlin fournit un DSL type-safe qui prévient les injections SQL par conception. Pour des requêtes dynamiques, utilisez des générateurs de requêtes comme jOOQ ou Exposed au lieu de concaténation de chaînes. Lors de l'utilisation de Spring Data JPA, exploitez les annotations @Query avec binding de paramètres ou des méthodes de requête dérivées qui sont sûres par défaut. N'utilisez jamais de modèles de chaînes ou de concaténation pour la construction SQL. Pour des requêtes dynamiques complexes, utilisez des générateurs de critères ou des patrons de spécification qui construisent des requêtes de manière programmatique avec une bonne paramétrisation. La bibliothèque JDBI offre une API fluide avec un binding automatique des paramètres pour les applications Kotlin.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_password_rule-ConstantDBPassword¶
Résumé :
Utilisation de mots de passe en dur
Gravité : Critique
CWE : CWE-259
Description :
Un mot de passe en dur a été détecté dans un appel à
java.sql.DriverManager.getConnection(). Cela est dangereux car les mots de passe
intégrés directement dans le code source peuvent être facilement extraits par quiconque ayant accès
au code source ou aux binaires compilés, entraînant un accès non autorisé à la base de données.
Les identifiants codés en dur rendent extrêmement difficile l'audit des accès, le changement
des identifiants compromis, ou l'application des politiques de sécurité à travers les environnements.
Remédiation :
Envisagez de charger les mots de passe de base de données à 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 d'un système de gestion des clés (KMS) qui fournit des journaux d'audit et une rotation facile des identifiants en cas de violation. Pour Google Cloud Platform, envisagez d'utiliser Cloud Key Management (https://cloud.google.com/kms/docs). Pour Amazon Web Services, envisagez AWS Key Management (https://aws.amazon.com/kms/). Pour des déploiements sur site ou des solutions agnostiques au cloud, envisagez Hashicorp Vault (https://www.vaultproject.io/). Alternativement, utilisez des variables d'environnement ou des fichiers de configuration avec des permissions restreintes, stockés en dehors du contrôle de version. Cette séparation garantit que les identifiants peuvent être gérés indépendamment du code de l'application et changés sans nécessiter de modifications de code.
OWASP :
- A2:2017-Authentification rompue
- A07:2021-Défauts d'identification et d'authentification
kotlin_password_rule-EmptyDBPassword¶
Résumé :
Authentification manquante pour une fonction critique (base de données)
Sévérité : Critique
CWE : CWE-306
Description :
Un mot de passe vide a été détecté dans un appel à
java.sql.DriverManager.getConnection(). Cela établit une connexion
à la base de données sans authentification, ce qui est dangereux car cela
permet à quiconque ayant un accès réseau à la base de données d'exécuter
des requêtes sans fournir d'identifiants. Cela viole le principe du moindre
privilège et peut entraîner un accès, une modification ou une suppression
non autorisée de données. Les connexions à la base de données non
authentifiées contournent les contrôles d'accès critiques et les mécanismes
de audit.
Remédiation :
Envisagez de configurer votre serveur de base de données pour exiger l'authentification et de restreindre les privilèges des utilisateurs uniquement aux requêtes et opérations nécessaires pour l'application. Consultez la documentation de votre serveur de base de données pour des instructions sur la création d'utilisateurs avec des mots de passe et la définition des permissions appropriées. Une fois l'authentification activée, chargez les identifiants à partir de sources externes sécurisées telles qu'un système de gestion de clés (KMS), qui fournit des journaux d'audit et des capacités de rotation des identifiants. Pour Google Cloud Platform, envisagez Cloud Key Management (https://cloud.google.com/kms/docs). Pour Amazon Web Services, envisagez AWS Key Management (https://aws.amazon.com/kms/). Pour les déploiements sur site ou agnostiques au cloud, envisagez Hashicorp Vault (https://www.vaultproject.io/). Alternativement, utilisez des variables d'environnement ou des fichiers de configuration externalisés avec des permissions de fichier restreintes, en veillant à ce que les identifiants ne soient jamais commis dans le contrôle de version.
OWASP :
- A2:2017-Autentification cassée
- A07:2021-Echecs d'identification et d'authentification
kotlin_script_rule-ScriptInjection¶
Résumé :
Contrôle inadéquat de la génération de code ('Injection de Code')
Sévérité : Critique
CWE : CWE-94
Description :
L'entrée contrôlée par l'utilisateur est transmise à des fonctions d'évaluation de script telles que
ScriptEngine.eval(), Invocable.invokeFunction() ou Invocable.invokeMethod().
Cela permet aux attaquants d'exécuter du code arbitraire dans le contexte de l'application,
ce qui peut conduire à un compromis complet 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 directes.
Remédiation :
Envisagez d'éviter l'utilisation de l'évaluation dynamique de scripts avec des entrées utilisateur. Il est recommandé de refactoriser le code pour utiliser des appels de méthodes 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 sur liste blanche pour les noms de fonctions et les paramètres. Ne jamais passer des entrées utilisateur non sanitizées à eval(), invokeFunction() ou invokeMethod(), car ces fonctions exécutent du code arbitraire avec les privilèges de l'application.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_smtp_rule-InsecureSmtp¶
Résumé :
Validation inappropriée du certificat avec correspondance d'hôte inexacte
Gravité : Critique
CWE : CWE-297
Description :
Configuration SMTP non sécurisée détectée avec les classes Apache Commons Email
(SimpleEmail, MultiPartEmail, HtmlEmail, ImageHtmlEmail) qui n'activent pas
la vérification de l'identité du serveur. Sans setSSLCheckServerIdentity(true),
l'application est vulnérable aux attaques de l'homme du milieu où des attaquants peuvent
intercepter les communications par email même lorsque SSL/TLS est activé.
Remédiation :
Envisagez d'activer la vérification de l'identité du serveur SSL en appelant
setSSLCheckServerIdentity(true) sur toutes les instances Apache Commons Email.
Il est recommandé d'utiliser toujours ce paramètre en conjonction avec
setSSLOnConnect(true) pour garantir à la fois le chiffrement et la validation appropriée
du certificat. Cela empêche les attaques de l'homme du milieu en vérifiant que le certificat du serveur correspond au nom d'hôte attendu avant de transmettre des contenus d'email sensibles.
OWASP :
- A3:2017-Exposition de données sensibles
- A02:2021-Panneaux cryptographiques
kotlin_smtp_rule-SmtpClient¶
Résumé :
Neutralisation incorrecte des éléments spéciaux utilisés dans une commande
Gravité : Critique
CWE : CWE-77
Description :
Vulnérabilité d'injection d'en-tête SMTP détectée dans les opérations MimeMessage. Cette règle
identifie les entrées utilisateur passées à MimeMessage.setSubject(), addHeader(),
setDescription(), ou setDisposition() sans désinfection. Les attaquants peuvent
injecter des caractères de retour chariot (CR) et de saut de ligne (LF) pour ajouter des en-têtes de courriel arbitraires, ce qui peut permettre le relais de spam, le phishing ou la manipulation de contenu de courriel.
Remédiation :
Envisagez de désinfecter les entrées utilisateur avant de les passer aux méthodes d'en-tête SMTP en
supprimant ou en remplaçant les caractères de nouvelle ligne (CR/LF). Il est recommandé d'utiliser des bibliothèques de courriel sûres comme Apache Commons Email ou Simple Java Mail, qui
filtrent automatiquement les caractères spéciaux pouvant mener à une injection d'en-tête.
Pour une désinfection manuelle, retirez les caractères \r et \n en utilisant
input.replace("\\r", "").replace("\\n", "") ou validez que l'entrée
ne contient aucun caractère de contrôle avant de construire les en-têtes de courriel.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_ssrf_rule-SSRF¶
Résumé :
Falsification de requête côté serveur (SSRF)
Gravité : Critique
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 Kotlin via java.net.URL, java.net.URI ou java.net.InetSocketAddress sans validation appropriée. Les motifs identifient des cas où des valeurs non littérales sont passées à des constructeurs comme URL(), URI(), ou InetSocketAddress(), suivies de méthodes telles que connect(), openConnection(), openStream(), getContent(), ou la propriété content. Lorsque l'entrée utilisateur contrôle des URLs ou des noms d'hôtes dans ces opérations réseau, des vulnérabilités de Falsification de requête côté serveur (SSRF) émergent, permettant aux attaquants de forcer le serveur à accéder à des ressources internes, à des points de terminaison de métadonnées cloud (169.254.169.254), à des interfaces administratives, ou d'effectuer des analyses réseau qui contournent les protections de pare-feu et la segmentation réseau.
Remédiation :
Envisagez de mettre en œuvre une liste d'autorisation strictes d'URL qui valide l'entrée utilisateur par rapport aux domaines approuvés avant de construire des objets URL ou URI. Utilisez les fonctions d'extension de Kotlin avec java.net.URI pour analyser et valider les composants de schéma, d'hôte et de port, en rejetant toutes les URLs qui ne correspondent pas à la liste d'autorisation. 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 d'adresses IP privées (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) et des adresses de métadonnées cloud (169.254.169.254). Pour les applications Kotlin utilisant OkHttp ou d'autres clients HTTP, configurez des intercepteurs personnalisés ou des résolveurs DNS qui appliquent un filtrage d'adresses IP. Les défenses au niveau réseau peuvent inclure l'exécution de l'application dans des environnements conteneurisés avec des règles de filtrage egress qui empêchent les connexions aux réseaux internes. Envisagez d'utiliser une approche de mappage côté serveur où l'entrée utilisateur fournit des clés qui correspondent à des URLs sûres préconfigurées plutôt que d'accepter des URLs arbitraires.
OWASP :
- A1:2017-Injection
- A10:2021-Falsification de requête côté serveur
kotlin_strings_rule-FormatStringManipulation¶
Résumé :
Utilisation d'une chaîne de format contrôlée par l'extérieur
Gravité : Critique
CWE : CWE-134
Description :
L'utilisation des entrées utilisateur provenant de HttpServletRequest.getParameter() directement dans les méthodes de chaînes de format telles que String.format(), Formatter.format(), PrintStream.printf(), ou PrintStream.format() crée une vulnérabilité d'injection de chaîne de format. Les attaquants peuvent injecter des spécificateurs de format malveillants (comme %s, %x, %n) pour provoquer des exceptions qui font planter l'application, ou utiliser des spécificateurs de format pour accéder et divulguer des données sensibles à partir des arguments non utilisés passés à la fonction de formatage. Cela est particulièrement dangereux lorsque la chaîne de format est concaténée avec des entrées utilisateur sans une sanitation appropriée.
Remédiation :
Envisagez de traiter la chaîne de format comme une constante et d'utiliser les entrées utilisateur uniquement comme arguments à la fonction de formatage, jamais comme partie de la chaîne de format elle-même. Par exemple, au lieu de String.format(userInput + " result", value), utilisez String.format("%s result", userInput) où la chaîne de format "%s result" est codée en dur et sûre. Si un formatage dynamique est nécessaire, mettez en œuvre une liste blanche stricte des motifs de format autorisés et validez les entrées utilisateur par rapport à cette liste avant utilisation. Alternativement, utilisez une simple concaténation de chaînes ou des chaînes de modèles où les spécificateurs de format ne peuvent pas être injectés. Il est recommandé de sanitiser ou de rejeter toute entrée contenant des caractères de spécificateurs de format comme '%' lors de la construction des chaînes de format, et d'envisager l'utilisation de frameworks de journalisation structurés qui séparent les modèles de messages des données utilisateur.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_templateinjection_rule-TemplateInjection¶
Résumé :
Contrôle inapproprié de la génération de code ('Injection de Code')
Gravité : Critique
CWE : CWE-94
Description :
Une vulnérabilité d'injection de template côté serveur a été détectée dans les moteurs de template Velocity, FreeMarker ou Pebble. Les entrées contrôlées par l'utilisateur sont directement transmises à des méthodes de template telles que 'Velocity.evaluate()', 'Configuration.getTemplate()', ou 'PebbleEngine.getTemplate().evaluate()'. Cela permet aux attaquants d'injecter du code template malveillant qui exécute du code arbitraire sur le serveur.
Remédiation :
Envisagez d'utiliser une configuration de template sécurisée qui limite l'accès aux templates uniquement à des emplacements de confiance. Il est recommandé d'utiliser 'VelocityContext' avec des variables prédéfinies au lieu de passer directement les entrées de l'utilisateur dans les chaînes de template ou les noms de template. Ne jamais permettre aux entrées de l'utilisateur de contrôler le contenu du template ou les chemins de fichiers de template. Validez et assainissez toutes les entrées utilisées dans les opérations de template selon une liste d'autorisation stricte des valeurs permises.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_xpathi_rule-XpathInjection¶
Résumé :
Neutralisation inappropriée des données au sein des expressions XPath ('Injection XPath')
Sévérité : Critique
CWE : CWE-643
Description :
Vulnérabilité d'injection XPath détectée lorsque l'entrée utilisateur est passée à
XPath.compile() ou XPath.evaluate() sans désinfection appropriée. Cela
permet à des attaquants de manipuler des requêtes XPath pour extraire des données non autorisées de
documents XML ou contourner des contrôles de sécurité. Les entrées non fiables doivent être correctement
paramétrées avant d'être utilisées dans des expressions XPath.
Remédiation :
Envisagez d'utiliser XPathVariableResolver pour paramétrer les requêtes XPath au lieu
de concaténer directement l'entrée utilisateur dans les expressions XPath. Il est recommandé de
faire appel à setXPathVariableResolver() sur l'objet XPath et de référencer
les variables dans la chaîne de requête en utilisant la syntaxe $variableName. Si
la paramétrisation n'est pas faisable, validez et désinfectez toutes les entrées utilisateur
conformément à une liste d'autorisation stricte avant leur inclusion dans les expressions XPath.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_xxe_rule-SaxParserXXE¶
Résumé :
Restriction inappropriée de la référence d'entité externe XML ('XXE')
Gravité : Critique
CWE : CWE-611
Description :
L'application utilise SAXParserFactory.newInstance() et newSAXParser() pour créer
un analyseur XML sans désactiver le traitement des entités externes, ce qui la rend vulnérable aux
attaques par entité externe XML (XXE). Lorsque l'analyseur SAX traite une entrée XML non
fiable sans les caractéristiques 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 via des canaux hors bande, ou provoquer une déni de service grâce
à des attaques d'expansion d'entité comme le milliard de rires.
Remédiation :
Configurer 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 l'analyseur. Cela prévient toutes les vulnérabilités XXE, les attaques d'expansion d'entité
et le déni de service par milliard de rires 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);
Guide supplémentaire sur
https://cheatsheatseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#java
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_xxe_rule-XMLRdr¶
Résumé :
Restriction incorrecte de la référence d'entité externe XML ('XXE')
Gravité : Critique
CWE : CWE-611
Description :
L'application utilise XMLReaderFactory.createXMLReader() pour créer un parseur XML sans désactiver le traitement des entités externes, la rendant vulnérable aux attaques par entité externe XML (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 depuis le système de fichiers, mener des attaques SSRF contre des services réseau internes, exfiltrer des données sensibles ou provoquer des dénis de service par des attaques d'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 d'expansion d'entités et le déni de service "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
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_xxe_rule-XMLStreamRdr¶
Résumé :
Restriction inadéquate de la référence aux entités externes XML ('XXE')
Sévérité : Critique
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és externes XML (XXE). Lorsque le XMLStreamReader traite
des entrées XML non fiables avec le support DTD et les entités externes activées, les attaquants peuvent
en profiter pour lire des fichiers arbitraires, effectuer des attaques SSRF sur 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 d'expansion d'entité en milliard de rires et d'explosion quadratique.
Remédiation :
Configurez 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 les dénis de service
par milliard de rires 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); Des conseils supplémentaires sont disponibles sur
https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#java
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_password_rule-HardcodePassword¶
Résumé :
Utilisation de mots de passe codés en dur
Gravité : Élevée
CWE : CWE-259
Description :
Un mot de passe codé en dur a été détecté dans des API cryptographiques ou d'authentification sensibles, y compris KeyStore.load(), PBEKeySpec(), PasswordAuthentication(), KeyManagerFactory.init(), DriverManager.getConnection(), et des méthodes connexes. C'est dangereux car les mots de passe intégrés directement dans le code source peuvent être facilement extraits par quiconque ayant accès à la base de code, à du bytecode décompilé ou à des artefacts binaires. Les identifiants codés en dur ne peuvent pas être changés sans modifications du code, rendent l'audit d'accès presque impossible, et exposent les systèmes à des compromissions si le code source ou l'application compilée est divulguée.
Remédiation :
Envisagez de charger les mots de passe et les identifiants sensibles à partir de sources externes sécurisées au lieu de les coder en dur dans votre application. Les approches recommandées incluent l'utilisation d'un Système de Gestion des Clés (KMS) qui fournit une gestion centralisée des identifiants, une journalisation des audits et une rotation facile en cas de violations de sécurité. Pour Google Cloud Platform, envisagez Cloud Key Management (https://cloud.google.com/kms/docs). Pour Amazon Web Services, envisagez AWS Key Management (https://aws.amazon.com/kms/). Pour les déploiements sur site ou des solutions agnostiques au cloud, envisagez Hashicorp Vault (https://www.vaultproject.io/). D'autres options sécurisées incluent les variables d'environnement, les fichiers de configuration externalisés avec des permissions restreintes, ou des outils de gestion des secrets spécifiques à votre plateforme de déploiement. Assurez-vous que les identifiants ne sont jamais engagés dans des systèmes de contrôle de version et sont gérés indépendamment du code de l'application pour permettre une rotation sans déploiement.
OWASP :
- A2:2017-Autentification Cassée
- A07:2021-Échecs d'Identification et d'Authentification
kotlin_cookie_rule-CookieHTTPOnly¶
Résumé :
Cookie sensible sans le drapeau 'HttpOnly'
Sévérité : Moyenne
CWE : CWE-1004
Description :
L'application crée un objet javax.servlet.http.Cookie et l'ajoute à la
HttpServletResponse en utilisant addCookie() sans appeler setHttpOnly(true) sur l'instance du cookie. Le drapeau HttpOnly est une directive de sécurité du navigateur qui empêche
le JavaScript côté client d'accéder au cookie via document.cookie. Lorsqu'un utilisateur
devient la cible d'une attaque Cross-Site Scripting (XSS), un attaquant peut voler
des cookies sensibles tels que des identifiants de session, des jetons d'authentification ou d'autres données critiques pour la sécurité qui devraient rester uniquement côté serveur.
Remédiation :
Envisagez d'appeler setHttpOnly(true) sur tous les objets Cookie contenant des données sensibles avant de les ajouter à la réponse. Cela doit être fait immédiatement après
l'instanciation du cookie : val cookie = Cookie("sessionId", value); cookie.setHttpOnly(
true); response.addCookie(cookie). Le drapeau HttpOnly est particulièrement critique pour
les cookies de session, les jetons d'authentification et les jetons CSRF qui ne devraient jamais être accessibles
au JavaScript. Notez que les cookies HttpOnly peuvent toujours être envoyés au serveur dans les requêtes
et accessibles par du code côté serveur, donc cette protection n'interfère pas avec les flux d'authentification normaux. Pour les applications Spring Boot, il est recommandé de configurer les cookies de session globalement via server.servlet.session.cookie.http-only=true dans les propriétés de l'application plutôt que de gérer cela par cookie.
OWASP :
- A6:2017-Misconfiguration de la sécurité
- A05:2021-Misconfiguration de la sécurité
kotlin_cookie_rule-CookieInsecure¶
Résumé :
Cookie sensible dans la session HTTPS sans attribut 'Secure'
Gravité : Moyenne
CWE : CWE-614
Description :
L'application crée un objet javax.servlet.http.Cookie et l'ajoute à la
HttpServletResponse en utilisant addCookie() sans appeler setSecure(true) sur l'instance du cookie. Le flag Secure est une directive de sécurité du navigateur qui instructe le navigateur à ne transmettre le cookie que sur des connexions HTTPS. Sans ce flag, les cookies peuvent être transmis sur des connexions HTTP non chiffrées, les exposant à l'écoute réseau et aux attaques de type man-in-the-middle, où des attaquants sur le chemin réseau peuvent intercepter des valeurs de cookies sensibles, y compris des identifiants de session et des jetons d'authentification.
Remédiation :
Pensez à appeler setSecure(true) sur tous les objets Cookie contenant des données sensibles avant de les ajouter à la réponse. Cela doit être fait immédiatement après l'instanciation du cookie : val cookie = Cookie("sessionId", value); cookie.setSecure(true); response.addCookie(cookie). Le flag Secure est essentiel pour tout cookie contenant des informations critiques en matière de sécurité lorsque votre application est servie via HTTPS. Soyez conscient que le paramétrage de ce flag empêche l'envoi du cookie sur des connexions HTTP, donc assurez-vous que votre application impose HTTPS pour toutes les pages authentifiées. Pour les applications Spring Boot, il est recommandé de configurer les cookies de session globalement via server.servlet.session.cookie.secure=true dans les propriétés de l'application, et envisagez d'activer server.ssl.enabled=true avec des en-têtes HSTS pour imposer HTTPS dans l'ensemble de l'application.
OWASP :
- A6:2017-Mauvaise configuration de la sécurité
- A05:2021-Mauvaise configuration de la sécurité
kotlin_cookie_rule-HttpResponseSplitting¶
Résumé :
Neutralisation inappropriée des séquences CRLF dans les en-têtes HTTP ('Fractionnement de la réponse HTTP')
Gravité : Moyenne
CWE : CWE-113
Description :
L'application transmet des entrées contrôlées par l'utilisateur provenant des méthodes HttpServletRequest (comme
getParameter(), getHeader(), ou getPathInfo()) directement au constructeur javax.servlet.http.Cookie
ou à la méthode setValue() sans une désinfection appropriée des caractères CR (\r) et LF (\n). Lorsque ces caractères CRLF atteignent les en-têtes de réponse HTTP, le serveur peut les interpréter comme des terminators d'en-tête, entraînant l'analyse du flux de sortie en tant que deux réponses HTTP distinctes au lieu d'une seule. Les attaquants peuvent en profiter en injectant des en-têtes HTTP supplémentaires et des corps de réponse pour mener des attaques de Cross-Site Scripting (XSS), de contamination de cache ou de fixation de session où ils contrôlent le contenu de la seconde réponse injectée.
Remédiation :
Envisagez de désinfecter toutes les entrées utilisateur avant de les utiliser dans les valeurs de cookie en supprimant ou en remplaçant les caractères CR (\r) et LF (\n). Utilisez String.replace() avec un modèle regex comme [\\r\\n]+ pour éliminer ces caractères : val sanitized = userInput.replace(Regex("[\\r\\n]+"), ""). Alternativement, vous pouvez utiliser org.apache.commons.text.StringEscapeUtils.escapeJava() qui échappe correctement les caractères de contrôle, y compris les séquences CRLF. Il est recommandé de mettre en œuvre une validation des entrées qui rejette les requêtes contenant des caractères de contrôle inattendus plutôt que de tenter de les désinfecter, car cela procure une défense en profondeur. Les conteneurs de servlets modernes (Servlet 3.0+) offrent une certaine protection contre le fractionnement de réponse, mais la validation au niveau de l'application reste essentielle, car les protections du conteneur peuvent ne pas couvrir tous les vecteurs d'attaque. Envisagez d'utiliser un pare-feu d'application web (WAF) comme une couche de protection supplémentaire pour détecter et bloquer les tentatives de fractionnement de réponse HTTP.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_crypto_rule-BlowfishKeySize¶
Résumé :
Force de chiffrement inadéquate
Gravité : 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. Blowfish
prend en charge des tailles de clé allant de 32 à 448 bits, mais les clés de moins de 128 bits offrent une sécurité inadéquate pour les applications modernes. De plus, Blowfish a 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 rendant inadapté aux scénarios de chiffrement à fort débit.
Remédiation :
Envisagez de migrer vers AES-256-GCM pour un chiffrement authentifié, qui est la norme recommandée
pour les applications modernes. Utilisez javax.crypto.KeyGenerator.getInstance("AES") avec
keyGen.init(256) pour générer des clés de 256 bits. Pour les scénarios nécessitant un
chiffrement authentifié, utilisez le mode GCM avec Cipher.getInstance("AES/GCM/NoPadding") qui fournit
à la fois protection de la confidentialité et de l'intégrité sans nécessiter d'implémentation manuelle de MAC.
Si Blowfish doit être utilisé pour des raisons de compatibilité héritée, assurez-vous que les tailles de clé sont d'au moins 128
bits en appelant keyGen.init(128) ou plus. Pour de nouvelles applications Kotlin, envisagez d'utiliser
la bibliothèque de cryptographie Tink qui offre des valeurs par défaut sécurisées et prévient les problèmes de
mauvaise configuration courants.
OWASP :
- A3:2017-Exposition des données sensibles
- A02:2021-Échecs cryptographiques
kotlin_crypto_rule-CipherDESInsecure¶
Résumé :
Force de chiffrement inadéquate
Gravité : Moyenne
CWE : CWE-326
Description :
L'application utilise javax.crypto.Cipher.getInstance() avec le chiffrement DES, qui est cryptographiquement cassé et ne devrait pas être utilisé pour les applications modernes. Le DES a une longueur de clé effective de 56 bits, ce qui le rend vulnérable aux attaques par force brute, avec des démonstrations pratiques de rupture du DES en moins de 24 heures en utilisant du matériel spécialisé. La petite taille de bloc de 64 bits rend également le DES susceptible aux attaques d'anniversaire. Le NIST a officiellement déprécié le DES en 2005 et recommande l'AES comme norme de remplacement pour le chiffrement symétrique.
Remédiation :
Remplacez le DES par l'AES-256-GCM pour un chiffrement authentifié en utilisant
javax.crypto.Cipher.getInstance("AES/GCM/NoPadding"). Générer des clés AES avec
javax.crypto.KeyGenerator.getInstance("AES") et initialisez avec une taille de clé de 256 bits en utilisant
keyGen.init(256). Le mode GCM offre à la fois le chiffrement et l'authentification, protégeant
contre la falsification sans nécessiter une mise en œuvre MAC distincte. Assurez-vous d'un bon traitement des IV/nonces en générant des nonces aléatoires de 12 octets avec java.security.SecureRandom pour chaque
opération de chiffrement et ne réutilisez jamais les nonces avec la même clé. Pour les projets Kotlin,
envisagez d'utiliser la bibliothèque Tink de Google qui fournit des API cryptographiques sûres avec des
paramètres par défaut sécurisés et prévient les erreurs d'implémentation courantes.
OWASP :
- A3:2017-Exposition de données sensibles
- A02:2021-Failles cryptographiques
kotlin_crypto_rule-CipherDESedeInsecure¶
Résumé :
Utilisation d'un algorithme cryptographique défectueux ou risqué
Sévérité : Moyenne
CWE : CWE-327
Description :
L'application utilise javax.crypto.Cipher.getInstance() avec le chiffrement Triple DES (DESede/3DES), qui est obsolète et n'est plus recommandé pour les applications modernes. Bien que le Triple DES ait été conçu pour remédier aux vulnérabilités du DES en appliquant le chiffre trois fois, il souffre toujours de la limitation de taille de bloc de 64 bits, ce qui le rend vulnérable aux attaques par anniversaire après avoir chiffré environ 32 Go de données avec la même clé. Le NIST a officiellement déclaré le Triple DES obsolète pour les nouvelles applications en 2017 et a interdit son utilisation après 2023, recommandant l'AES comme norme de remplacement.
Remédiation :
Migrate vers AES-256-GCM pour un chiffrement authentifié moderne en utilisant javax.crypto.Cipher.getInstance("AES/GCM/NoPadding"). Générez des clés AES de 256 bits avec javax.crypto.KeyGenerator.getInstance("AES") et keyGen.init(256). Le mode GCM offre à la fois confidentialité et authenticité sans nécessiter d'implémentation manuelle de MAC, et présente de meilleures performances que le Triple DES sur le matériel moderne. Générez des nonces uniques de 12 octets pour chaque opération de chiffrement en utilisant java.security.SecureRandom et ne réutilisez jamais les nonces avec la même clé, car cela compromet catastrophiquement la sécurité du GCM. Pour les applications Kotlin, envisagez d'utiliser la bibliothèque de cryptographie Tink qui fournit des API de haut niveau avec des valeurs par défaut sécurisées et une protection intégrée contre les pièges cryptographiques courants.
OWASP :
- A3:2017-Exposition de données sensibles
- A02:2021-Échecs cryptographiques
kotlin_crypto_rule-CustomMessageDigest¶
Résumé :
Utilisation d'un algorithme cryptographique défectueux ou risqué
Gravité : Moyenne
CWE : CWE-327
Description :
L'application implémente une classe personnalisée étendant java.security.MessageDigest, qui est
extrêmement sujette aux erreurs et susceptible d'introduire des vulnérabilités cryptographiques. Concevoir des
fonctions de hachage sécurisées nécessite une expertise approfondie en cryptanalyse, et même de
minimes erreurs d'implémentation peuvent complètement compromettre des propriétés de sécurité comme la résistance aux collisions et la résistance à l'image pré-image. Les implémentations de hachage personnalisées sont sensibles aux attaques par extension de longueur, aux effets d'avalanche faibles et aux faiblesses cryptanalytiques qui peuvent ne pas être immédiatement apparentes. Le NIST recommande
d'utiliser des fonctions de hachage prouvées et bien analysées des familles SHA-2 ou SHA-3.
Remédiation :
Utilisez des fonctions de hachage standard du secteur fournies par les fournisseurs de sécurité de Java au lieu d'implémenter des résumés personnalisés. Pour le hachage à usage général, utilisez java.security.MessageDigest.getInstance("SHA-256")
qui offre une excellente sécurité et performance. Pour les applications nécessitant des marges de sécurité plus élevées, utilisez SHA-512 avec MessageDigest.getInstance("SHA-512"). Si le hachage de mots de passe est l'objectif, utilisez des algorithmes de hachage de mots de passe dédiés comme Argon2, bcrypt, ou scrypt via la bibliothèque Bouncy Castle, car les fonctions de hachage à usage général ne conviennent pas au stockage de mots de passe. Pour les opérations HMAC, utilisez javax.crypto.Mac.getInstance("HmacSHA256") plutôt que d'implémenter manuellement HMAC avec des résumés personnalisés. Les applications Kotlin peuvent également utiliser la bibliothèque Tink de Google qui fournit des API de hachage sûres avec des paramètres par défaut sécurisés.
OWASP :
- A6:2017-Misconfiguration de sécurité
- A04:2021-Conception non sécurisée
kotlin_crypto_rule-HazelcastSymmetricEncryption¶
Résumé :
Force de chiffrement inadéquate
Sévérité : Moyenne
CWE : CWE-326
Description :
L'application configure les communications réseau de Hazelcast en utilisant
com.hazelcast.config.SymmetricEncryptionConfig(), qui par défaut utilise généralement des
chiffres symétriques faibles comme DES ou Blowfish, ne fournissant ni protection d'intégrité ni
authentification sécurisée. Le chiffrement symétrique à lui seul ne peut pas empêcher les attaques de type "homme du milieu" ni vérifier l'identité des membres du cluster, permettant aux attaquants de rejoindre potentiellement le cluster ou d'intercepter des données sensibles. De plus, les chiffres symétriques par défaut dans les versions plus anciennes de Hazelcast sont cryptographiquement faibles et vulnérables à des attaques pratiques.
Remédiation :
Utilisez le chiffrement TLS/SSL de Hazelcast au lieu du chiffrement symétrique en configurant
SSLConfig avec une authentification basée sur des certificats appropriés. Cela fournit à la fois le chiffrement et une authentification mutuelle entre les membres du cluster, empêchant les nœuds non autorisés de se joindre. Configurez TLS avec config.networkConfig.sslConfig et utilisez des suites de chiffrement fortes en définissant
sslConfig.setProperty("javax.net.ssl.cipherSuites", "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384").
Assurez-vous que les certificats sont correctement validés et utilisez les protocoles modernes TLS 1.2 ou 1.3. Pour une sécurité supplémentaire, activez l'authentification des membres de Hazelcast en utilisant des secrets partagés ou intégrez-vous aux systèmes d'authentification d'entreprise. Évitez d'utiliser le chiffrement symétrique sauf si cela est nécessaire pour des scénarios de compatibilité héritée spécifiques, et si nécessaire, assurez-vous que des algorithmes forts comme AES-256 sont configurés explicitement.
OWASP :
- A3:2017-Exposition de données sensibles
- A02:2021-Échecs cryptographiques
kotlin_crypto_rule-TailleDeCléInsuffisanteRsa¶
Résumé :
Force de chiffrement inadéquate
Gravité : Moyenne
CWE : CWE-326
Description :
L'application utilise KeyPairGenerator.getInstance() avec les algorithmes RSA ou DSA et initialise les clés avec des tailles inférieures à 2048 bits, offrant une sécurité insuffisante pour les applications modernes. Les clés RSA et DSA de moins de 2048 bits sont vulnérables aux attaques par factorisation utilisant des ressources informatiques de plus en plus puissantes. Le NIST a déclaré obsolètes les clés RSA/DSA de 1024 bits en 2013 et recommande désormais des clés d'au moins 2048 bits pour une sécurité jusqu'en 2030, avec des clés de 3072 bits recommandées pour une protection à long terme. Des tailles de clé plus petites peuvent être compromises par des adversaires bien financés ou devenir vulnérables à mesure que la puissance de calcul augmente.
Remédiation :
Utilisez des clés d'au moins 2048 bits pour RSA et DSA en appelant keyGen.initialize(2048) lors de l'initialisation du KeyPairGenerator. Pour les applications nécessitant une sécurité au-delà de 2030, envisagez des clés de 3072 bits ou 4096 bits avec keyGen.initialize(3072). Pour de nouvelles applications, envisagez fortement de migrer vers la cryptographie à courbe elliptique (ECC) en utilisant l'algorithme ECDSA avec les courbes P-256 ou P-384, qui offrent une sécurité équivalente à RSA-2048/3072 avec des tailles de clé significativement plus petites et de meilleures performances. Utilisez KeyPairGenerator.getInstance("EC") et spécifiez les courbes via ECGenParameterSpec("secp256r1") pour P-256 ou ECGenParameterSpec("secp384r1") pour P-384. Pour les applications Kotlin, envisagez d'utiliser la bibliothèque Tink qui fournit une génération de clés sécurisée avec des valeurs par défaut sécurisées.
OWASP :
- A3:2017-Exposition de Données Sensibles
- A02:2021-Failles Cryptographiques
kotlin_crypto_rule-NullCipher¶
Résumé :
Utilisation d'un algorithme cryptographique cassé ou risqué
Gravité : Moyenne
CWE : CWE-327
Description :
L'application utilise javax.crypto.NullCipher(), qui implémente l'interface Cipher en renvoyant un texte chiffré identique au texte clair fourni, ne fournissant absolument aucune cryptographie ni sécurité. NullCipher est destiné uniquement aux scénarios de test où le chiffrement doit être temporairement désactivé, mais son utilisation accidentelle dans le code de production introduit des risques de confidentialité catastrophiques. Les données chiffrées avec NullCipher sont transmises et stockées en texte clair, exposant des informations sensibles à quiconque ayant accès au réseau ou au stockage. Cela est particulièrement dangereux lorsque la logique de chiffrement est activée conditionnellement, car une erreur de configuration pourrait désactiver silencieusement tout chiffrement.
Remédiation :
Remplacez NullCipher par un chiffrement authentifié approprié utilisant AES-256-GCM via
javax.crypto.Cipher.getInstance("AES/GCM/NoPadding"). Générez des clés AES appropriées avec
javax.crypto.KeyGenerator.getInstance("AES") et keyGen.init(256). Pour les scénarios de test nécessitant la désactivation du chiffrement, utilisez l'injection de dépendances ou des drapeaux de fonctionnalités pour contrôler la sélection des ciphers, et assurez-vous que les configurations uniquement pour les tests ne peuvent pas être déployées accidentellement en production. Envisagez d'utiliser des interfaces distinctes pour les implémentations de ciphers de test et de production, avec des vérifications à la compilation pour empêcher l'inclusion de NullCipher dans les builds de production. Pour les projets Kotlin, utilisez la bibliothèque Tink de Google qui fournit des primitives de cryptographie sûres et rend impossible l'utilisation accidentelle de NullCipher via ses API de haut niveau.
OWASP :
- A3:2017-Exposition de données sensibles
- A02:2021-Failles cryptographiques
kotlin_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 sans rembourrage approprié (NoPadding), ce qui est cryptographiquement peu sûr et vulnérable à plusieurs attaques. RSA sans rembourrage est déterministe, ce qui signifie que des textes en clair identiques produisent des textes chiffrés identiques, permettant aux attaquants d'identifier des motifs et des données répétées. Il est également vulnérable aux attaques par texte chiffré choisi où les attaquants peuvent manipuler le texte chiffré pour créer des textes en clair liés, et il ne fournit pas de sécurité sémantique. Des schémas de rembourrage appropriés comme OAEP (Optimal Asymmetric Encryption Padding) ajoutent du hasard et une structure pour prévenir ces attaques et garantir que le chiffrement RSA est non déterministe et sécurisé.
Remédiation :
Utilisez RSA avec rembourrage OAEP en spécifiant javax.crypto.Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding") pour les opérations de chiffrement. OAEP ajoute du hasard et des protections structurelles qui rendent le chiffrement RSA sémantiquement sécurisé et résistant aux attaques. Pour les signatures numériques, utilisez le rembourrage PSS avec Signature.getInstance("SHA256withRSA/PSS") qui offre des garanties de sécurité plus fortes que le rembourrage PKCS1. Notez que RSA est coûteux en termes de calcul et ne devrait généralement être utilisé que pour chiffrer des clés symétriques ou de petites quantités de données, et non pour le chiffrement de masse. Pour chiffrer de grandes quantités de données, utilisez le chiffrement hybride où RSA chiffre une clé AES, et AES-GCM chiffre les données réelles. Pour les applications Kotlin modernes, envisagez d'utiliser la bibliothèque Tink de Google qui impose des schémas de rembourrage appropriés et empêche les configurations incorrectes courantes de RSA.
OWASP :
- A3:2017-Exposition de données sensibles
- A02:2021-Failles cryptographiques
kotlin_crypto_rule-WeakMessageDigest¶
Résumé :
Utilisation d'un algorithme cryptographique cassé ou risqué (SHA1/MD5)
Gravité : Moyenne
CWE : CWE-327
Description :
L'application utilise MessageDigest.getInstance() ou Signature.getInstance() avec
des algorithmes de hachage cryptographiquement cassés, y compris MD2, MD4, MD5 ou SHA-1. Ces algorithmes
sont vulnérables aux attaques par collision où les attaquants peuvent créer deux entrées différentes qui
produisent le même résultat de hachage. Les collisions MD5 sont pratiques depuis 2004, et les collisions SHA-1
ont été démontrées en 2017 avec l'attaque SHAttered. L'utilisation de ces algorithmes pour
les signatures numériques permet aux attaquants de forger des signatures, et leur utilisation pour la vérification
de l'intégrité permet une falsification non détectée. Le NIST a déconseillé SHA-1 pour les signatures numériques en
2011 et pour tous les usages cryptographiques après 2030.
Remédiation :
Migrez vers des fonctions de hachage sécurisées des familles SHA-2 ou SHA-3. Pour un hachage à usage général
et une vérification de l'intégrité, utilisez SHA-256 avec MessageDigest.getInstance("SHA-256").
Pour les signatures numériques, utilisez SHA-256 ou plus fort avec Signature.getInstance("SHA256withRSA")
ou Signature.getInstance("SHA256withECDSA"). Pour les applications nécessitant des marges de sécurité plus
élevées ou une protection à long terme, utilisez SHA-512 avec MessageDigest.getInstance("SHA-512").
Pour les opérations HMAC, utilisez javax.crypto.Mac.getInstance("HmacSHA256"). Si le hachage de mot de passe
est le cas d'utilisation, n'utilisez pas de fonctions de hachage à usage général ; utilisez plutôt des algorithmes
de hachage de mot de passe dédiés comme Argon2, bcrypt ou scrypt via la bibliothèque Bouncy Castle. Pour les
applications Kotlin, envisagez d'utiliser la bibliothèque Tink de Google qui fournit des API de hachage sûres avec
des défauts sécurisés et empêche l'utilisation d'algorithmes faibles.
OWASP :
- A6:2017-Mauvaise Configuration de Sécurité
- A04:2021-Conception Insecure
kotlin_crypto_rule-WeakTLSProtocol¶
Résumé :
Validation de certificat inadéquate
Gravité : Moyenne
CWE : CWE-295
Description :
L'application utilise des configurations TLS/SSL obsolètes et non sécurisées, y compris
org.apache.http.impl.client.DefaultHttpClient() ou javax.net.ssl.SSLContext.getInstance("SSL").
DefaultHttpClient de Apache HttpClient 4.x est obsolète et utilise des paramètres par défaut non sécurisés, y compris
l'acceptation de versions de protocole TLS/SSL dépassées vulnérables à des attaques connues. Le contexte générique "SSL"
peut activer SSL 3.0, TLS 1.0 et TLS 1.1, qui ont tous des vulnérabilités connues
y compris POODLE, BEAST et d'autres qui permettent aux attaquants de déchiffrer le trafic ou de réaliser
des attaques de type "man-in-the-middle". Les applications modernes devraient utiliser exclusivement TLS 1.2 ou TLS 1.3.
Remédiation :
Pour les clients HTTP, migrez de l'Apache HttpClient obsolète vers des alternatives modernes comme
OkHttp ou utilisez le HttpClient intégré de Java 11 qui a des paramètres par défaut sécurisés. Si Apache HttpClient
doit être utilisé, mettez à niveau vers HttpClient 5.x et configurez explicitement TLS 1.2+ avec une validation de certificat appropriée. Pour SSLContext, utilisez SSLContext.getInstance("TLSv1.2") ou
SSLContext.getInstance("TLSv1.3") au lieu des options génériques "SSL" ou "TLS" pour garantir
que seules les versions de protocole sécurisées sont activées. Configurez les protocoles activés explicitement avec
sslEngine.setEnabledProtocols(arrayOf("TLSv1.2", "TLSv1.3")) et spécifiez des suites de chiffrement fortes
qui supportent la confidentialité persistante. Pour les projets Kotlin utilisant OkHttp, configurez le client
avec ConnectionSpec.MODERN_TLS pour imposer automatiquement TLS 1.2+, ou utilisez
ConnectionSpec.RESTRICTED_TLS pour la configuration la plus sécurisée.
OWASP :
- A3:2017-Exposition de données sensibles
- A02:2021-Failles cryptographiques
kotlin_crypto_rule-WeakTLSProtocolVersion¶
Résumé :
Force de chiffrement inadéquate
Gravité : Moyenne
CWE : CWE-326
Description :
L'application utilise javax.net.ssl.SSLContext.getInstance() ou
SSLEngine.setEnabledProtocols() pour activer des versions de protocole TLS non sécurisées, y compris SSL,
TLS 1.0, TLS 1.1, ou DTLS 1.0/1.1. Ces protocoles présentent des vulnérabilités connues telles que
POODLE (SSL 3.0), BEAST (TLS 1.0) et des suites de chiffrement faibles qui permettent aux attaquants de déchiffrer
le trafic, d'effectuer des attaques de dégradation ou de mener des attaques de l'homme du milieu. PCI DSS et d'autres
cadres de conformité exigent la désactivation des versions de TLS antérieures à 1.2. S'appuyer sur les valeurs par défaut du système
est insuffisant, car les applications peuvent être déployées sur des systèmes plus anciens avec des configurations par défaut non sécurisées, et une configuration explicite est nécessaire pour garantir la conformité et la sécurité.
Remédiation :
Configurez explicitement TLS 1.2 ou TLS 1.3 comme versions de protocole minimales en utilisant
SSLContext.getInstance("TLSv1.2") ou SSLContext.getInstance("TLSv1.3"). Si vous utilisez le
contexte générique "TLS", restreignez explicitement les protocoles activés avec
sslEngine.setEnabledProtocols(arrayOf("TLSv1.2", "TLSv1.3")) pour remplacer les valeurs par défaut potentiellement
non sécurisées. Pour le DTLS (Datagram TLS), utilisez SSLContext.getInstance("DTLSv1.2") ou
DTLSv1.3. Configurez des suites de chiffrement robustes qui supportent la confidentialité à long terme en définissant
sslEngine.setEnabledCipherSuites() avec des suites comme TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
Pour les applications Kotlin utilisant OkHttp, configurez avec ConnectionSpec.MODERN_TLS ou
ConnectionSpec.RESTRICTED_TLS pour appliquer automatiquement des versions de protocole sécurisées. Évitez
de vous fier aux valeurs par défaut du système ; spécifiez explicitement les configurations de sécurité dans tous les environnements de déploiement pour garantir la conformité et une posture de sécurité cohérente.
OWASP :
- A3:2017-Exposition de données sensibles
- A02:2021-Pannes cryptographiques
kotlin_csrf_rule-SpringCSRFDisabled¶
Résumé :
Falsification de Requête Inter-Site (CSRF)
Sévérité : Moyenne
CWE : CWE-352
Description :
La protection CSRF a été explicitement désactivée à l'aide de HttpSecurity.csrf().disable()
ou CsrfConfigurer.disable(). Cela supprime les protections contre les attaques de
Falsification de Requête Inter-Site, permettant à des sites Web malveillants de tromper
des utilisateurs authentifiés en les incitant à effectuer des actions non désirées.
Sans protection CSRF, les attaquants peuvent falsifier des requêtes qui semblent
légitimes, ce qui peut entraîner des changements d'état non autorisés, des
modifications de données ou une élévation de privilèges.
Remédiation :
Envisagez de maintenir la protection CSRF activée pour toutes les opérations
modifiant l'état. Il est recommandé de supprimer l'appel .csrf().disable() et de
compter sur la validation par défaut du jeton CSRF de Spring Security. La protection
CSRF ne doit être désactivée que pour des API REST vraiment sans état qui utilisent
une authentification par jeton (par exemple, JWT) et ne dépendent pas des cookies
pour l'authentification. Pour les applications basées sur un navigateur utilisant
des cookies de session, la protection CSRF est essentielle.
OWASP :
- A5:2017-Contrôle d'Accès Brisé
- A01:2021-Contrôle d'Accès Brisé
kotlin_endpoint_rule-WeakHostNameVerification¶
Résumé :
Validation de certificat incorrecte
Sévérité : Moyenne
CWE : CWE-295
Description :
Vérification de nom d'hôte faible ou désactivée détectée dans l'implémentation SSL/TLS. Cette règle identifie les implémentations personnalisées de HostnameVerifier.verify() qui retournent toujours true, ou les méthodes vides de X509TrustManager (checkClientTrusted(), checkServerTrusted(), getAcceptedIssuers()). Ces implémentations désactivent la validation des certificats, rendant l'application vulnérable aux attaques de type homme du milieu où des attaquants peuvent intercepter et déchiffrer le trafic HTTPS.
Remédiation :
Considérez la mise en œuvre d'une validation appropriée des certificats au lieu de désactiver la vérification des noms d'hôte. Il est recommandé d'utiliser les implémentations par défaut de HostnameVerifier et X509TrustManager fournies par le JDK, qui effectuent une validation standard de la chaîne de certificats. Si une vérification personnalisée est requise, assurez-vous que HostnameVerifier.verify() effectue une correspondance réelle des noms d'hôte par rapport aux champs de sujet/SAN des certificats. Ne retournez jamais true de manière inconditionnelle et ne laissez pas les méthodes du gestionnaire de confiance vides, car cela accepte tout certificat, y compris ceux auto-signés et expirés.¶
kotlin_file_rule-FilenameUtils¶
Résumé :
Limitation incorrecte d'un chemin d'accès à un répertoire restreint ('Traversée de chemin')
Sévérité : Moyenne
CWE : CWE-22
Description :
Vulnérabilité de traversée de chemin détectée lors de l'utilisation des méthodes de Apache Commons FilenameUtils telles que 'normalize()', 'getName()', 'getExtension()', 'getBaseName()', ou 'isExtensions()'. Les entrées contrôlées par l'utilisateur sont traitées par ces méthodes, pouvant être manipulées avec des séquences de traversée de chemin comme '../' pour accéder à des fichiers en dehors du répertoire prévu. Cela peut permettre un accès non autorisé aux fichiers.
Remédiation :
Envisagez de valider tous les chemins de fichiers par rapport à une liste d'autorisation stricte de fichiers ou de répertoires permis avant d'utiliser les méthodes 'FilenameUtils'. Il est recommandé de vérifier les séquences de traversée de répertoire comme '..' et de rejeter tout chemin les contenant. Utilisez la résolution de chemin canonique et vérifiez que le chemin résolu reste dans le répertoire de base prévu. Ne faites jamais confiance à l'entrée utilisateur pour les chemins de fichiers sans une validation et une assainissement approfondis.
OWASP :
- A5:2017-Contrôle d'accès rompu
- A01:2021-Contrôle d'accès rompu
kotlin_inject_rule-CommandInjection¶
Résumé :
Neutralisation inappropriée des éléments spéciaux utilisés dans une commande OS ('Injection de commande OS')
Sévérété : Moyenne
CWE : CWE-78
Description :
L'application utilise Runtime.getRuntime().exec() ou ProcessBuilder.command() avec
des entrées contrôlées par l'utilisateur concaténées en utilisant des modèles de chaînes Kotlin ou
la concaténation de chaînes, ce qui permet l'injection de commandes arbitraires. Lorsque l'entrée
de l'utilisateur est directement incorporée dans les commandes shell via l'interpolation de chaînes
(par exemple, Runtime.getRuntime().exec("sh -c $userInput") ou ProcessBuilder.command("bash", "-c", userInput)), les attaquants peuvent injecter
des métacaractères de shell pour exécuter des commandes malveillantes. Cela est particulièrement
dangereux lors de l'utilisation de l'invocation shell (sh, bash, etc.) car cela permet la
chaînage de commandes avec des opérateurs tels que ;, &&, ||, et la substitution de
commandes avec des accents graves ou $( ).
Remédiation :
Envisagez d'utiliser ProcessBuilder avec des tableaux d'arguments plutôt qu'une invocation shell
pour exécuter des commandes en toute sécurité. Lors de l'utilisation de ProcessBuilder, passez chaque
argument comme un élément distinct dans la liste des commandes plutôt que de les concaténer en
une seule chaîne (par exemple, ProcessBuilder("programme", arg1, arg2) au lieu de
ProcessBuilder("sh", "-c", "programme $arg1 $arg2")). Cette approche empêche l'interprétation
shell des caractères spéciaux. Pour les arguments de commande dynamiques, validez et assainissez
toutes les entrées utilisateur contre une liste d'autorisation stricte des valeurs attendues.
La bibliothèque Apache Commons Exec fournit des utilitaires supplémentaires pour une
exécution sécurisée des commandes avec quoting des arguments. Évitez d'invoquer des
interprètes de shell (sh, bash, etc.) à moins que cela ne soit absolument nécessaire,
et si requis, utilisez des mécanismes d'échappement appropriés spécifiques à la shell
cible. Pour les applications Kotlin, envisagez d'utiliser des bibliothèques de niveau supérieur
ou de créer des fonctions d'encapsulation qui imposent des modèles de construction de commande sûrs.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_inject_rule-ELInjection¶
Résumé :
Neutralisation inadéquate des éléments spéciaux utilisés dans une déclaration de langage d'expression ('Injection de Langage d'Expression')
Sévérité : Moyenne
CWE : CWE-917
Description :
L'application utilise des API Java Expression Language (EL) telles que
ExpressionFactory.createMethodExpression(), ExpressionFactory.createValueExpression(),
ou ELProcessor.eval() avec des entrées contrôlées par l'utilisateur, ce qui permet l'exécution
de code arbitraire par injection EL. Les expressions EL peuvent accéder à des objets Java et invoquer des méthodes sur ceux-ci,
rendant l'évaluation dynamique d'EL extrêmement dangereuse lorsque des entrées utilisateur sont intégrées. Les attaquants
peuvent créer des expressions EL malveillantes pour exécuter du code Java arbitraire, accéder à des données sensibles,
ou manipuler l'état de l'application. Cette vulnérabilité se produit couramment dans les applications Web Java utilisant JSP, JSF,
ou les frameworks Spring où EL est utilisé pour évaluer dynamiquement des expressions à partir des entrées utilisateur.
Remédiation :
Évitez d'utiliser l'évaluation dynamique d'expressions EL avec des entrées contrôlées par l'utilisateur si
possible. Utilisez plutôt des expressions EL statiques définies dans des modèles JSP/JSF ou
des fichiers de configuration. Si l'évaluation dynamique est absolument nécessaire, mettez en œuvre une validation
stricte des entrées en utilisant une liste blanche de modèles d'expressions autorisées et rejetez toute entrée
contenant des caractères spéciaux EL comme $, {, }, ou .. Envisagez d'utiliser des alternatives plus sûres
telles que des recherches de propriétés simples ou la mise en œuvre d'un langage spécifique à un domaine avec des fonctionnalités limitées. Pour les applications Spring, évitez d'utiliser
SpELExpressionParser avec des entrées non fiables. Si EL doit être utilisé, envisagez d'utiliser
javax.el.ELResolver avec une implémentation personnalisée qui limite l'accès à des beans et méthodes spécifiques. La bibliothèque OWASP ESAPI fournit des utilitaires pour assainir les expressions EL,
bien qu'une prévention complète par des changements architecturaux soit fortement recommandée.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_inject_rule-LDAPInjection¶
Résumé :
Neutralisation inadéquate des éléments spéciaux utilisés dans une requête LDAP ('Injection LDAP')
Gravité : Moyenne
CWE : CWE-90
Description :
L'application utilise des entrées contrôlées par l'utilisateur dans des opérations LDAP via
javax.naming.directory.DirContext.search(), LdapContext.search(),
LdapConnection.search(), ou les méthodes LdapTemplate de Spring LDAP sans
sanitisation appropriée, ce qui permet des attaques par injection LDAP. Contrairement à SQL, LDAP ne dispose pas d'interfaces de déclarations préparées, ce qui le rend vulnérable lorsque des entrées utilisateur contenant des caractères spéciaux LDAP tels que *, (, ), \, |, &, ou ! sont directement intégrées dans des filtres de recherche ou des noms distingués. Les attaquants peuvent manipuler les requêtes LDAP pour contourner l'authentification, accéder à des données non autorisées, ou énumérer le contenu du répertoire. Par exemple, injecter *)(uid=*))(|(uid=* dans un filtre peut modifier la logique de requête pour retourner toutes les entrées. Cette vulnérabilité est courante dans les applications utilisant LDAP pour l'authentification ou les recherches dans le répertoire où les entrées utilisateur construisent des filtres de recherche ou des chemins DN.
Remédiation :
Mettre en œuvre une validation stricte des entrées et un échappement pour toutes les entrées utilisateur utilisées dans les requêtes LDAP. Pour les filtres de recherche LDAP, échapper aux caractères spéciaux en utilisant des fonctions d'encodage LDAP qui convertissent des caractères comme *, (, ), \, et NUL en leurs équivalents échappés (par exemple, \2a pour *). Le SDK LDAP UnboundID fournit Filter.encodeValue() pour une construction de filtres sécurisée, tandis que Spring LDAP offre LdapEncoder.filterEncode() pour échapper les valeurs de filtre et LdapEncoder.nameEncode() pour les composants DN. Pour les applications Kotlin, créez des fonctions d'enveloppe qui appliquent automatiquement l'échappement à tous les paramètres LDAP. Lors de la construction de filtres LDAP, utilisez des générateurs de filtres paramétrés plutôt que la concaténation de chaînes. Mettez en œuvre une validation de liste blanche pour les composants DN et les noms d'attributs, les restreignant à des motifs alphanumériques attendus. Envisagez d'utiliser LdapTemplate de Spring LDAP avec ses fonctionnalités de sanitisation intégrées, ou la classe Filter du SDK UnboundID qui permet une construction de filtres programmatiques plus sûres. Pour les cas d'utilisation d'authentification, validez les noms d'utilisateur par rapport à des motifs stricts avant de les incorporer dans les requêtes LDAP.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_inject_rule-OgnlInjection¶
Résumé :
Injection d'expressions (OGNL)
Sévérité : Moyenne
CWE : CWE-917
Description :
L'application utilise des entrées contrôlées par l'utilisateur avec les API OGNL (Object-Graph Navigation Language) d'Apache Struts 2 telles que OgnlUtil.getValue(), OgnlUtil.setValue(), TextParseUtil.translateVariables(), ou ValueStack.findValue() sans une sanitation appropriée, ce qui permet l'exécution de code arbitraire via l'injection d'expressions OGNL. OGNL est un langage d'expression extrêmement puissant dans Struts 2 qui peut accéder à des objets Java, invoquer des méthodes et exécuter du code arbitraire. Lorsque l'entrée de l'utilisateur est incorporée dans des expressions OGNL, les attaquants peuvent créer des expressions malveillantes pour instancier des objets, appeler des méthodes statiques, accéder au contexte d'exécution ou exécuter des commandes système. Cette vulnérabilité a été exploitée dans de nombreux CVE critiques de Struts 2 et peut mener à une compromission complète du serveur. Le risque est particulièrement élevé car l'évaluation OGNL fonctionne avec des capacités de réflexion Java complètes et les privilèges de l'application.
Remédiation :
Évitez d'utiliser l'évaluation dynamique d'expressions OGNL avec des entrées contrôlées par l'utilisateur. Utilisez plutôt les actions paramétrées de Struts 2 où l'entrée de l'utilisateur est liée aux propriétés d'action via des setters sûrs plutôt que d'être évaluée en tant qu'expressions. Si OGNL doit être utilisé, ne passez jamais directement l'entrée de l'utilisateur aux méthodes OgnlUtil, aux opérations ValueStack ou aux fonctions TextParseUtil. Pour les applications Struts 2, mettez à jour vers la dernière version qui inclut une meilleure sécurisation d'OGNL et des configurations du gestionnaire de sécurité. Configurez struts.ognl.expressionMaxLength pour limiter la complexité des expressions et activez struts.ognl.enableEvalExpression=false pour désactiver les fonctionnalités d'évaluation dangereuses. Envisagez de migrer vers des frameworks modernes comme Spring Boot avec Spring MVC qui évitent l'évaluation d'expressions dynamiques. Si la migration n'est pas réalisable, mettez en œuvre une validation stricte des entrées en utilisant des listes blanches et envisagez d'utiliser l'intercepteur ParametersInterceptor de Struts 2 avec des excludeParams et acceptParamNames correctement configurés pour prévenir l'injection de paramètres malveillants. Le jeu de règles de base OWASP ModSecurity fournit des règles WAF pour détecter les motifs courants d'injection OGNL comme mesure de défense en profondeur.¶
kotlin_inject_rule-SpotbugsPathTraversalAbsolute¶
Résumé :
Limitation incorrecte d'un chemin d'accès à un répertoire restreint ('Traversal de chemin')
Sévérité : Moyenne
CWE : CWE-22
Description :
L'application utilise une entrée contrôlée par l'utilisateur provenant de HttpServletRequest.getParameter() ou
@RequestParam de Spring pour construire des chemins de fichiers dans des opérations telles que java.io.File(),
java.nio.file.Paths.get(), FileInputStream(), FileReader(), ou
ClassLoader.getResourceAsStream() sans validation appropriée, ce qui permet des attaques par traversée de chemin. Lorsque l'entrée utilisateur contient des chemins absolus (par exemple, /etc/passwd), des références de répertoire parent (../), ou des liens symboliques, les attaquants peuvent accéder à des fichiers en dehors du répertoire prévu, y compris des fichiers système, le code source de l'application, des fichiers de configuration contenant des identifiants, ou des données d'autres utilisateurs. Cette vulnérabilité est particulièrement dangereuse car les API de fichiers Java respecteront les chemins absolus et les séquences de traversée de répertoires, permettant aux attaquants de contourner les contrôles d'accès prévus. Le risque s'étend aux scénarios de téléchargement de fichiers, au chargement de ressources, et à toute opération de fichier où l'entrée utilisateur influence le chemin d'accès au fichier.
Remédiation :
Utilisez FilenameUtils.getName() d'Apache Commons IO pour extraire uniquement le composant du nom de fichier, en supprimant toute information de chemin de répertoire avant de construire des chemins de fichiers. Pour les applications Kotlin, mettez en œuvre une validation stricte qui rejette toute entrée utilisateur contenant des séquences de traversée de chemin (.., /, \), des indicateurs de chemin absolu, ou des octets nuls. Envisagez d'utiliser une approche de liste blanche où l'entrée utilisateur sélectionne parmi un ensemble prédéfini de noms de fichiers valides plutôt que de construire directement des chemins. Lorsque les chemins de fichiers doivent être construits, utilisez Path.normalize().startsWith(baseDirectory) pour vérifier que les chemins résolus restent dans le répertoire prévu. Pour les fichiers temporaires, utilisez Files.createTempFile() avec un préfixe sûr et ignorez complètement les noms de fichiers fournis par l'utilisateur. Évitez d'utiliser ClassLoader.getResourceAsStream() avec des entrées utilisateur ; utilisez plutôt un mappage d'identifiants sûrs vers des chemins de ressources. Pour les applications Spring Boot, configurez spring.resources.static-locations de manière appropriée et utilisez ResourceLoader avec une validation adéquate. Envisagez de mettre en œuvre un système de fichiers virtuel ou d'utiliser des UUID comme noms de fichiers tout en stockant les noms fournis par l'utilisateur séparément dans une base de données. Ne vous fiez jamais à l'entrée utilisateur pour les opérations de fichiers sans validation et confinement complets.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_ldap_rule-AnonymousLDAP¶
Résumé :
Authentification manquante pour une fonction critique (LDAP)
Gravité : Moyenne
CWE : CWE-306
Description :
Définir Context.SECURITY_AUTHENTICATION sur "none" désactive l'authentification pour
les connexions LDAP, permettant des liaisons anonymes au serveur de répertoire. Cela expose
le serveur LDAP à un accès non autorisé et permet aux attaquants de interroger, modifier ou
extraire des informations sensibles du répertoire sans identification. L'authentification LDAP
anonyme ne devrait 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 l'authentification "simple" avec des identifiants appropriés (nom d'utilisateur et
mot de passe) ou des mécanismes plus forts comme SASL pour les liaisons LDAP. Envisagez de mettre en œuvre
une authentification basée sur des certificats ou Kerberos pour une sécurité accrue. Validez toujours
que les connexions LDAP sont authentifiées et utilisez des transports cryptés
(LDAPS) pour protéger les identifiants en transit.
OWASP :
- A2:2017-Authentification Cassée
- A07:2021-Échecs d'Identification et d'Authentification
kotlin_perm_rule-PermissionsDangereuses¶
Résumé :
Permissions héritées non sécurisées
Gravité : Moyenne
CWE : CWE-277
Description :
Accorder des permissions dangereuses telles que ReflectPermission("suppressAccessChecks")
ou RuntimePermission("createClassLoader") à un PermissionCollection peut
compromettre la sécurité de l'application en permettant l'exécution de code non autorisé ou le contournement du contrôle d'accès. Ces permissions permettent de supprimer les vérifications d'accès basées sur la réflexion ou de créer des chargeurs de classes personnalisés, qui sont des vecteurs d'attaque courants.
Remédiation :
Évitez d'accorder ReflectPermission("suppressAccessChecks") ou
RuntimePermission("createClassLoader"), car ces permissions peuvent permettre
des attaques par contournement de la sécurité. Envisagez d'appliquer le principe du moindre privilège en accordant uniquement les permissions minimales nécessaires au fonctionnement spécifique de l'application. Si des capacités de réflexion ou de chargement de classes sont nécessaires,
implémentez-les via des interfaces contrôlées et auditées plutôt que par des permissions globales.
OWASP :
- A5:2017-Contrôle d'accès brisé
- A01:2021-Contrôle d'accès brisé
kotlin_perm_rule-OverlyPermissiveFilePermissionInline¶
Résumé :
Attribution incorrecte des autorisations pour une ressource critique
Gravité : Moyenne
CWE : CWE-732
Description :
L'attribution de permissions de fichier trop permissives en utilisant
PosixFilePermissions.fromString() avec un accès lisible ou écrivable par tous
peut exposer des données sensibles à des utilisateurs non autorisés sur le système. Les permissions qui
accordent un accès en lecture, écriture ou exécution au groupe "autres" permettent à tout utilisateur sur le
système d'accéder au fichier, créant ainsi des vulnérabilités potentielles de sécurité.
Remédiation :
Utilisez des permissions de fichier restrictives lors de l'appel de
PosixFilePermissions.fromString(). Envisagez d'utiliser "rw-------" (lecture/écriture uniquement pour le propriétaire)
ou "rw-r-----" (lecture/écriture pour le propriétaire, lecture pour le groupe) au lieu de
permissions qui accordent un accès lisible ou écrivable par tous. Il est recommandé de
suivre le principe du moindre privilège et de n'accorder l'accès au fichier qu'aux
utilisateurs ou groupes spécifiques qui en ont besoin.
OWASP :
- A5:2017-Contrôle d'Accès Brisé
- A01:2021-Contrôle d'Accès Brisé
kotlin_strings_rule-BadHexConversion¶
Résumé :
Conversion ou cast de type incorrect
Gravité : Moyenne
CWE : CWE-704
Description :
Utiliser Integer.toHexString() pour convertir des octets de MessageDigest.digest() en chaînes hexadécimales dans une boucle peut produire une sortie incorrecte en raison de l'extension de signe et des zéros initiaux manquants. Lorsqu'un octet signé est converti en int, les valeurs 0x80-0xFF deviennent négatives et peuvent produire des représentations hexadécimales incorrectes. De plus, Integer.toHexString() omet les zéros initiaux pour les valeurs inférieures à 0x10, ce qui entraîne des chaînes hexadécimales à un caractère au lieu des deux caractères requis par octet.
Remédiation :
Envisagez d'utiliser joinToString() avec un lambda qui formate correctement chaque octet, tel que digest.joinToString("") { "%02x".format(it) }, ce qui garantit que chaque octet est représenté par exactement deux caractères hexadécimaux avec des zéros initiaux lorsque nécessaire. Alternativement, utilisez Hex.encodeHexString() de Apache Commons Codec qui gère correctement la conversion, ou convertissez en entiers non signés avant d'appeler Integer.toHexString() avec "%02x".format(byte.toInt() and 0xFF). L'essentiel est de masquer l'octet avec 0xFF pour éviter l'extension de signe et d'utiliser des chaînes de format qui ajoutent des zéros initiaux pour garantir une sortie cohérente de deux caractères par octet.
OWASP :
- A6:2017-Misconfiguration de sécurité
- A05:2021-Misconfiguration de sécurité
kotlin_strings_rule-ModifierAprèsValidation¶
Résumé :
Consolidation des données en une valeur non sécurisée
Sévérité : Moyenne
CWE : CWE-182
Description :
Modifier une chaîne de caractères en utilisant des méthodes comme replace(), replaceAll(), replaceFirst(), ou concat() après l'avoir validée avec Pattern.matcher() crée une vulnérabilité de type time-of-check à time-of-use (TOCTOU). La validation est effectuée sur la chaîne d'origine, mais la version modifiée est ensuite utilisée, ce qui peut contourner les contrôles de sécurité. Cela enfreint la directive de codage sécurisé CERT IDS11-J qui exige que toutes les modifications de chaîne soient effectuées avant la validation pour s'assurer que le contenu validé correspond à ce qui sera réellement utilisé par l'application.
Remédiation :
Envisagez de restructurer le code pour effectuer toutes les modifications de chaîne (opérations de remplacement, replaceAll, replaceFirst, concat) avant d'appliquer la validation avec Pattern.matcher(). Cela garantit que la chaîne exacte en cours de validation est la même que celle qui sera utilisée dans les opérations suivantes. Par exemple, si vous devez assainir l'entrée de l'utilisateur en supprimant certains caractères et ensuite valider le résultat, effectuez d'abord la suppression puis validez la chaîne nettoyée. Il est recommandé de créer un processus de traitement unique où : (1) l'entrée brute est reçue, (2) toutes les transformations nécessaires sont appliquées, (3) la chaîne finale transformée est validée, et (4) seule la chaîne validée est utilisée. Cela empêche les attaquants de contourner la validation en exploitant les différences entre les valeurs vérifiées et utilisées.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_strings_rule-NormalizeAfterValidation¶
Résumé :
Ordre de comportement incorrect : valider avant de normaliser
Sévérité : Moyenne
CWE : CWE-180
Description :
Appeler Normalizer.normalize() après avoir validé une chaîne avec Pattern.matcher() crée une vulnérabilité de temps de vérification à temps d'utilisation. La normalisation Unicode peut modifier la représentation des caractères (par exemple, en convertissant des caractères composés en forme décomposée ou vice versa), ce qui peut introduire des caractères qui ont été filtrés lors de la validation. Cela viole les directives de codage sécurisé de CERT IDS01-J qui exigent de normaliser les chaînes avant validation afin de garantir que la validation opère sur la forme finale des données qui seront utilisées par l'application.
Remédiation :
Envisagez d'appeler Normalizer.normalize() avant d'appliquer toute validation avec Pattern.matcher() pour vous assurer que la validation examine la forme finale normalisée de la chaîne. Par exemple, normalisez d'abord la chaîne d'entrée en utilisant une forme de normalisation comme NFC (Décomposition Canonique suivie de Composition Canonique) ou NFD (Décomposition Canonique), puis appliquez la correspondance de motifs au résultat normalisé. Il est conseillé d'établir un ordre de traitement cohérent : (1) recevoir une entrée brute, (2) normaliser en utilisant Normalizer.normalize() avec une forme appropriée, (3) valider la chaîne normalisée, et (4) utiliser uniquement la chaîne normalisée et validée. Cela empêche les attaquants de contourner la validation en utilisant des représentations Unicode alternatives qui se normalisent en caractères dangereux après la validation.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_unsafe_rule-ExternalConfigControl¶
Résumé :
Contrôle externe des paramètres système ou de configuration
Gravité : Moyenne
CWE : CWE-15
Description :
Un contrôle externe de la configuration de la base de données a été détecté lorsque l'entrée utilisateur provenant de HttpServletRequest.getParameter() est transmise à Connection.setCatalog(). Cela permet aux attaquants d'accéder à des catalogues de base de données non autorisés ou de provoquer des erreurs en fournissant des noms de catalogues inexistants, ce qui peut entraîner une exposition de données ou une perturbation du service.
Remédiation :
Envisagez d'utiliser des noms de catalogues codés en dur plutôt que de les accepter à partir des entrées utilisateur. Il est recommandé de valider toute valeur de catalogue externe contre une liste d'autorisation stricte de noms de catalogues autorisés avant de les transmettre à setCatalog(). Si la sélection dynamique des catalogues est nécessaire, associez les identifiants fournis par l'utilisateur à des noms de catalogues prédéfinis à l'aide d'une table de correspondance plutôt que de transmettre directement les entrées à la connexion de base de données.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_xml_rule-SAMLIgnoreComments¶
Résumé :
Authentification faible
Gravité : Moyenne
CWE : CWE-1390
Description :
Configurer BasicParserPool.setIgnoreComments(false) dans l'authentification SAML permet
le traitement des commentaires XML lors de l'analyse. Cela est dangereux car les attaquants
peuvent injecter des commentaires XML dans les assertions SAML pour manipuler la logique d'authentification,
bypassant potentiellement la vérification de signature et obtenant un accès non autorisé.
L'API OpenSAML BasicParserPool.setIgnoreComments() devrait être réglée sur true pour
prévenir les vulnérabilités d'élévation de privilèges basées sur les commentaires.
Remédiation :
Envisagez de configurer le BasicParserPool pour ignorer les commentaires XML en appelant
setIgnoreComments(true) au lieu de false. Cela empêche les attaquants de
manipuler les assertions SAML à travers des commentaires XML soigneusement élaborés qui pourraient
contourner la validation de signature. Lorsque les commentaires XML ne sont pas ignorés, ils peuvent être
utilisés pour diviser le contenu des éléments ou injecter des données supplémentaires qui altèrent le
sens sémantique des assertions SAML après la vérification de la signature. Il est
recommandé de toujours régler ignoreComments sur true dans les configurations SAML de production
pour maintenir l'intégrité des flux d'authentification. De plus,
envisagez de valider les assertions SAML contre un schéma strict et de mettre en œuvre
des mesures de défense en profondeur telles que la vérification de l'identité de l'émetteur, la vérification
des horodatages des assertions, et l'imposition de restrictions d'audience.
OWASP :
- A5:2017-Contrôle d'accès défaillant
- A01:2021-Contrôle d'accès défaillant
kotlin_xml_rule-XmlDecoder¶
Résumé :
Désérialisation de données non fiables
Gravité : Moyenne
CWE : CWE-502
Description :
L'appel à XMLDecoder.readObject() désérialise le contenu XML en objets Java, ce qui est dangereux lors du traitement de données non fiables. Cette API Java Beans permet l'exécution de code arbitraire car les attaquants peuvent créer un XML malveillant qui instancie des objets, invoque des méthodes et exécute des commandes système pendant la désérialisation. La classe java.beans.XMLDecoder ne doit jamais être utilisée avec des entrées non fiables car elle ne fournit aucun moyen sûr de restreindre la désérialisation.
Remédiation :
Envisagez de remplacer XMLDecoder par une alternative plus sûre comme Jackson, Gson ou d'autres bibliothèques de parsing JSON/XML qui n'exécutent pas de code arbitraire lors de la désérialisation. Si vous devez analyser des objets encodés en XML, utilisez un parseur XML standard avec une validation de schéma stricte et construisez manuellement des objets à partir des données analysées plutôt que de compter sur la désérialisation automatique. Pour les besoins de sérialisation de données, privilégiez les formats basés sur JSON avec des bibliothèques qui adoptent par défaut des pratiques de désérialisation sécurisées. Si l'utilisation de XMLDecoder est absolument nécessaire pour des raisons de compatibilité, implémentez un ClassLoader restrictif personnalisé qui n'autorise que la désérialisation de classes explicitement autorisées, et validez toutes les entrées par rapport à un schéma strict avant le traitement. Cependant, sachez qu même avec des restrictions, XMLDecoder comporte des risques de sécurité importants et le remplacement complet est l'approche recommandée.
OWASP :
- A8:2017-Désérialisation non sécurisée
- A08:2021-Pannes d'intégrité logicielle et des données
kotlin_xml_rule-XsltTransform¶
Résumé :
Injection XML (également appelée injection XPath aveugle)
Sévérité : Moyenne
CWE : CWE-91
Description :
Les transformations XSLT utilisant TransformerFactory.newTransformer() ou
Transformer.transform() avec des feuilles de style contrôlées par l'utilisateur sont dangereuses car
les processeurs XSLT peuvent exécuter du code arbitraire via des fonctions d'extension et
l'accès à des documents externes. Les attaquants peuvent concevoir des feuilles de style XSL malveillantes qui
invoquent des méthodes Java, lisent des fichiers ou exécutent des commandes système lorsqu'elles sont traitées par
l'API javax.xml.transform, entraînant des vulnérabilités d'exécution de code à distance.
Remédiation :
Envisagez de restreindre les transformations XSLT à n'utiliser que des feuilles de style
de confiance, contrôlées par l'application, stockées dans des emplacements sécurisés plutôt que d'accepter du contenu XSL fourni par l'utilisateur. Si l'entrée utilisateur doit influencer les transformations, utilisez une approche paramétrée où seules des valeurs spécifiques sont transmises à une feuille de style de confiance via Transformer.setParameter() au lieu de permettre un contrôle total de la feuille de style. Lors de la création d'instances de TransformerFactory, désactivez le traitement des entités externes et les fonctions d'extension en définissant les propriétés ACCESS_EXTERNAL_DTD et ACCESS_EXTERNAL_STYLESHEET sur des chaînes vides, et configurez la fonctionnalité XMLConstants.FEATURE_SECURE_PROCESSING sur true. En outre, envisagez d'exécuter des transformations XSLT dans un environnement isolé avec des autorisations restreintes, validez toutes les sources de feuilles de style par rapport à une liste blanche stricte et mettez en œuvre une validation complète des entrées pour prévenir les attaques d'injection via les paramètres de transformation.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_xss_rule-WicketXSS¶
Résumé :
Neutralisation incorrecte 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 dans le code Kotlin. Cela crée
une vulnérabilité Cross-Site Scripting (XSS) lorsque le composant affiche des données fournies par l'utilisateur, car un JavaScript ou un balisage HTML malveillant sera rendu directement dans le navigateur sans assainissement. L'échappement automatique par défaut de Wicket protège contre les XSS en encodant les caractères spéciaux HTML, et désactiver cette protection supprime un contrôle de sécurité critique. Cela est particulièrement dangereux dans les composants Label, les panneaux dynamiques ou tout composant qui rend l'entrée utilisateur dans les applications web basées sur Kotlin utilisant le framework Wicket.
Remédiation :
Considérez garder l'échappement automatique par défaut de Wicket activé en vous assurant que
setEscapeModelStrings(true) est appelé ou en vous fiant au comportement par défaut de Wicket qui échappe automatiquement le HTML. Si vous devez rendre du contenu HTML riche provenant de sources fiables, envisagez d'utiliser le composant Label de Wicket avec une validation de modèle explicite plutôt que de désactiver l'échappement globalement. Pour le contenu généré par l'utilisateur qui doit inclure une mise en forme, utilisez une bibliothèque de désinfection HTML basée sur une liste blanche comme OWASP Java HTML Sanitizer ou Jsoup avec une liste d'autorisation restrictive avant de passer le contenu aux composants Wicket. 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 les 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 une utilisation appropriée des fonctionnalités d'échappement dans les applications Kotlin.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
kotlin_xss_rule-XSSReqParamToServletWriter¶
Résumé :
Neutralisation incorrecte des entrées pendant la génération de pages web ('Cross-site Scripting')
Gravité : Moyenne
CWE : CWE-79
Description :
L'application écrit des données fournies par l'utilisateur à partir des paramètres de la requête HTTP directement dans la réponse HTTP via HttpServletResponse.getWriter().write() dans le code de servlet Kotlin. Cela crée une vulnérabilité XSS reflétée où les attaquants peuvent injecter du JavaScript malveillant en créant des paramètres de requête obtenus via HttpServletRequest.getParameter() qui sont renvoyés dans la réponse HTTP sans encodage HTML. Sans un 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, ce qui pourrait entraîner un détournement de session, un vol d'identifiants ou des attaques de défiguration dans des applications web basées sur Kotlin.
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 Kotlin. Si vous écrivez des réponses en texte brut, définissez le Content-Type sur text/plain avec response.contentType = "text/plain; charset=UTF-8" pour empêcher les navigateurs d'interpréter la sortie comme du HTML. Pour les applications web Kotlin modernes, privilégiez l'utilisation de moteurs de templates tels que le DSL HTML de Ktor, Thymeleaf ou FreeMarker qui fournissent un échappement automatique en fonction du contexte 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 une couche de défense supplémentaire contre les attaques XSS.
OWASP :
- A1:2017-Injection
- A03:2021-Injection
rules_lgpl_kotlin_other_rule-android-kotlin-webview-debug¶
Résumé :
Code de débogage résiduel
Gravité : Moyenne
CWE : CWE-489
Description :
Le débogage à distance de WebView est activé via setWebContentsDebuggingEnabled(true). Cela permet aux outils de débogage à distance, tels que Chrome DevTools, de se connecter à la WebView et d'inspecter ou de manipuler son contenu. Dans les versions de production, cela peut exposer des informations sensibles, y compris des données utilisateurs, des jetons de session, des identifiants d'authentification et la logique de l'application à des parties non autorisées.
Remédiation :
Envisagez de désactiver le débogage de WebView dans les versions de production tout en le maintenant disponible pour le développement. Il est recommandé d'utiliser BuildConfig.DEBUG pour activer conditionnellement le débogage uniquement dans les versions de développement avec WebView.setWebContentsDebuggingEnabled(BuildConfig.DEBUG). Cela garantit que les capacités de débogage à distance sont automatiquement désactivées lors de la création des versions de publication de l'application.
OWASP :
- A6:2017-Mauvaise configuration de la sécurité
- A05:2021-Mauvaise configuration de la sécurité