Udostępnij za pośrednictwem

Analiza kontroli katalogu LDAP jest teraz bardziej rygorystyczna

  • Artykuł

Wcześniej platforma .NET używała System.DirectoryServices.Protocols.BerConverter do analizowania obiektów System.DirectoryServices.Protocols.DirectoryControl odebranych przez sieć i generowania wysłanych tablic bajtów System.DirectoryServices.Protocols.DirectoryControl. System.DirectoryServices.Protocols.BerConverter użył funkcji analizowania BER specyficznego dla systemu operacyjnego. Ta funkcja analizowania jest teraz implementowana w kodzie zarządzanym.

Poprzednie zachowanie

W wyniku używania System.DirectoryServices.Protocols.BerConverteranalizowanie obiektów System.DirectoryServices.Protocols.DirectoryControl było dość luźne:

  • Tagi ASN.1 wartości nie zostały sprawdzone.
  • Dane końcowe po zakończeniu przetworzonego DirectoryControl zostały zignorowane, podobnie jak dane końcowe w sekwencji ASN.1.
  • W systemie Linux długości ciągów OCTET, które przekraczały granice sekwencji nadrzędnej, zwracały dane spoza tej sekwencji.
  • We wcześniejszych wersjach systemu Windows ciąg OCTET o zerowej długości zwrócił null, a nie pusty ciąg.
  • Podczas odczytywania zawartości System.DirectoryServices.Protocols.DirectoryControl jako ciągu zakodowanego w formacie UTF8 nieprawidłowa sekwencja UTF8 nie wygenerowała wyjątku.
  • Podczas przekazywania nieprawidłowego ciągu UTF8 do konstruktora VlvRequestControlnie zgłoszono wyjątku.

Chociaż nie jest to zmiana powodująca niezgodność, system Windows zawsze kodował tagi ASN.1 o długości czterech bajtów, podczas gdy system Linux używał tylko tyle bajtów dla długości tagu, ile jest potrzebnych. Obie reprezentacje były prawidłowe, ale ta różnica behawioralna między platformami już nie istnieje; Zachowanie systemu Linux jest teraz również wyświetlane w systemie Windows.

Nowe zachowanie

Analizowanie DirectoryControl jest znacznie bardziej rygorystyczne i jest teraz spójne na wszystkich platformach i wersjach.

  • Tagi ASN.1 są teraz sprawdzane.
  • Dane śledzące nie są już dopuszczalne.
  • Długość OCTET STRINGs i SEQUENCEs jest teraz sprawdzana.
  • OCTET STRINGo zerowej długości zawsze zwracają pusty ciąg.
  • Jeśli serwer wysyła nieprawidłową sekwencję bajtów UTF8, logika analizy System.DirectoryServices.Protocols.DirectoryControl teraz zgłasza wyjątek zamiast cicho zastępować nieprawidłowe znaki znaną wartością.

Sprawdzamy również błędy dokładniej podczas wywoływania konstruktora VlvRequestControl. Przekazywanie ciągu znaków, którego nie można zakodować jako wartości UTF8, teraz powoduje zgłoszenie błędu EncoderFallbackException.

Wersja wprowadzona

.NET 10 (wersja zapoznawcza 1)

Typ zmiany powodującej niezgodność

Ta zmiana jest zmianą behawioralną.

Przyczyna zmiany

Ta zmiana została wprowadzona dla zgodności z RFC i specyfikacjami. W różnych dokumentach RFC i sekcjach MS-ADTS, controlValue jest określony jako kodowanie BER struktury ASN.1, z użyciem sformułowania podobnego do następującego (z RFC2891, sekcja 1.2).

Właściwość controlType jest ustawiona na "1.2.840.113556.1.4.474". Krytyczność ma wartość FAŁSZ (MOŻE być nieobecna). ControlValue jest ciągiem OCTET, którego wartością jest kodowanie BER wartości następującej sekwencji:

To uniemożliwia dodanie danych końcowych. Wyklucza również kodowanie BER struktur ASN.1 o różnych znacznikach ASN.1 i nieprawidłowe kodowania BER (takie jak ciągi oktetów, które są dłuższe niż sekwencja, która je zawiera).

W przypadku konstruktora VlvRequestControl zgłoszenie wyjątku na początku oznacza, że użytkownicy mogą ufać, że tylko określone przez nich wartości są wysyłane do serwera. Nie ma sytuacji, w których mogą przypadkowo wysłać EF BF BD do serwera, ponieważ przekazali ciąg, którego nie można zakodować w prawidłowe bajty UTF-8.

Serwery powinny być zgodne z dokumentami RFC i specyfikacjami. Pamiętaj, aby obsłużyć EncoderFallbackException podczas wywoływania konstruktora VlvRequestControl.

Interfejsy API, których dotyczy problem