El análisis de LDAP DirectoryControl ahora es más estricto
Anteriormente, .NET usaba System.DirectoryServices.Protocols.BerConverter para analizar los objetos de System.DirectoryServices.Protocols.DirectoryControl que recibió a través de la red y para generar las matrices de bytes de System.DirectoryServices.Protocols.DirectoryControl que envió. System.DirectoryServices.Protocols.BerConverter usó la funcionalidad de análisis ber específica del sistema operativo. Esta funcionalidad de análisis ahora se implementa en código administrado.
Comportamiento anterior
Como resultado del uso de System.DirectoryServices.Protocols.BerConverter, el análisis de objetos System.DirectoryServices.Protocols.DirectoryControl era bastante flexible.
- Las etiquetas ASN.1 de cada valor no se comprobaron.
- Se ignoraron los datos finales después del final del DirectoryControl analizado, al igual que los datos finales dentro de una ASN.1 SEQUENCE.
- En Linux, las longitudes de OCTET STRING que se extienden más allá del final de su secuencia principal devolvieron datos fuera de la secuencia principal.
- En versiones anteriores de Windows, una cadena OCTET de longitud cero devolvió
nullen lugar de una cadena vacía. - Al leer el contenido de un System.DirectoryServices.Protocols.DirectoryControl como una cadena codificada UTF8, una secuencia UTF8 no válida no produjo una excepción.
- Al pasar una cadena UTF8 no válida al constructor de VlvRequestControl, no se produjo ninguna excepción.
Aunque no es un cambio importante, Windows siempre codifica las etiquetas ASN.1 con una longitud de cuatro bytes, mientras que Linux solo usó tantos bytes para la longitud de la etiqueta según sea necesario. Ambas representaciones eran válidas, pero esta diferencia de comportamiento entre las plataformas ha desaparecido; el comportamiento de Linux ahora también aparece en Windows.
Nuevo comportamiento
El análisis de DirectoryControl es mucho más estricto y ahora es coherente entre plataformas y versiones:
- Ahora se comprueban las etiquetas ASN.1.
- Los datos finales ya no se permiten.
- Ahora se comprueba la longitud de
OCTET STRINGs ySEQUENCEs. - Las
OCTET STRINGs de longitud cero ahora siempre devuelven una cadena vacía. - Si el servidor envía una secuencia de bytes UTF8 no válida, la lógica de análisis de System.DirectoryServices.Protocols.DirectoryControl inicia ahora una excepción en lugar de sustituir silenciosamente los caracteres no válidos por un valor conocido.
También validamos los errores de manera más exhaustiva cuando llamamos al constructor de VlvRequestControl. Pasar una cadena que no se puede codificar como un valor UTF8 ahora produce una EncoderFallbackException.
Versión introducida
.NET 10 Preview 1
Tipo de cambio disruptivo
Este cambio es un cambio de comportamiento .
Motivo del cambio
Este cambio se realizó para cumplir con el RFC y la especificación. En las distintas RFC y secciones de MS-ADTS, el controlValue se especifica como la codificación BER de una estructura ASN.1 con texto similar al siguiente (de RFC2891, sección 1.2):
El controlType se establece en "1.2.840.113556.1.4.474". La criticidad es FALSE (puede estar ausente). ControlValue es una CADENA OCTET, cuyo valor es la codificación BER de un valor de la secuencia siguiente:
Esto excluye los datos finales. También se descartan las codificaciones BER de estructuras ASN.1 con etiquetas ASN.1 diferentes y de codificaciones BER no válidas (como OCTET STRINGs que son más largas que la SEQUENCE que las contiene).
En el caso del constructor de VlvRequestControl, al iniciar la excepción temprana, los usuarios pueden confiar en que solo los valores que especifiquen explícitamente se envían al servidor. No hay circunstancias en las que pueden enviar accidentalmente EF BF BD al servidor porque han pasado una cadena que no se puede codificar en bytes UTF8 válidos.
Acción recomendada
Los servidores deben cumplir con las RFC y las especificaciones. Asegúrese de controlar una EncoderFallbackException al llamar al constructor VlvRequestControl.
