40 votes

Quel est le degré de sécurité avec Maven?

Quels sont les risques et les possibilités ou les scénarios dans lesquels une personne configure des masques de référentiels maven et / ou des flux ip pour fournir des copies de bibliothèque masquées de l'original, mais contenant du code malveillant ou nuisible.

Quelles sont les étapes et les pratiques pour prévenir de tels risques et possibilités?

26voto

AlistairIsrael Points 3673

Je suppose que dévoué et plein de ressources attaquant peut effectuer une attaque de type MITM et intercepte toutes les requêtes du public Maven dépôts, soigneusement malveillant d'injecter du bytecode dans le POT artefacts, puis recalculer et de fournir le SHA1 hash.

Pour le client, il semble légitime d'artefact: le binaire BOCAL et le SHA1 match et sera le même, même si elles consultez d'autres miroirs.

Je suppose que la seule solution est de demander à la centrale de repos à l'appui de HTTPS (et de la confiance que le protocole TLS lui-même n'a pas été brisée).

Sinon, une approche pratique pourrait être de créer un Maven proxy (Artifactory ou Nexus) servi par le protocole HTTPS pour les clients internes. Cela réduit la surface d'attaque et signifie que vous aurez juste à sécuriser les lignes de communication de ce serveur vers le monde extérieur. Je périodiquement, vérifiez que les Pots et les tables de hachage sur le proxy correspondre à celles du public miroirs à l'aide d'un totalement indépendants, réseau de confiance.

Si vous voulez vraiment, vraiment être sûr que vous ne voudriez pas être de confiance binaires au lieu de cela, vous seriez le téléchargement de tout le code source et de les examiner à la main avant de les compiler vous-même-mais cela suppose que vous ayez suffisamment de personnel qualifié de ressources et de temps pour l'examen et la confiance de l'ensemble de votre outil de construction de la chaîne pour commencer.

Ainsi, la sécurité dans les couches comme ils disent toujours.

7voto

Mike Partridge Points 1438

Je peux penser à plusieurs scénarios, bien que la première n'est pas Maven-spécifique.

  1. L'empoisonnement du cache DNS

    Les données DNS que vous utilisez pour obtenir dans les dépôts standards pourraient être empoisonné, provoquant Maven pour télécharger des artefacts à partir d'un autre référentiel. Voir l'article de wikipedia sur l'empoisonnement de cache DNS.

  2. Non-standard des référentiels

    Tout dépôt que vous ajoutez à votre Maven configuration pourrait fournir des artefacts inclure du code malveillant. Éviter cela en utilisant uniquement ceux de la 3e partie des dépôts qui vous avez confiance.

  3. Référentiel de l'empoisonnement

    Basé sur Maven de Guide à la mise en ligne des artefacts vers le Dépôt Central, il semble que le central repository Maven publie des artefacts de l'approbation d'un référentiel d'hôtes, de sorte que la sécurité des artefacts dépend de l'hôte. Je ne sais pas les détails sur le processus de devenir un référentiel approuvé hôte, mais avec si peu de énumérées c'est probablement onéreux.

    En outre, le centre des pensions exige des signatures PGP pour tous les déploiements, de sorte que si un utilisateur malveillant parvient à accéder à la clé privée pour un projet, je ne pense pas que ce soit possible.

  4. Artefact de modification lors de la transmission (de l'homme du milieu)

    Maven n'automatique de vérification de somme de contrôle pour tous les artefacts, ainsi, l'attaquant aurait à modifier l'artefact et de l'accompagnement des sommes de contrôle pour injecter du code malveillant. Je ne sais pas si vous pourriez éviter complètement, mais assurez-vous que vous faites attention à des sommes de contrôle, assurez-vous que votre somme de contrôle de la politique n'est pas à ignorer. Voir les paramètres de doc.

Comme d'autres commentateurs l'ont mentionné, une bonne façon d'éviter que du code malveillant dans votre déploiement de production est uniquement à usage interne repository Maven pour la production de release. En restreignant l'accès à l'ajout de dépendances pour stockage, vous pouvez vous assurer qu'ils sont tous vérifiés quel que soit le niveau que vous choisissez, par exemple, de la somme de contrôle de double contrôle, source de numérisation.

4voto

Piotrek De Points 3566

Si vous utilisez bien connus des référentiels centraux (central repository maven, jboss référentiel), il est très faible possibilité d'injecter du code malveillant. Virus d'ordinateur, votre fournisseur de services internet, fournisseur de services internet ou de votre fournisseur de services internet pour se faire, doit à désordre dans les serveurs DNS ou modifier les chemins de routage pour un ensemble de destinations. Je pense que c'est plutôt rare - même n'est pas seulement à propos de maven repos, mais pour tous les services internet (e-mail, http, voip et ainsi de suite). Ce qui est plus le même risque avec le téléchargement des Pots directement à partir de sites de projet.
De toute façon, si vous voulez avoir un contrôle total, vous pouvez configurer votre propre repository maven (http://nexus.sonatype.org/)

Tous les fichiers disponibles dans le dépôt doit avoir md5 ou sha de la somme de contrôle générée - de cette façon, vous pouvez vérifier si ce que vous avez téléchargé est vraiment ce que tu voulais. Mais - si l'utilisateur malveillant (virus) est assez intelligent pour intercepter la transmission de vos données et le désordre dans les fichiers JAR il sera également assez intelligent pour intercepter md5/sha de sommes de contrôle. La défense contre il est de fournir des signatures PGP à la fois pour les sommes de contrôle et des artefacts - libération des artefacts téléchargés à la centrale des pensions de titres sont obligés de le faire (.les fichiers asc)

La bonne idée est d'utiliser Nexus Professionnel vous seriez en mesure de configurer les marchés suite à la vérification de signature PGP contre une clé publique du serveur à chaque fois artefact est téléchargé. Plus d'informations sur les signatures PGP avec maven peut être trouvé ici:

https://docs.sonatype.org/display/Repository/How+À+Générer+PGP+Signatures+Avec+Maven

http://www.sonatype.com/people/2012/03/the-first-line-of-defense-checksums-and-pgp-signatures-in-repositories/

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X