FlawOpen

flawopen.com/Unsichere Deserialisierung/.NET BinaryFormatter-Sicherheit

Ist .NET BinaryFormatter sicher?

CWE-502: Deserialization of Untrusted DataReferenzseite
Kurzantwort: Keine sichere Konfiguration

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.

UNSICHER
// 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.
MIGRIEREN
// 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

Wir deserialisieren nur Daten, die wir selbst geschrieben haben. Ist das sicher?

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.

Was ändert sich beim Wechsel zu .NET 9?

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.

Ist Json.NET ein sicherer Ersatz?

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

Siehe auch Unsichere Deserialisierung: Risiken und Schutz Java ObjectInputStream: Deserialisierung sicher gestalten Newtonsoft.Json TypeNameHandling: sichere Konfiguration? PHP unserialize() und nicht vertrauenswürdige Daten Python pickle.load(): Risiken nicht vertrauenswürdiger Daten Ist Ruby YAML.load sicher? Psych-Versionen und safe_load