flawopen.com/Unsichere Deserialisierung/.NET BinaryFormatter-Sicherheit
Ist .NET BinaryFormatter sicher?
Microsoft bezeichnet BinaryFormatter als unsicher und nicht absicherbar. Die Verwendung soll auch dann beendet werden, wenn eine Anwendung ihre Daten für vertrauenswürdig hält. In .NET 9 bleiben die API-Typen vorhanden, aber die integrierte Implementierung löst immer PlatformNotSupportedException aus; ältere Runtimes und das nicht unterstützte Kompatibilitätspaket behalten das ursprüngliche Risiko.
// Deserialisieren Sie keine Daten über eine Vertrauensgrenze hinweg. using System.IO; using System.Runtime.Serialization.Formatters.Binary; public static class LegacyReader { public static object Deserialize(Stream input) => new BinaryFormatter().Deserialize(input); } // Auch diese uneingeschränkten polymorphen Serializer entfernen: SoapFormatter NetDataContractSerializer LosFormatter ObjectStateFormatter // intern von ASP.NET ViewState verwendet // SerializationBinder macht diese Formate nicht sicher.
// Die Anwendung legt die Datenform explizit fest. // Nullable reference types make the DTO contract explicit. #nullable enable using System; using System.IO; using System.Text.Json; public sealed record MyDto(int Id, string Name); public static class DtoReader { public static MyDto Parse(ReadOnlySpan<byte> json) { // Eingabegröße begrenzen und Anwendungsregeln prüfen. if (json.Length > 65_536) throw new InvalidDataException(); MyDto? value = JsonSerializer.Deserialize<MyDto>(json); if (value is null || value.Id <= 0 || string.IsNullOrWhiteSpace(value.Name) || value.Name.Length > 100) throw new InvalidDataException(); return value; } } // Alte NRBF-Dateien mit NrbfDecoder untersuchen // und zulässige Werte in ein DTO übertragen. // Niemals beliebige Runtime-Typen rekonstruieren.
Warum BinaryFormatter gefährlich ist
BinaryFormatter.Deserialize rekonstruiert Objektgraphen aus einem Datenstrom und kann vom Angreifer kontrollierte Daten den Kontrollfluss beeinflussen lassen. Microsoft warnt vor Denial of Service, Offenlegung von Informationen und Remote-Codeausführung. Das Grundproblem ist uneingeschränkte polymorphe Deserialisierung: Die serialisierten Daten können beeinflussen, welche Typen und Objektzustände verarbeitet werden. Keine Formatter-Einstellung macht daraus einen sicheren Parser für nicht vertrauenswürdige Bytes.
Das Risiko beschränkt sich nicht auf öffentliche HTTP-Endpunkte. Dateien, Caches, Warteschlangen, Datenbankeinträge, Nachrichten von Desktop-Clients und Cloud-Synchronisationsdaten können später von Angreifern beeinflusst werden. Verfolgen Sie, wie Bytes ins System gelangen und weitergegeben werden; “von uns geschrieben” oder “intern” ist keine dauerhafte Vertrauenskennzeichnung.
Warum SerializationBinder keine Lösung ist
Ein eigener SerializationBinder kann die aufzulösenden Typen einschränken. Microsoft stellt jedoch ausdrücklich klar, dass Binder und andere Konfigurationsoptionen Denial-of-Service-Angriffe nicht verhindern und gegen andere Angriffsklassen unzureichend sein können. Binder ersetzt keine Migration; akzeptieren Sie bis zur Entfernung von BinaryFormatter keine nicht vertrauenswürdigen Eingaben.
Alte Verwendungen und verbundene Pfade finden
Durchsuchen Sie Quellcode, Projektverweise und Runtime-Konfiguration nach BinaryFormatter, IFormatter, SoapFormatter, NetDataContractSerializer, LosFormatter und ObjectStateFormatter. Prüfen Sie Session-Provider, Cache-Adapter, Queue-Consumer, Dateiimporte/-exporte und ältere ASP.NET-Web-Forms-Anwendungen. ViewState ist üblicherweise durch einen Message Authentication Code (MAC) geschützt; lassen Sie diesen Schutz aktiviert und sichern Sie den Machine Key. Der MAC macht die allgemeine BinaryFormatter-Deserialisierung nicht sicher.
Migration nach Datenformat und Runtime-Version planen
Wählen Sie für neue Daten einen expliziten Vertrag wie System.Text.Json, DataContractSerializer, MessagePack oder protobuf-net nach Format- und Kompatibilitätsbedarf; es gibt keinen direkten Ersatz. Für alte NRBF-Dateien kann NrbfDecoder in .NET 9 Datensätze dekodieren, ohne kodierte Anwendungstypen zu instanziieren. Validieren Sie die Struktur und übernehmen Sie nur erwartete Werte in Anwendungs-DTOs. Prüfen Sie separat WinForms/WPF-Migrationshinweise zu Ressourcen, Zwischenablage und Drag-and-drop.
Häufige Fragen
Microsoft empfiehlt die Migration auch bei vermeintlich vertrauenswürdigen Daten, da Speicher, Caches, Dateien, Synchronisierung und nachgelagerte Dienste Vertrauensgrenzen überschreiten können. Prüfen Sie, wer jede Quelle beschreiben kann, und entfernen Sie BinaryFormatter, statt sich auf die Annahme zu verlassen.
In .NET 9 bleiben die API-Typen vorhanden, aber die integrierte Implementierung löst unabhängig vom früheren Kompatibilitätsschalter immer PlatformNotSupportedException aus. Prüfen Sie alle Verwendungen und migrieren Sie vor dem Upgrade. Ein nicht unterstütztes Kompatibilitätspaket stellt die verwundbare Implementierung wieder her und behebt das Sicherheitsproblem nicht.
Json.NET setzt TypeNameHandling standardmäßig auf None; Payload-Metadaten wählen dadurch keine beliebigen CLR-Typen aus. Aktivieren Sie andere Werte nicht für nicht vertrauenswürdige Eingaben. Falls Polymorphie nötig ist, verwenden Sie eine anwendungsgesteuerte Allowlist und beachten Sie die Bibliotheksleitlinien. Siehe Ist TypeNameHandling sicher?
Quellen und Referenzen
- Microsoft Learn — BinaryFormatter security guide
- Microsoft Learn — BinaryFormatter migration guide
- Microsoft Learn — Choose a BinaryFormatter replacement
- Microsoft Learn — Safely read NRBF payloads with NrbfDecoder
- Microsoft Learn — SYSLIB0011
- Microsoft Learn — ASP.NET ViewState MAC
- CWE-502 — Deserialization of Untrusted Data
- Is Json.NET TypeNameHandling safe?