Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Vorsicht
Aufgrund der BinaryFormatter raten wir dringend von der Verwendung von ab. Bestehende Benutzer sollten weg von BinaryFormattermigrieren.
Ab .NET 9 enthalten wir keine Implementierung von BinaryFormatter mehr in der Runtime. Die APIs sind weiterhin vorhanden, ihre Implementierung löst jedoch unabhängig vom Projekttyp immer einen PlatformNotSupportedExceptionFehler aus. Das Festlegen des vorhandenen Abwärtskompatibilitätsflags reicht daher nicht mehr aus, um es zu verwenden BinaryFormatter.
Sie haben zwei Möglichkeiten, dies zu beheben:
Migrieren sie weg von BinaryFormatter. Es wird dringend empfohlen, Optionen zu untersuchen, um die Verwendung von BinaryFormatter aufgrund der damit verbundenen Sicherheitsrisiken einzustellen. Nachfolgend werden mehrere Optionen aufgeführt.
BinaryFormatterVerwenden Sie weiterhin . Wenn Sie BinaryFormatter in .NET 9 weiterhin verwenden möchten, müssen Sie auf das nicht unterstützte System.Runtime.Serialization.Formatters NuGet Paket zurückgreifen, das die werfende Implementierung ersetzt.
Was ist das Risiko bei der Verwendung BinaryFormatter?
Jeder Deserialisierer, ob binär oder textbasiert, der seiner Eingabe die Möglichkeit bietet, Informationen über die zu erstellenden Objekte zu übertragen, ist ein Sicherheitsproblem, das auf sich warten lässt. Es gibt eine häufige Schwächeaufzählung (CWE), die das Problem beschreibt: CWE-502 "Deserialisierung von nicht vertrauenswürdigen Daten". BinaryFormatter ist ein Deserialisierer, der in der ersten Version des .NET Framework im Jahr 2002 enthalten war. Wir behandeln dies auch im BinaryFormater-Sicherheitshandbuch.
Aufgrund der bekannten Verwendungsrisiken BinaryFormatterwurde die Funktionalität von .NET Core 1.0 ausgeschlossen. Aber ohne einen klaren Migrationspfad, um etwas Sichereres zu verwenden, führte die Kundennachfrage dazu, dass BinaryFormatter in .NET Core 2.0 enthalten wurde. Seitdem versucht das .NET-Team, BinaryFormatter vollständig zu entfernen, indem es standardmäßig in mehreren Projekttypen ausgeschaltet wird. Die Benutzer können es jedoch bei Bedarf für die Abwärtskompatibilität über Flags wieder aktivieren.
Weitere Informationen zur Entscheidung finden Sie in der Ankündigung zu "BinaryFormatter wird in .NET 9 entfernt".
Wenn Probleme im Zusammenhang mit der Entfernung von BinaryFormatter auftreten, die in diesem Migrationshandbuch nicht behoben werden, melden Sie bitte ein Problem unter github.com/dotnet/runtime und geben Sie an, dass das Problem mit der Entfernung von BinaryFormatter zusammenhängt.
Themen zur Migration
Die Migration weg von BinaryFormatter bedeutet in der Regel, einen anderen Serialisierer auszuwählen. Dies ist jedoch in der Regel nur dann zulässig, wenn Sie sowohl den Produzenten als auch den Verbraucher der codierten Daten steuern. Falls Sie den Produzenten nicht steuern, können Sie auch zur neuen API wechseln, um Nutzlasten zu lesenBinaryFormatter, ohne einen der codierten Typen zu instanziieren.
Beide Optionen werden weiter unten beschrieben.
Auswählen eines Serialisierungsmoduls
Der erste Schritt bei der Migration von BinaryFormatter
ist die Wahl eines Serialisierers, der an seiner Stelle verwendet wird. Je nach Ihren spezifischen Anforderungen empfiehlt das .NET-Team Migrationen zu vier verschiedenen Serialisierern.
- Migrieren zu System.Text.Json (JSON)
- Migrieren zu DataContractSerializer (XML)
- Migrieren zu MessagePack (binär)
- Migrieren zu protobuf-net (binär)
Lesen von BinaryFormatter-Nutzlasten (NRBF)
Viele Anwendungen laden und deserialisieren Nutzlasten, die im Speicher beibehalten wurden, und es ist nicht immer möglich, alle dauerhaften Nutzlasten vorab zu transformieren. Andere Szenarien können Systeme oder Dienste betreffen, die von BinaryFormatter produzierte Daten empfangen, wobei diese Systeme unabhängig voneinander migriert werden müssen.
In diesen Szenarien und anderen Szenarien ist es notwendig, die Unterstützung für das Lesen der bereitgestellten Nutzlasten und den Übergang zu einem neuen Format im Laufe der Zeit beizubehalten. Um diese Anforderungen zu erfüllen, ist es jetzt möglich, NRBF-Nutzlasten sicher zu lesen, die mithilfe von BinaryFormatter
erstellt wurden, ohne eine allgemeine und anfällige Deserialisierung durchzuführen.
Migrieren von Windows Forms- und WPF-Anwendungen
Für Windows Forms- und WPF-Anwendungen sind möglicherweise zusätzliche Änderungen erforderlich. Weitere Anleitungen zur Migration finden Sie unter Windows Forms-Apps, WPF-Apps und WinForms/WPF-Anleitungen zur Zwischenablage und Drag-and-Drop.
Migrieren verwalteter Ressourcen (ResX)
Die am häufigsten verwendeten Ressourcentypen (z. B. Zeichenfolgen und Symbole) funktionieren ohne BinaryFormatter. Für benutzerdefinierte Typen müssen Sie einen Kompatibilitätsswitch einbinden BinaryFormatter und aktivieren, siehe Laden der Ressource während der Laufzeit.
Verwenden des Kompatibilitätspakets
Für Szenarien, in denen beim Upgrade auf .NET 9 eine Migration von BinaryFormatter weg nicht durchgeführt werden kann, ist ein nicht unterstütztes Kompatibilitätspaket verfügbar. Das NuGet Paket System.Runtime.Serialization.Formatters enthält die funktionierende Implementierung von BinaryFormatter, einschließlich seiner Schwachstellen und Risiken.
Obwohl nicht unterstützt und nicht empfohlen, enthält das Handbuch für die Verwendung des Kompatibilitätspakets die Details zum Installieren des Pakets und zum Aktivieren der Funktionalität.
Vorsicht
Aufgrund der BinaryFormatter raten wir dringend von der Verwendung von ab. Bestehende Benutzer sollten weg von BinaryFormattermigrieren.