FlawOpen

flawopen.com/Deserialisasi tidak aman/Keamanan .NET BinaryFormatter

Apakah BinaryFormatter .NET aman?

CWE-502: Deserialization of Untrusted DataHalaman referensi
Jawaban singkat: tidak ada konfigurasi aman

Microsoft menyatakan BinaryFormatter tidak aman dan tidak dapat diamankan. Microsoft menyarankan untuk berhenti menggunakannya, meskipun aplikasi menganggap datanya tepercaya. Di .NET 9, tipe API tetap tersedia, tetapi implementasi bawaan selalu melempar PlatformNotSupportedException; runtime lama dan paket kompatibilitas yang tidak didukung tetap memiliki risiko awal.

BERISIKO
// Jangan deserialisasi data yang melintasi batas kepercayaan.
using System.IO;
using System.Runtime.Serialization.Formatters.Binary;

public static class LegacyReader
{
    public static object Deserialize(Stream input) =>
        new BinaryFormatter().Deserialize(input);
}

// Hapus juga serializer polimorfik tanpa batas berikut:
SoapFormatter
NetDataContractSerializer
LosFormatter
ObjectStateFormatter  // digunakan secara internal oleh ASP.NET ViewState

// SerializationBinder tidak mengamankan format ini.
MIGRASI
// Bentuk data dinyatakan oleh kode aplikasi.
// 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)
    {
        // Batasi ukuran input dan validasi aturan aplikasi.
        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;
    }
}

// Untuk file NRBF lama, periksa record dengan NrbfDecoder
// lalu petakan nilai yang diizinkan ke DTO.
// Jangan membuat ulang tipe runtime sembarang.

Mengapa BinaryFormatter berbahaya

BinaryFormatter.Deserialize membangun kembali graf objek dari stream dan dapat membiarkan data yang dikendalikan penyerang memengaruhi alur eksekusi. Microsoft memperingatkan risiko denial of service, pengungkapan informasi, dan eksekusi kode jarak jauh. Masalah utamanya adalah deserialisasi polimorfik tanpa batas: data serialisasi dapat memengaruhi tipe dan status objek yang diproses. Tidak ada pengaturan formatter yang menjadikannya parser aman untuk byte tak tepercaya.

Risiko tidak hanya ada pada endpoint HTTP publik. File, cache, antrean, catatan basis data, pesan klien desktop, dan status sinkronisasi cloud dapat dipengaruhi penyerang di kemudian hari. Telusuri bagaimana byte masuk dan berpindah dalam sistem; label “kami yang menulisnya” atau “internal” bukan jaminan kepercayaan permanen.

Mengapa SerializationBinder tidak cukup

SerializationBinder khusus dapat membatasi tipe yang dicoba oleh formatter, tetapi Microsoft menegaskan bahwa binder maupun pengaturan lain tidak dapat mengurangi denial of service dan mungkin tidak cukup untuk kelas serangan lain. Binder bukan pengganti migrasi; jangan terima input tak tepercaya sambil menunggu penghapusan BinaryFormatter.

Temukan penggunaan lama dan jalur terkait

Cari kode sumber, referensi proyek, dan konfigurasi runtime untuk BinaryFormatter, IFormatter, SoapFormatter, NetDataContractSerializer, LosFormatter, dan ObjectStateFormatter. Periksa penyedia session, adapter cache, konsumen antrean, impor/ekspor file, dan aplikasi ASP.NET Web Forms lama. ViewState biasanya dilindungi message authentication code (MAC); pertahankan perlindungan itu dan amankan machine key. MAC tersebut tidak membuat deserialisasi umum BinaryFormatter aman.

Rencanakan migrasi berdasarkan format dan versi runtime

Untuk data baru, pilih kontrak eksplisit seperti System.Text.Json, DataContractSerializer, MessagePack, atau protobuf-net sesuai format dan kompatibilitas; tidak ada pengganti langsung. Jika file NRBF lama harus dipertahankan, NrbfDecoder .NET 9 dapat mendekode record tanpa membuat instance tipe aplikasi yang dikodekan. Validasi struktur hasil decode dan petakan hanya nilai yang diharapkan ke DTO. Tinjau panduan migrasi WinForms/WPF untuk resource, clipboard, dan drag-and-drop secara terpisah.

Pertanyaan umum

Kami hanya mendeserialisasi data yang kami tulis sendiri. Apakah aman?

Microsoft menyarankan migrasi meskipun data tampak tepercaya karena penyimpanan, cache, file, sinkronisasi, dan layanan hilir dapat melintasi batas kepercayaan. Cari tahu siapa yang dapat menulis ke tiap sumber dan hentikan BinaryFormatter, bukan mengandalkan asumsi.

Apa yang terjadi saat pindah ke .NET 9?

Di .NET 9, tipe API tetap ada tetapi implementasi bawaan selalu melempar PlatformNotSupportedException, apa pun switch kompatibilitas lama. Audit penggunaan dan migrasikan sebelum upgrade. Paket kompatibilitas yang tidak didukung mengembalikan implementasi rentan dan bukan perbaikan keamanan.

Apakah Json.NET pengganti yang aman?

Secara default, Json.NET menetapkan TypeNameHandling ke None, sehingga metadata payload tidak memilih tipe CLR sembarang. Jangan aktifkan nilai lain untuk input tak tepercaya. Jika polimorfisme diperlukan, gunakan allowlist ketat yang dikendalikan aplikasi dan ikuti panduan library. Lihat Apakah TypeNameHandling aman?

Sumber dan referensi

Lihat juga Deserialisasi tidak aman: risiko dan mitigasi Keamanan ObjectInputStream Java: Cegah Risiko Deserialisasi Newtonsoft.Json TypeNameHandling: konfigurasi aman? PHP unserialize() dan input tak tepercaya Python pickle.load(): risiko data tak tepercaya Apakah Ruby YAML.load aman? Versi Psych dan safe_load