Bewährte Methoden für sichere MSBuild-Verwendung

MSBuild ist hochgradig anpassbar und erweiterbar (siehe Anpassen Ihres Builds für Details), daher sollte besondere Sorgfalt an die richtige Konfiguration der Umgebung und des Builds gezahlt werden.

Einschränken des Schreibzugriffs auf den Installationsspeicherort

Installieren Sie MSBuild (ob mit Visual Studio, dem .NET SDK oder eigenständig) an einem Speicherort, an dem nur vertrauenswürdige Benutzer Schreibzugriff haben.

Sie können die Buildlogik ändern, indem Sie verschiedene Binär- und XML-Dateien ändern oder hinzufügen, die neben der ausführbaren MSBuild-Datei und den Unterordnern der ausführbaren Datei MSBuild platziert werden. Daher sollten nur vertrauenswürdige Benutzer in den Ordner schreiben dürfen.

Ausführen von Build nur für Quellen, die Sie kennen und überprüft haben

Führen Sie MSBuild (zum Erstellen und Wiederherstellen von Projekten, aber auch zum Öffnen von Projekten in Visual Studio) nur für Quellen aus, denen Sie vollständig vertrauen.

MSBuild-Logik kann innerhalb der Buildskriptdateien erweitert werden, einschließlich Der Projektdateien. Daher sollte von unbekannter Buildlogik ausgegangen werden, dass sie beliebigen Code in der Buildumgebung ausführen kann.

Führen Sie Ihren Build an einem überprüften, dedizierten Speicherort aus.

MSBuild kann automatisch Logik aus einem Ordner Ihres Projekts oder Ihrer Projektmappe und einem beliebigen übergeordneten Ordner bis zum Stammverzeichnis des Laufwerks enthalten. Dazu gehören .user Dateien, [before|after].{solution}.targets Dateien, Directory.Build.[props|targets|rsp] Dateien und andere.

Stellen Sie sicher, dass nur die autorisierten Benutzer oder Konten Schreibzugriff auf den Speicherort mit Ihren buildbezogenen Dateien und allen Ordnern in einer hierarchischen Struktur bis zum Stamm des Laufwerks haben.

Um die unbeabsichtigte Aufnahme von Directory.Build.[props|targets|rsp]Dateien zu verhindern, können Sie solche Dateien in den Stamm Ihrer Quellen aufnehmen. Die Datei kann ein leeres MSBuild-Element Project sein.

Kennen und Überprüfen von referenzierten Paketen und Ursprungsfeeds

Buildlogik kann automatisch durch NuGet-Pakete erweitert werden. Diese Logik wird bei der Wiederherstellung ausgeführt, die die Logik in die Build- oder Kompilierungsausführung einschließt. Stellen Sie sicher, dass Sie mit den NuGet-Paketobjekttypen und deren Rolle während des Builds, der Kompilierung und Laufzeit vertraut sind. Insbesondere werden die buildElemente buildMultitargetingbuildTransitiveund analyzers Ressourcen automatisch an den Build angeschlossen (und werden daher während des Builds automatisch ausgeführt), es sei denn, sie werden explizit deaktiviert.

Verwenden Sie ExcludeAssets immer, wenn Sie die Build- oder Compilererweiterungslogik nicht aus einem referenzierten Paket benötigen (oder noch besser, nur explizit IncludeAssets die Buildlogik, wenn Sie dies wünschen).

Stellen Sie sicher, dass Sie mit der aktuellen Dokumentation und Anleitungen des NuGet-Teams vertraut sind. Verweisen Sie auf das PackageReference Dokument in Projektdateien als autorisierende Quelle für dieses Problem.

Kennen und Überprüfen des Buildstartskripts/Prozesses

Buildlogik kann von Befehlszeilenargumenten oder Umgebungsvariablen beeinflusst werden, insbesondere von Denen, die zum Einfügen von Plug-Ins (z. B. benutzerdefinierten Loggern) oder Buildlogik führen können (z. B. Buildskripts in MSBuildUserExtensionsPath). Stellen Sie sicher, dass Sie wissen, welche Befehlszeilenargumente und Umgebungsvariablen auf den MSBuild-Prozess angewendet werden. Auf diese Weise werden Sie besser verstehen, wie die Buildlogik betroffen ist.

Verwenden eines dedizierten Benutzerkontos und einer dedizierten Sitzung zum Ausführen des Builds

Führen Sie nicht unter einem Konto aus, das auf einem System verwendet werden kann, um zuvor unbekannte Prozesse oder Skripts auszuführen, einschließlich eines anderen Builds. Insbesondere, wenn der nicht verknüpfte Build unter demselben Benutzerkonto möglicherweise auf Quellen ausgeführt wurde, die nicht vollständig vertrauenswürdig und bekannt sind.

MSBuild kann Logik aus verschiedenen Speicherorten aus dem Benutzerprofil (insbesondere MSBuild SDK enthält automatisch Buildlogik, die sich im Speicherort MSBuildUserExtensionsPath befindet) oder von Speicherorten, die durch Umgebungsvariablen injiziert werden können (Sie können mit einer MSBuild-Eigenschaft mit demselben Namen anpassen MSBuildUserExtensionsPath . Diese Eigenschaft verfügt nicht über einen Standardwert, sodass sie aus der Umgebungsvariable mit demselben Namen stammen kann).

Hinweis

Als Implementierungsdetail sucht und kommuniziert MSBuild mit seinen persistenten Prozessen über benannte Rohre und Mutexes. In Windows teilen sich diese benannten Pipes und Mutexes einen computerweiten Namespace. Daher kann ein Prozess unter einem anderen lokalen Konto diese Namen belegen und ihren Build daran hindern, sie zu erstellen. Diese Situation betrifft nur die Verfügbarkeit (Denial-of-Service). Zugriffssteuerungen des Betriebssystems verhindern weiterhin, dass ein anderes Konto den Build liest oder ändert. Bevorzugen Sie einen Computer, auf dem alle lokalen Konten vertrauenswürdig sind, oder eine isolierte Sitzung, ein Container oder eine VM.

  • MSBuildExtensionsPath und MSBuildUserExtensionsPath: Sie können die ImportUserLocationsByWildcardBefore{ImportingFileNameWithNoDots} Eigenschaft so festlegen, dass false die automatische Einbindung der spezifischen Erweiterungsbuildlogik abgemeldet wird.
  • Last updated on