Comment éviter les 7 principaux pièges de sécurité Java

Comment éviter les 7 principaux pièges de sécurité Java

Même avant que la vulnérabilité Log4j ne conduise au ciblage de près de la moitié des réseaux d’entreprise mondiaux, les applications Java offraient de nombreuses opportunités aux pirates. Après tout, il y a tellement de composants à protéger (logique côté serveur, logique côté client, stockage de données, transport de données, API et autres) qu’il est décourageant de tout défendre.

En réalité, de graves vulnérabilités existent dans 44 % des applications Java, contre 23 % pour ceux .NET. Heureusement, la plupart des vulnérabilités partagent les mêmes causes profondes. Mais avant de pouvoir les réparer, vous devez les trouver. Et pour les trouver, il faut savoir ce que l’on cherche. Dans cet esprit, voici notre liste des sept principaux pièges de sécurité Java – et ce que vous devriez faire à leur sujet :

Attaques XXE. Cela se produit lorsque des cybercriminels exploitent un analyseur de langage de balisage extensible (XML) pour lire des fichiers arbitraires sur votre serveur. Ils peuvent ensuite déployer une entité externe XML (XXE) pour récupérer des informations utilisateur, des fichiers de configuration ou même des informations d’identification pour les environnements cloud. La plupart des analyseurs Java XML activent les exigences XXE par défaut, vous devez donc les désactiver de manière proactive pour éviter les attaques XXE.

Désérialisation non sécurisée. Lors de la sérialisation, un objet dans un langage de programmation est converti dans un format que vous pouvez enregistrer dans une base de données ou transférer sur un réseau. Lors de la désérialisation, l’inverse se produit : l’objet sérialisé est lu à partir d’un fichier ou d’un réseau afin que vous puissiez le reconvertir en objet.

Cependant, les pirates rechercheront des vulnérabilités sous la forme d’une désérialisation non sécurisée, afin de pouvoir manipuler l’objet sérialisé pour lancer des attaques de contournement d’authentification, de déni de service ou d’exécution de code arbitraire.

Pour éviter cela, vous devez rester à jour avec les correctifs. Vous devez également vous assurer que votre code tiers répond à vos normes de défense, car de nombreuses vulnérabilités non sécurisées causées par la désérialisation sont introduites via des dépendances.

Exécution de code à distance. Les pirates commettent l’exécution de code à distance (RCE) lorsqu’ils exécutent leur code sur votre machine, souvent via des vulnérabilités d’injection de commande – une RCE dans laquelle l’entrée de l’utilisateur est directement liée à une commande système. Votre application ne peut pas faire la différence entre l’entrée de l’utilisateur et l’emplacement de la commande système, elle exécute donc l’entrée de l’utilisateur sous forme de code. Cela permet aux pirates d’exécuter des commandes arbitraires sur la machine.

Votre meilleur contre-mouvement ici est de proposer une liste d’autorisation efficace, qui assurera une validation d’entrée robuste.

Injection SQL. Au sens large, injections lorsque les applications ne peuvent pas correctement faire la distinction entre les données utilisateur non fiables et le code légitime/valide. Dans les commandes du système d’exploitation, cela conduira à l’injection de commandes.

Dans le cas des injections de langage de requête structuré (SQL), les adversaires injectent des données pour manipuler les commandes SQL. Si l’application ne peut pas valider correctement l’entrée de l’utilisateur, les adversaires insèrent des caractères désignés pour le langage SQL afin de perturber la logique de la requête et d’exécuter du code SQL arbitraire. Ils peuvent profiter de la structure de requête compromise pour modifier ou voler des données et/ou exécuter des commandes arbitraires dans le système d’exploitation.

C’est pourquoi vous devez tirer parti des instructions paramétrées pour rendre les injections SQL pratiquement impossibles, en pré-compilant les instructions SQL afin de fournir strictement les paramètres (ou variables/entrées) que vous cherchez à insérer dans l’instruction pour l’exécuter.

Injection NoSQL. Les bases de données “Not only SQL” (NoSQL) n’utilisent pas le langage SQL. Lors des injections NoSQL, les pirates vont injecter des données dans la logique des langages de base de données pour permettre les contournements d’authentification et RCE. MongoDB, Couchbase, Cassandra, HBase et d’autres bases de données NoSQL sont vulnérables à ces attaques.

La syntaxe des requêtes NoSQL est spécifique à la base de données et les requêtes sont souvent écrites dans le langage de programmation de l’application. Vous devez donc recourir à des méthodes spécifiques à la base de données pour bloquer les injections NoSQL. Nous avons fourni des conseils plus détaillés sur la sécurisation des principales bases de données individuelles ici.

Injection LDAP. Le protocole LDAP (Lightweight Directory Access Protocol) permet aux développeurs d’interroger un service d’annuaire sur les utilisateurs et les périphériques d’un système. Mais lorsqu’une application autorise des entrées non fiables dans ces requêtes, les pirates peuvent soumettre des entrées spécialement conçues pour contourner l’authentification et altérer les données stockées dans le répertoire. Là encore, les requêtes paramétrées restent ici efficaces en prévention.

Injection de journaux. Les équipes de sécurité s’appuient sur la journalisation du système pour détecter les activités malveillantes sur le réseau. Mais les adversaires en sont conscients et modifient fréquemment les fichiers journaux pour dissimuler leurs traces lors d’une attaque. Grâce à une injection de journal typique, ils inciteront l’application à écrire de fausses entrées dans vos fichiers journaux.

Ils peuvent, par exemple, rechercher des applications qui ne nettoient pas les caractères de nouvelle ligne dans les entrées écrites dans les journaux, pour introduire leur propre caractère de nouvelle ligne et insérer de nouvelles entrées de journal d’application. Ou ils injecteront du code HTML malveillant dans les entrées de journal pour lancer une attaque de script intersite (XSS) sur le navigateur de l’administrateur qui supervise les journaux.

Pour éviter cela, vous devez faire la distinction entre les vraies entrées de journal et les fausses, en préfixant chaque entrée de journal avec un horodatage, un ID de processus, un nom d’hôte et d’autres formes de métadonnées. En appliquant les principes de confiance zéro, vous devez traiter le contenu du fichier journal comme une entrée non fiable jusqu’à ce que vous l’ayez entièrement validé pour l’accès et les opérations.

La liste des pièges de sécurité Java se résume à peine à ces sept, car nous prévoyons de publier dans un avenir proche un livre électronique avec des résumés détaillés de 29 des vulnérabilités les plus courantes. Nous sommes heureux de fournir cela parce que, comme le dit l’adage éprouvé, la connaissance est le pouvoir. Lorsque les équipes sont conscientes de ce qui existe dans leurs applications Java et qui pourraient les exposer, elles sont beaucoup plus proches de trouver – et de supprimer – les problèmes qui les exposent à une attaque.

Leave a Comment