Partilhar via


A análise do LDAP DirectoryControl agora é mais rigorosa

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

Comportamento anterior

Anteriormente, como resultado do uso do System.DirectoryServices.Protocols.BerConverter, a análise sintática de objetos System.DirectoryServices.Protocols.DirectoryControl era bastante permissiva.

  • As tags ASN.1 de cada valor não foram verificadas.
  • Os dados restantes após o final do DirectoryControl analisado foram ignorados, assim como os dados adicionais dentro de uma SEQUÊNCIA ASN.1.
  • No Linux, os comprimentos OCTET STRING que se estendiam além dos limites da sequência pai retornavam dados fora da sequência pai.
  • Em versões anteriores do Windows, uma OCTET STRING de comprimento zero retornava null em vez de uma cadeia de caracteres vazia.
  • Ao ler o conteúdo de um System.DirectoryServices.Protocols.DirectoryControl como uma cadeia de caracteres codificada em UTF8, uma sequência UTF8 inválida não lançou uma exceção.
  • Nenhuma exceção foi lançada ao passar uma cadeia de caracteres UTF8 inválida para o construtor de VlvRequestControl.

Embora não seja uma mudança significativa, o Windows sempre codificou tags ASN.1 com um comprimento de quatro bytes, enquanto o Linux usou apenas quantos bytes para o comprimento da tag fosse necessário. Ambas as representações eram válidas, mas essa diferença comportamental entre plataformas desapareceu; o comportamento do Linux agora também aparece no Windows.

Novo comportamento

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

  • As tags ASN.1 agora estão verificadas.
  • Os dados excedentes não são mais permitidos.
  • O comprimento de OCTET STRINGs e SEQUENCEs é agora verificado.
  • Os OCTET STRINGde 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 de System.DirectoryServices.Protocols.DirectoryControl agora lançará uma exceção em vez de substituir silenciosamente os caracteres inválidos por um valor conhecido.

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

Versão introduzida

.NET 10 Prévia 1

Tipo de mudança de rutura

Esta alteração é uma mudança comportamental.

Motivo da mudança

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

O controlType é definido como "1.2.840.113556.1.4.474". A criticidade é falsa (pode estar ausente). O controlValue é uma OCTET STRING, cujo valor é a codificação BER de um valor da seguinte SEQUENCE:

Isso impede o rastreamento de dados. Ele também exclui codificações BER de estruturas ASN.1 com tags ASN.1 diferentes e codificações BER inválidas (como STRINGs OCTET que são mais longas do que SEQUENCE).

Para o construtor VlvRequestControl, lançar a exceção antecipadamente significa que os usuários podem confiar que apenas os valores que especificam 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 as RFCs e especificações. Certifique-se de manipular um EncoderFallbackException ao chamar o construtor VlvRequestControl.

APIs afetadas