Resumo

  • RFC 1558 deu ao Filter binário do LDAP uma notação textual prefixa. Parênteses, &, |, !, comparadores e * definiam a operação, não apenas sua aparência.
  • O filtro era somente um campo da SearchRequest; base, escopo, aliases, limites, regras de correspondência, controle de acesso e sequência de resultados continuavam separados.
  • RFC 1960, RFC 2254 e RFC 4515 refinaram o contrato até LDAPv3, UTF-8 e escapes hexadecimais. RFC 1558 era Informational e não discutia segurança; não prova incidente, implantação nem vulnerabilidade atual.

A tela mostrava caracteres; o servidor via ramificações

Na RFC 1558, (cn=Babs Jensen) é igualdade. (!(cn=Tim Howes)) nega uma condição. (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) é uma árvore: AND no topo, igualdade de um lado e OR com igualdade e substring do outro.

O asterisco torna a autoridade da sintaxe ainda mais clara. attr=* testa presença; em (o=univ*of*mich*), os asteriscos delimitam trechos de substring; se * fizer parte do valor, o texto de 1993 manda precedê-lo com barra invertida. O mesmo glifo pode ampliar a busca ou permanecer dado, dependendo da codificação.

O registro no Datatracker e a página do RFC Editor confirmam dezembro de 1993 e o status Informational, sem definir padrão da Internet. A versão textual permite conferência independente, e a página de errata mantém correções separadas. O documento diz que questões de segurança não são discutidas. Ele não deve ser recontado como relatório contemporâneo de injeção ou violação.

Um Filter não reconstruía uma SearchRequest

RFC 1487 já descrevia a SearchRequest: o Filter em BER vinha acompanhado do objeto-base, escopo, política para aliases, limites de tamanho e tempo, retorno só de tipos ou também de valores e seleção de atributos. RFC 1488 fornecia formas textuais para as sintaxes de atributos daquela geração. RFC 1558 padronizou a representação humana do Filter, não o contexto inteiro.

Com outra base, a mesma condição visita outra parte da árvore. wholeSubtree amplia o domínio em relação a singleLevel; aliases podem abrir novos caminhos; limites podem interromper; a seleção de atributos muda o que é pedido depois da correspondência. Revisar só a linha visível não mostra o trabalho executado.

Na RFC 4511, cuja ficha oficial identifica o protocolo, a avaliação tem três resultados: TRUE, FALSE ou Undefined. Só TRUE torna a entrada retornável, ainda sujeita a controles de acesso. Atributo desconhecido, regra inadequada ou valor inválido podem dar Undefined. Aceitação sintática não é confirmação semântica.

O resultado chega em etapas: zero ou mais SearchResultEntry e SearchResultReference, depois um SearchResultDone. Uma referência aponta área ainda não explorada; valores podem faltar por pedido ou política. Correspondência, retorno, completude, autenticação, autorização e ação posterior são recibos diferentes.

Os sucessores tornaram o limite mais preciso

RFC 1960 conservou a notação prefixa ao substituir RFC 1558 como Proposed Standard, conforme sua ficha. Depois foi substituída por RFC 2254.

RFC 2254 levou a forma a LDAPv3, incluindo correspondência extensível e UTF-8, e usou barra invertida mais dois dígitos hexadecimais para octetos especiais. A página oficial registra esse elo.

A atual RFC 4515, com sua ficha, exige escapar os octetos de *, (, ), barra invertida e NUL e produzir UTF-8 válido. Em (cn=*\2a*), os asteriscos externos são operadores de substring; \2a é o asterisco literal.

Sem os octetos, a rotina de escape e a árvore analisada, uma captura do texto final não prova qual papel o caractere desempenhou. O aperfeiçoamento do escape é também aperfeiçoamento de evidência.

O contrato comum precisava continuar estreito

A forma legível reduziu custo de revisão e integração. O ganho era real. Ela não definiu conteúdo do diretório, regra de comparação, base escolhida, política de acesso nem decisão tomada com o resultado.

A ideia de Heng Lu sobre especificação inicial mínima e decisão futura localizada ajuda a enxergar a medida correta desse contrato. Running-Code Primacy exige observar o parser e o servidor que realmente rodaram. As camadas de realidade mantêm texto, árvore, BER, avaliação, acesso, resposta e consequência separados.

As fontes não apontam incidente, produto atual, instalação afetada, exposição de dados ou taxa de adoção. A cadeia de RFCs prova evolução documental, não migração universal. RFC 1558 tornou o objeto de busca visível; não autorizou a aparência a substituir o recibo de execução.

Fontes