Udostępnij za pośrednictwem

Ryzyko deserializacji w użyciu klasy BinaryFormatter i powiązanych typów

  • Artykuł

Ten artykuł dotyczy następujących typów:

Ten artykuł dotyczy następujących implementacji platformy .NET:

  • Wszystkie wersje programu .NET Framework
  • .NET Core 2.1 — 3.1
  • .NET 5 lub nowszy

Uwaga

Typ BinaryFormatter jest niebezpieczny i nie jest zalecany do przetwarzania danych. Aplikacje powinny przestać używać BinaryFormatter tak szybko, jak to możliwe, nawet jeśli uważają, że dane, które przetwarzają, będą wiarygodne. BinaryFormatter jest niezabezpieczony i nie można go zabezpieczyć.

Uwaga

Począwszy od platformy .NET 9, implementacja wbudowana BinaryFormatter zgłasza wyjątki w użyciu, nawet w przypadku ustawień, które wcześniej włączyły jego użycie. Te ustawienia są również usuwane. Aby uzyskać więcej informacji, zapoznaj się z przewodnikiem migracji BinaryFormatter.

Luki w zabezpieczeniach deserializacji

Luki w zabezpieczeniach deserializacji to kategoria zagrożeń, w której ładunki żądań są przetwarzane w sposób niezabezpieczony. Osoba atakująca, która pomyślnie wykorzystuje te luki w zabezpieczeniach aplikacji, może spowodować odmowę usługi (DoS), ujawnienie informacji lub zdalne wykonywanie kodu w aplikacji docelowej. Ta kategoria ryzyka konsekwentnie sprawia, że OWASP Top 10. Cele obejmują aplikacje napisane w różnych językach, w tym C/C++, Java i C#.

Na platformie .NET największym celem ryzyka są aplikacje używające BinaryFormatter typu do deserializacji danych. BinaryFormatter jest szeroko stosowany w całym ekosystemie platformy .NET ze względu na jego moc i łatwość użytkowania. Jednak ta sama siła daje osobom atakującym możliwość wywierania wpływu na przepływ sterowania w aplikacji docelowej. Pomyślne ataki mogą spowodować, że osoba atakująca będzie mogła uruchomić kod w kontekście procesu docelowego.

W prostszej analogii załóżmy, że wywoływanie BinaryFormatter.Deserialize ładunku jest odpowiednikiem interpretowania tego ładunku jako autonomicznego pliku wykonywalnego i uruchamiania go.

Luki w zabezpieczeniach usługi BinaryFormatter

Ostrzeżenie

Metoda BinaryFormatter.Deserialize nigdy nie jest bezpieczna, gdy jest używana z niezaufanymi danymi wejściowymi. Zdecydowanie zalecamy, aby konsumenci zamiast tego rozważyli użycie jednej z alternatyw opisanych w dalszej części tego artykułu.

BinaryFormatter została zaimplementowana, zanim luki w zabezpieczeniach deserializacji były dobrze zrozumiałą kategorią zagrożeń. W związku z tym kod nie stosuje nowoczesnych najlepszych rozwiązań. Metodę Deserialize można użyć jako wektora do przeprowadzania ataków typu DoS na używanie aplikacji. Te ataki mogą spowodować brak odpowiedzi aplikacji lub spowodować nieoczekiwane zakończenie procesu. Tej kategorii ataku nie można ograniczyć za pomocą przełącznika SerializationBinder konfiguracji lub innego BinaryFormatter . Platforma .NET traktuje to zachowanie zgodnie z projektem i nie wyda aktualizacji kodu w celu zmodyfikowania zachowania.

BinaryFormatter.Deserialize mogą być podatne na inne kategorie ataków, takie jak ujawnienie informacji lub zdalne wykonywanie kodu. Wykorzystanie funkcji, takich jak niestandardowe SerializationBinder , może być niewystarczające, aby prawidłowo ograniczyć te zagrożenia. Istnieje możliwość, że osoba atakująca odkryje nowatorski program wykorzystujący istniejące środki zaradcze. Platforma .NET nie zobowiązuje się do publikowania poprawek w odpowiedzi na wszelkie takie obejścia. Ponadto opracowywanie lub wdrażanie takich poprawek może być technicznie niewykonalne. Należy ocenić swoje scenariusze i rozważyć potencjalne narażenie na te zagrożenia.

Zalecamy, aby BinaryFormatter konsumenci przeprowadzali indywidualne oceny ryzyka w swoich aplikacjach. Jedynym zadaniem konsumenta jest określenie, czy należy korzystać z usługi BinaryFormatter. Jeśli rozważasz korzystanie z niego, należy ocenić bezpieczeństwo, techniczne, reputację, prawne i konsekwencje regulacyjne.

Preferowane alternatywy

Platforma .NET oferuje kilka serializatorów w pudełku, które mogą bezpiecznie obsługiwać niezaufane dane:

Niebezpieczne alternatywy

Unikaj następujących serializatorów:

Poprzednie serializatory wykonują nieograniczoną deserializacji polimorficzne i są niebezpieczne, podobnie jak BinaryFormatter.

Ryzyko przy założeniu, że dane mają być wiarygodne

Często deweloper aplikacji może sądzić, że przetwarza tylko zaufane dane wejściowe. Bezpieczny przypadek wejściowy ma wartość true w niektórych rzadkich okolicznościach. Jednak znacznie częściej ładunek przekracza granicę zaufania, nie zdając sobie z tego sprawy.

Rozważ serwer w wersji lokalnej, na którym pracownicy korzystają z klienta stacjonarnego ze stacji roboczych w celu interakcji z usługą. Ten scenariusz może być postrzegany naiwnie jako "bezpieczna" konfiguracja, w której wykorzystanie jest akceptowalne BinaryFormatter . Jednak ten scenariusz przedstawia wektor złośliwego oprogramowania, który uzyskuje dostęp do maszyny pojedynczego pracownika, aby móc rozpowszechniać się w całym przedsiębiorstwie. To złośliwe oprogramowanie może wykorzystać użycie BinaryFormatter przedsiębiorstwa do przechodzenia z stacji roboczej pracownika do serwera zaplecza. Następnie może eksfiltrować poufne dane firmy. Takie dane mogą obejmować tajemnice handlowe lub dane klientów.

Rozważ również aplikację, która używa BinaryFormatter funkcji do utrwalania stanu zapisywania. Początkowo może to być bezpieczny scenariusz, ponieważ odczytywanie i zapisywanie danych na własnym dysku twardym stanowi niewielkie zagrożenie. Jednak udostępnianie dokumentów za pośrednictwem poczty e-mail lub Internetu jest powszechne, a większość użytkowników końcowych nie postrzega otwierania tych pobranych plików jako ryzykowne zachowanie.

Ten scenariusz można wykorzystać do nikczemnego efektu. Jeśli aplikacja jest grą, użytkownicy, którzy udostępniają pliki zapisywania nieświadomie narażają się na ryzyko. Deweloperzy mogą być również objęci celami. Osoba atakująca może wysłać wiadomość e-mail do działu pomocy technicznej deweloperów, dołączyć złośliwy plik danych i poprosić pracowników pomocy technicznej o jego otwarcie. Ten rodzaj ataku może dać atakującemu przyczółek w przedsiębiorstwie.

Innym scenariuszem jest to, że plik danych jest przechowywany w magazynie w chmurze i automatycznie synchronizowany między maszynami użytkownika. Osoba atakująca, która może uzyskać dostęp do konta magazynu w chmurze, może zatruć plik danych. Ten plik danych zostanie automatycznie zsynchronizowany z maszynami użytkownika. Następnym razem, gdy użytkownik otworzy plik danych, ładunek osoby atakującej zostanie uruchomiony. W związku z tym osoba atakująca może wykorzystać zabezpieczenia konta magazynu w chmurze, aby uzyskać pełne uprawnienia do wykonywania kodu.

Rozważmy aplikację, która przenosi się z modelu instalacji klasycznej do modelu opartego na chmurze. Ten scenariusz obejmuje aplikacje, które przechodzą z aplikacji klasycznej lub rozbudowanego modelu klienta do modelu internetowego. Wszystkie modele zagrożeń rysowane dla aplikacji klasycznej nie muszą mieć zastosowania do usługi opartej na chmurze. Model zagrożenia dla aplikacji klasycznej może odrzucić dane zagrożenie jako "nie interesujące dla klienta, aby zaatakował się". Jednak to samo zagrożenie może stać się interesujące, jeśli uważa, że użytkownik zdalny (klient) atakuje samą usługę w chmurze.

Uwaga

Ogólnie rzecz biorąc, celem serializacji jest przesyłanie obiektu do lub z aplikacji. Ćwiczenie modelowania zagrożeń prawie zawsze oznacza ten rodzaj transferu danych jako przekroczenie granicy zaufania.

Zobacz też