Dela via

LDAP DirectoryControl-parsning är nu strängare

Tidigare använde .NET System.DirectoryServices.Protocols.BerConverter för att parsa de System.DirectoryServices.Protocols.DirectoryControl objekt som det tog emot via nätverket och för att generera de System.DirectoryServices.Protocols.DirectoryControl bytematriser som skickades. System.DirectoryServices.Protocols.BerConverter använde den OS-specifika BER-parsningsfunktionen. Den här parsningsfunktionen implementeras nu i hanterad kod.

Tidigare beteende

Tidigare, som ett resultat av att använda System.DirectoryServices.Protocols.BerConverter, var parsningen av System.DirectoryServices.Protocols.DirectoryControl objekt ganska lös:

  • ASN.1-taggarna för varje värde kontrollerades inte.
  • Eftersläpande data efter slutet av den parsade DirectoryControl ignorerades, liksom eftersläpande data i en ASN.1-SEKVENS.
  • På Linux returnerade OCTET STRING-längder som sträckte sig bortom slutet av den överordnade sekvensen, data som låg utanför sin överordnade sekvens.
  • I tidigare versioner av Windows returnerades en OCTET STRING med noll längd null i stället för en tom sträng.
  • När man läser innehållet i en System.DirectoryServices.Protocols.DirectoryControl som en UTF-8-kodad sträng, utlöste inte en ogiltig UTF-8-sekvens ett undantag.
  • När en ogiltig UTF8-sträng skickades till konstruktorn för VlvRequestControlutlöstes inget undantag.

Även om det inte är en icke-bakåtkompatibel ändring kodade Windows alltid ASN.1-taggar med en längd på fyra byte medan Linux endast använde så många byte för tagglängden som det behövdes. Båda representationerna var giltiga, men den här beteendeskillnaden mellan plattformarna är nu borta. Linux-beteendet visas nu också i Windows.

Nytt beteende

Från och med .NET 10 är DirectoryControl-parsningen mycket strängare och är nu konsekvent mellan plattformar och versioner:

  • ASN.1-taggar är nu kontrollerade.
  • Efterföljande data är inte längre tillåtna.
  • Längden på OCTET STRINGoch SEQUENCEkontrolleras nu.
  • Nollängds OCTET STRING:er returnerar nu alltid en tom sträng.
  • Om servern skickar en ogiltig UTF8-bytesekvens utlöser System.DirectoryServices.Protocols.DirectoryControl parsningslogik nu ett undantag i stället för att tyst ersätta de ogiltiga tecknen med ett känt värde.

Vi validerar också felen mer noggrant när vi anropar VlvRequestControl konstruktorn. Om du skickar en sträng som inte kan kodas som ett UTF8-värde genereras nu en EncoderFallbackException.

Version introducerad

.NET 10 Förhandsversion 1

Typ av inkompatibel ändring

Den här ändringen är en beteendeförändring.

Orsak till ändring

Den här ändringen gjordes för RFC och specifikationsefterlevnad. I de olika RFC:erna och avsnitten i MS-ADTS anges controlValue som BER-kodning för en ASN.1-struktur med formuleringar som liknar följande (från RFC2891, avsnitt 1.2):

ControlType är inställt på "1.2.840.113556.1.4.474". Kritikaliteten är FALSE, vilket kan vara frånvarande. ControlValue är en OCTET STRING, vars värde är BER-kodningen för ett värde av följande SEKVENS:

Detta förhindrar efterföljande data. Det utesluter också BER-kodningar för ASN.1-strukturer med olika ASN.1-taggar och ogiltiga BER-kodningar (till exempel OCTET STRING:er som är längre än deras innehållande SEKVENS.)

För VlvRequestControl konstruktorn innebär ett tidigt undantag att användarna kan lita på att endast de värden som de uttryckligen anger skickas till servern. Det finns inga omständigheter där de av misstag kan skicka EF BF BD till servern eftersom de har skickat en sträng som inte kan kodas till giltiga UTF8-byte.

Servrarna bör följa RFC:erna och specifikationerna. Se till att hantera en EncoderFallbackException när du anropar VlvRequestControl konstruktorn.

Berörda API:er

  • Last updated on