Partager via

L’analyse LDAP DirectoryControl est désormais plus stricte

  • Article

Précédemment, .NET a utilisé System.DirectoryServices.Protocols.BerConverter pour analyser les objets System.DirectoryServices.Protocols.DirectoryControl qu’il a reçus sur le réseau et pour générer les tableaux d’octets System.DirectoryServices.Protocols.DirectoryControl qu’il a envoyés. System.DirectoryServices.Protocols.BerConverter utilisé la fonctionnalité d’analyse BER spécifique au système d’exploitation. Cette fonctionnalité d’analyse est désormais implémentée dans le code managé.

Comportement précédent

En raison de l’utilisation de System.DirectoryServices.Protocols.BerConverter, l’analyse des objets System.DirectoryServices.Protocols.DirectoryControl était assez lâche :

  • Les balises ASN.1 de chaque valeur n’ont pas été vérifiées.
  • Les données restantes après la fin de l'analyse de DirectoryControl ont été ignorées, tout comme les données restantes à l'intérieur d'une SEQUENCE ASN.1.
  • Sur Linux, les longueurs OCTET STRING qui se sont étendues au-delà de la fin de leur séquence parente ont renvoyé des données en dehors de la séquence parente.
  • Sur les versions antérieures de Windows, une chaîne OCTET de longueur nulle a retourné null plutôt qu’une chaîne vide.
  • Lors de la lecture du contenu d’un System.DirectoryServices.Protocols.DirectoryControl sous la forme d’une chaîne encodée en UTF8, une séquence UTF8 non valide n’a pas levée d’exception.
  • Lors du passage d'une chaîne UTF8 invalide au constructeur de VlvRequestControl, aucune exception n'était levée.

Bien qu’il ne s’agit pas d’une modification cassante, Windows a toujours codé des balises ASN.1 avec une longueur de quatre octets tandis que Linux n’a utilisé que autant d’octets pour la longueur de balise que nécessaire. Les deux représentations étaient valides, mais cette différence comportementale entre les plateformes est maintenant passée ; Le comportement Linux apparaît désormais également sur Windows.

Nouveau comportement

L’analyse DirectoryControl est beaucoup plus stricte et est désormais cohérente entre les plateformes et versions :

  • Les balises ASN.1 sont désormais vérifiées.
  • Les données complémentaires ne sont plus autorisées.
  • La longueur des OCTET STRINGs et SEQUENCEs est désormais vérifiée.
  • Les OCTET STRING de longueur nulle renvoient désormais toujours une chaîne vide.
  • Si le serveur envoie une séquence d’octets UTF8 non valide, la logique d’analyse System.DirectoryServices.Protocols.DirectoryControl lève désormais une exception plutôt que de remplacer silencieusement les caractères non valides par une valeur connue.

Nous validons également les erreurs de manière plus approfondie lors de l'appel au constructeur VlvRequestControl. Passer une chaîne qui ne peut pas être encodée en tant que valeur UTF-8 génère désormais une erreur EncoderFallbackException.

Version introduite

.NET 10 Preview 1

Type de changement cassant

Ce changement est un changement comportemental .

Raison de la modification

Cette modification a été apportée pour la conformité des spécifications et des RFC. Dans les différentes RFC et sections de MS-ADTS, controlValue est spécifié comme encodage BER d’une structure ASN.1 avec une formulation similaire à ce qui suit (de RFC2891, section 1.2) :

Le controlType est défini sur « 1.2.840.113556.1.4.474 ». La criticité est FALSE (PEUT être absent). ControlValue est une chaîne OCTET, dont la valeur est l’encodage BER d’une valeur de la séquence suivante :

Cela exclut les données de suivi. Cela exclut également les codages BER de structures ASN.1 avec des balises ASN.1 différentes, ainsi que les codages BER non valides (tels que les OCTET STRING plus longs que la SEQUENCE qu'ils contiennent).

Pour le constructeur VlvRequestControl, lever l’exception tôt signifie que les utilisateurs peuvent être assurés que seules les valeurs qu'ils spécifient explicitement sont envoyées au serveur. Il n’existe aucun cas où ils peuvent envoyer accidentellement des EF BF BD au serveur, car ils ont passé une chaîne qui ne peut pas être encodée à des octets UTF8 valides.

Les serveurs doivent se conformer aux RFC et aux spécifications. Veillez à gérer un EncoderFallbackException lorsque vous appelez le constructeur VlvRequestControl.

API affectées