Freigeben über

Die LDAP DirectoryControl-Analyse ist jetzt strenger.

Zuvor hat .NET System.DirectoryServices.Protocols.BerConverter verwendet, um die System.DirectoryServices.Protocols.DirectoryControl Objekte zu analysieren, die sie über das Netzwerk empfangen haben, und um die gesendeten System.DirectoryServices.Protocols.DirectoryControl Bytearrays zu generieren. System.DirectoryServices.Protocols.BerConverter hat die Betriebssystem-spezifische BER-Analysefunktion verwendet. Diese Analysefunktion wird jetzt in verwaltetem Code implementiert.

Vorheriges Verhalten

Zuvor war infolge der Verwendung von System.DirectoryServices.Protocols.BerConverter die Analyse von System.DirectoryServices.Protocols.DirectoryControl-Objekten ziemlich locker:

  • Die ASN.1-Tags jedes Werts wurden nicht überprüft.
  • Nachgestellte Daten nach dem Ende des geparsten DirectoryControl-Elements wurden ignoriert, ebenso wie nachgestellte Daten innerhalb eines ASN.1 SEQUENCE-Elements.
  • Unter Linux gaben OCTET STRING-Längen, die über das Ende ihrer übergeordneten Sequenz hinausgingen, Daten außerhalb der übergeordneten Sequenz zurück.
  • Unter früheren Versionen von Windows wurde null anstelle von OCTET STRING mit der Länge Null zurückgegeben.
  • Beim Lesen des Inhalts einer System.DirectoryServices.Protocols.DirectoryControl als UTF8-codierte Zeichenfolge löste eine ungültige UTF8-Sequenz keine Ausnahme aus.
  • Beim Übergeben einer ungültigen UTF8-Zeichenfolge an den Konstruktor von VlvRequestControlwurde keine Ausnahme ausgelöst.

Obwohl es sich nicht um eine grundlegende Änderung handelt, hat Windows ASN.1-Tags immer mit einer Länge von vier Byte codiert, während Linux nur so viele Bytes für die Taglänge verwendete, wie nötig. Beide Darstellungen waren gültig, aber dieser Verhaltensunterschied zwischen Plattformen ist jetzt verschwunden; Das Linux-Verhalten wird jetzt auch unter Windows angezeigt.

Neues Verhalten

Ab .NET 10 ist die DirectoryControl-Analyse wesentlich strenger und jetzt auf allen Plattformen und Versionen konsistent:

  • ASN.1-Tags werden jetzt überprüft.
  • Nachgestellte Daten sind nicht mehr zulässig.
  • Die Länge von OCTET STRINGs und SEQUENCEs wird nun überprüft.
  • OCTET STRING-Elemente mit der Länge Null geben jetzt immer eine leere Zeichenfolge zurück.
  • Wenn der Server eine ungültige UTF8-Bytesequenz sendet, löst die Analyselogik System.DirectoryServices.Protocols.DirectoryControl jetzt eine Ausnahme aus, anstatt die ungültigen Bytes unbemerkt durch einen bekannten Wert zu ersetzen.

Außerdem werden Fehler beim Aufrufen des VlvRequestControl-Konstruktors gründlicher überprüft. Durch Übergeben einer Zeichenfolge, die nicht als UTF8-Wert codiert werden kann, wird jetzt ein EncoderFallbackExceptionausgelöst.

Eingeführt in Version

.NET 10 Preview 1

Art der einschneidenden Änderung

Diese Änderung ist eine Verhaltensänderung.

Grund für Änderung

Diese Änderung wurde für RFC- und Spezifikationscompliance vorgenommen. In den verschiedenen RFCs und Abschnitten von MS-ADTS wird controlValue als BER-Codierung einer ASN.1-Struktur mit einem ähnlichen Wortlaut angegeben (aus RFC2891, Abschnitt 1.2):

Der controlType ist auf "1.2.840.113556.1.4.474" festgelegt. Die Kritikalität ist FALSCH (KANN fehlen). controlValue ist ein OCTET STRING-Element, dessen Wert die BER-Codierung eines Werts des folgenden SEQUENCE-Elements ist:

Dies schließt nachgestellte Daten aus. Außerdem werden BER-Codierungen von ASN.1-Strukturen mit verschiedenen ASN.1-Tags und ungültige BER-Codierungen ausgeschlossen (z. B. OCTET STRING-Elemente, die länger als ihr enthaltenes SEQUENCE-Element sind).

Für den VlvRequestControl-Konstruktor bedeutet das frühzeitige Auslösen der Ausnahme, dass Benutzer vertrauen können, dass nur die von ihnen angegebenen Werte an den Server gesendet werden. Es gibt keine Umstände, unter denen sie versehentlich EF BF BD an den Server senden können, da sie eine Zeichenfolge übergeben haben, die nicht mit gültigen UTF8-Bytes codiert werden kann.

Server sollten die RFCs und Spezifikationen einhalten. Behandeln Sie unbedingt EncoderFallbackException beim Aufrufen eines VlvRequestControl-Konstruktors.

Betroffene APIs

  • Last updated on