Compartilhar via


A análise LDAP DirectoryControl agora é mais rigorosa

Anteriormente, o .NET usava System.DirectoryServices.Protocols.BerConverter para analisar os objetos System.DirectoryServices.Protocols.DirectoryControl recebidos pela rede e gerar as matrizes de bytes System.DirectoryServices.Protocols.DirectoryControl enviadas. System.DirectoryServices.Protocols.BerConverter usou a funcionalidade de análise BER específica do sistema operacional. Essa funcionalidade de análise agora é implementada no código gerenciado.

Comportamento anterior

Anteriormente, como resultado do uso System.DirectoryServices.Protocols.BerConverter, a análise de System.DirectoryServices.Protocols.DirectoryControl objetos era bastante flexível:

  • As marcas ASN.1 de cada valor não foram verificadas.
  • Os dados finais após o término do DirectoryControl analisado foram ignorados, assim como os dados restantes em uma SEQUÊNCIA ASN.1.
  • No Linux, os comprimentos OCTET STRING que se estenderam além do final da sequência pai retornaram dados fora da sequência pai.
  • Em versões anteriores do Windows, uma CADEIA DE CARACTERES OCTET de comprimento zero retornou null em vez de uma cadeia de caracteres vazia.
  • Ao ler o conteúdo de uma System.DirectoryServices.Protocols.DirectoryControl como uma cadeia de caracteres codificada em UTF8, uma sequência UTF8 inválida não gerou uma exceção.
  • Ao passar uma cadeia de caracteres UTF8 inválida para o construtor de VlvRequestControl, nenhuma exceção foi gerada.

Embora não seja uma alteração significativa, o Windows sempre codificava tags ASN.1 com um comprimento de quatro bytes, enquanto o Linux usava apenas o número de bytes necessário para o comprimento da tag. Ambas as representações eram válidas, mas essa diferença comportamental entre plataformas já se foi; o comportamento do Linux agora também aparece no Windows.

Novo comportamento

A partir do .NET 10, a análise de DirectoryControl é muito mais rigorosa e agora é consistente entre plataformas e versões:

  • As marcas ASN.1 agora são verificadas.
  • Os dados finais não são mais permitidos.
  • O comprimento de OCTET STRINGs e SEQUENCEs agora é verificado.
  • Os OCTET STRINGs de comprimento zero agora sempre retornam uma cadeia de caracteres vazia.
  • Se o servidor enviar uma sequência de bytes UTF8 inválida, a lógica de análise System.DirectoryServices.Protocols.DirectoryControl agora gerará uma exceção em vez de substituir silenciosamente os caracteres inválidos por um valor conhecido.

Também validamos os erros de forma mais detalhada ao chamar o construtor VlvRequestControl. Passar uma string que não pode ser codificada como um valor UTF8 agora gera um erro EncoderFallbackException.

Versão introduzida

.NET 10 Versão Prévia 1

Tipo de alteração interruptiva

Esta é uma alteração comportamental.

Motivo da alteração

Essa alteração foi feita para conformidade com a RFC e a especificação. Nas várias RFCs e seções do MS-ADTS, o controlValue é especificado como a codificação BER de uma estrutura ASN.1 com texto semelhante ao seguinte (de RFC2891, seção 1.2):

O controlType é definido como "1.2.840.113556.1.4.474". A severidade é FALSA (PODE estar ausente). O controlValue é uma CADEIA DE OCTETOS, cujo valor é a codificação BER de um valor da seguinte SEQUÊNCIA:

Isso impede os dados finais. Ele também exclui codificações BER de estruturas ASN.1 com marcas ASN.1 diferentes e codificações BER inválidas (como OCTET STRINGs que são mais longas do que as sequências que as contêm).

Para o construtor VlvRequestControl, gerar a exceção antecipadamente significa que os usuários podem confiar que somente os valores especificados explicitamente são enviados para o servidor. Não há circunstâncias em que eles possam enviar acidentalmente EF BF BD para o servidor porque eles passaram uma cadeia de caracteres que não pode ser codificada para bytes UTF8 válidos.

Os servidores devem estar em conformidade com os RFCs e as especificações. Certifique-se de manipular um EncoderFallbackException ao chamar o construtor VlvRequestControl.

APIs afetadas