Práticas recomendadas de uso seguro do MSBuild

O MSBuild é altamente personalizável e extensível (consulte Personalizar seu build para obter detalhes), portanto, os cuidados especiais devem ser pagos à configuração adequada do ambiente e do build.

Restringir o acesso de gravação ao local de instalação

Instale o MSBuild (seja com Visual Studio, o SDK .NET ou autônomo) em um local em que apenas usuários confiáveis tenham acesso de gravação.

Você pode alterar a lógica de build alterando ou adicionando vários arquivos binários e XML colocados ao lado do executável do MSBuild e para as subpastas do executável MSBuild. Portanto, somente usuários confiáveis devem ter permissão para gravar na pasta.

Executar build somente em fontes que você conhece e revisou

Execute o MSBuild (para compilar e restaurar projetos, mas também para abrir projetos em Visual Studio) somente em fontes em que você confia totalmente.

A lógica do MSBuild pode ser estendida dentro dos arquivos de script de build, incluindo os arquivos de projeto, portanto, a lógica de build desconhecida deve ser considerada capaz de executar código arbitrário no ambiente de build.

Executar seu build em um local verificado e dedicado

O MSBuild pode incluir automaticamente a lógica de uma pasta de seu projeto ou solução e qualquer pasta pai até a raiz da unidade. Isso inclui .user arquivos, [before|after].{solution}.targets arquivos, Directory.Build.[props|targets|rsp] arquivos e outros.

Verifique se apenas os usuários ou contas autorizados têm acesso de gravação ao local com seus arquivos relacionados à compilação e qualquer pasta em uma estrutura hierárquica até a raiz da unidade.

Para impedir a inclusão não intencional, Directory.Build.[props|targets|rsp]você pode incluir esses arquivos na raiz de suas fontes. O arquivo pode ser um elemento MSBuild Project vazio.

Conhecer e examinar pacotes referenciados e feeds de origem

A lógica de build pode ser estendida automaticamente por pacotes NuGet. Essa lógica é executada após a restauração, o que inclui a lógica em sua execução de compilação ou build. Verifique se você está familiarizado com os tipos de ativo do pacote NuGet e sua função durante o build, a compilação e o runtime. Especificamente, os buildativos e analyzers os buildTransitivebuildMultitargeting ativos estão sendo conectados automaticamente (e assim executados automaticamente durante) o build, a menos que eles estejam sendo explicitamente optados.

Use ExcludeAssets sempre que você não precisar da lógica de extensão de build ou compilador de um pacote referenciado (ou melhor ainda, apenas explicitamente IncludeAssets a lógica de build se desejar).

Verifique se você está familiarizado com a documentação e as diretrizes atuais da equipe do NuGet. Consulte o documento nos arquivos doPackageReference projeto como uma fonte autoritativa para esse problema.

Conhecer e revisar o início do script/processo do build

A lógica de build pode ser afetada por argumentos de linha de comando ou variáveis de ambiente, especialmente aquelas que podem resultar na injeção de plug-ins (por exemplo, agentes personalizados) ou lógica de build (por exemplo, criar scripts).MSBuildUserExtensionsPath Verifique se você sabe quais argumentos de linha de comando e variáveis de ambiente são aplicados ao processo do MSBuild. Dessa forma, você entenderá melhor como a lógica de build é afetada.

Usar a conta de usuário dedicada e a sessão para executar o build

Não execute em uma conta que possa ser usada em um mesmo sistema para executar anteriormente processos ou scripts desconhecidos, incluindo um build diferente. Especialmente se o build não relacionado na mesma conta de usuário pode ter sido executado em fontes que não são totalmente confiáveis e conhecidas.

O MSBuild pode gerar lógica de vários locais do perfil de usuário (especificamente o SDK do MSBuild inclui automaticamente a lógica de build localizada na localização MSBuildUserExtensionsPath ) ou de locais injetáveis por variáveis de ambiente (você pode personalizar MSBuildUserExtensionsPath com uma propriedade MSBuild com o mesmo nome. Essa propriedade não tem um valor padrão, portanto, pode ser originada da variável de ambiente com o mesmo nome).

Note

Como um detalhe de implementação, o MSBuild localiza e se comunica com seus processos persistentes por meio de pipes nomeados e mutexes. Em Windows, esses pipes nomeados e mutexes compartilham um namespace de todo o computador. Portanto, um processo em outra conta local pode ocupar esses nomes e impedir que seu build os crie. Essa situação é apenas uma preocupação de disponibilidade (negação de serviço). Os controles de acesso do sistema operacional ainda impedem que outra conta leia ou altere o build. Prefira um computador em que todas as contas locais sejam confiáveis ou uma sessão isolada, um contêiner ou uma VM.

  • Última atualização em