Meilleures pratiques d’utilisation de MSBuild sécurisées

MSBuild est hautement personnalisable et extensible (voir Personnaliser votre build pour plus d’informations), de sorte que des soins spéciaux doivent être payés à la configuration appropriée de l’environnement et à la génération.

Restreindre l’accès en écriture à l’emplacement d’installation

Installez MSBuild (qu’il s’agisse de Visual Studio, du sdk .NET ou autonome) dans un emplacement où seuls les utilisateurs approuvés ont accès en écriture.

Vous pouvez modifier la logique de génération en modifiant ou en ajoutant différents fichiers binaires et XML placés en regard de l’exécutable MSBuild et aux sous-dossiers de l’exécutable MSBuild. Par conséquent, seuls les utilisateurs approuvés doivent être autorisés à écrire dans le dossier.

Exécuter la build uniquement sur les sources que vous connaissez et révisez

Exécutez MSBuild (pour générer et restaurer des projets, mais également pour ouvrir des projets dans Visual Studio) uniquement sur les sources que vous approuvez entièrement.

La logique MSBuild peut être étendue dans les fichiers de script de build, y compris vos fichiers projet, de sorte que la logique de build inconnue doit être supposée être capable d’exécuter du code arbitraire dans l’environnement de build.

Exécuter votre build dans un emplacement vérifié et dédié

MSBuild peut inclure automatiquement une logique à partir d’un dossier de votre projet ou solution et de tout dossier parent jusqu’à la racine du lecteur. Cela inclut des .user fichiers, [before|after].{solution}.targets des fichiers, Directory.Build.[props|targets|rsp] des fichiers et d’autres.

Assurez-vous que seuls les utilisateurs ou comptes autorisés ont accès en écriture à l’emplacement avec vos fichiers liés à la build et à tout dossier d’une structure hiérarchique jusqu’à la racine du lecteur.

Pour éviter l’inclusion involontaire de Directory.Build.[props|targets|rsp], vous pouvez inclure ces fichiers à la racine de vos sources. Le fichier peut être un élément MSBuild Project vide.

Connaître et examiner les packages référencés et les flux d’origine

La logique de génération peut être automatiquement étendue par les packages NuGet. Cette logique est exécutée lors de la restauration, ce qui inclut la logique dans votre exécution de build ou de compilation. Assurez-vous que vous êtes familiarisé avec les types de ressources de package NuGet et leur rôle pendant la génération, la compilation et le runtime. Plus précisément, les ressources buildTransitivebuildMultitargeting et analyzers les buildressources sont automatiquement branchées (et donc exécutées automatiquement pendant) la build, sauf si elles sont explicitement désactivées.

Utilisez ExcludeAssets chaque fois que vous n’avez pas besoin de la logique d’extension de build ou de compilateur à partir d’un package référencé (ou même mieux, uniquement la IncludeAssets logique de génération si vous le souhaitez).

Assurez-vous que vous êtes familiarisé avec la documentation et les conseils actuels de l’équipe NuGet. Reportez-vous au PackageReference document de fichiers projet comme source faisant autorité pour ce problème.

Connaître et passer en revue le script/processus de démarrage de build

La logique de génération peut être affectée par des arguments de ligne de commande ou des variables d’environnement, en particulier celles qui peuvent entraîner l’injection de plug-ins (par exemple, des enregistreurs d’événements personnalisés) ou une logique de génération (par exemple, générer des scripts dans MSBuildUserExtensionsPath). Vérifiez que vous savez quels arguments de ligne de commande et les variables d’environnement sont appliqués au processus MSBuild. De cette façon, vous comprendrez mieux comment la logique de build est affectée.

Utiliser un compte d’utilisateur et une session dédiés pour exécuter votre build

N’exécutez pas sous un compte qui peut être utilisé sur un même système pour exécuter précédemment des processus ou des scripts inconnus, y compris une autre build. En particulier si la build non liée sous le même compte d’utilisateur peut avoir été exécutée sur des sources qui ne sont pas entièrement approuvées et connues.

MSBuild peut sourcer la logique à partir de différents emplacements à partir du profil utilisateur (en particulier le SDK MSBuild inclut automatiquement la logique de génération située à l’emplacement MSBuildUserExtensionsPath ) ou à partir d’emplacements injectables par variables d’environnement (vous pouvez personnaliser MSBuildUserExtensionsPath avec une propriété MSBuild portant le même nom. Cette propriété n’a pas de valeur par défaut. Elle peut donc être source à partir de la variable d’environnement portant le même nom).

Note

En guise de détail d’implémentation, MSBuild localise et communique avec ses processus persistants via des canaux nommés et des mutex. Sur Windows, ces canaux nommés et mutex partagent un espace de noms à l’échelle de l’ordinateur. Par conséquent, un processus sous un autre compte local peut occuper ces noms et empêcher votre build de les créer. Cette situation est une préoccupation de disponibilité (déni de service) uniquement. Les contrôles d’accès au système d’exploitation empêchent toujours un autre compte de lire ou de modifier la build. Préférez un ordinateur où tous les comptes locaux sont approuvés ou une session isolée, un conteneur ou une machine virtuelle.

  • MSBuildExtensionsPath et MSBuildUserExtensionsPath : vous pouvez définir la ImportUserLocationsByWildcardBefore{ImportingFileNameWithNoDots} propriété pour false refuser l’inclusion automatique de la logique de génération d’extension spécifique.
  • Dernière mise à jour :