Resumo

  • Forwarded e X-Forwarded-For carregam alegações sobre o trajeto, não identidade autenticada. A observação própria do receptor é o par de transporte; endereços anteriores dependem de delegação explícita.
  • A trilha deve preservar linhas e ordem recebidas, parser, versão da política de confiança, primeiro limite não confiável e decisão consumidora. Sintaxe correta não concede autoridade.

O erro veio depois da análise

“Cabeçalhos podem ser falsificados” é verdade, mas insuficiente. Cabeçalhos são entrada do cliente. A falha decisiva acontece quando o sistema promove essa entrada a fato sobre a conexão.

O socket oferece um dado mais estreito: o endereço que estabeleceu o enlace imediato. Em uma arquitetura normal ele pode ser o balanceador, não o usuário. Ainda assim, é o ponto observado localmente a partir do qual uma cadeia de delegações pode ser validada.

Se esse par não estiver autorizado a apresentar metadados de encaminhamento, a busca termina. Usar o par ou rejeitar a rota direta são decisões defensáveis. Ignorá-lo e escolher o elemento mais à esquerda permite que o próprio solicitante selecione a origem que deseja reivindicar.

O limite declarado pelo RFC 7239

O RFC 7239 define Forwarded como campo opcional para revelar informações alteradas ou perdidas quando um proxy participa do caminho. for, by, host e proto descrevem aspectos diferentes de um salto. Sua correlação não cria uma credencial.

O padrão afirma que não se pode presumir a correção do campo: qualquer nó no caminho, inclusive o cliente, pode modificá-lo por engano ou malícia. Verificar proxies e autorizá-los dá peso ao que cada um observou. Não valida automaticamente um prefixo recebido antes deles, nem protege um trecho posterior sem segurança.

unknown e identificadores ofuscados também são resultados válidos. Eles registram desconhecimento ou proteção de privacidade, não um IP defeituoso a ser convertido. Ausente, desconhecido, ofuscado, inválido e endereço normalizado precisam permanecer estados distintos.

XFF não herda a gramática padronizada

X-Forwarded-For é uma prática anterior e não é o campo definido pelo RFC 7239. A semelhança de listas separadas por vírgulas não uniformiza os produtos.

O AWS ALB pode anexar, preservar ou remover XFF. No modo append, conserva o valor de entrada e adiciona à direita o endereço que observou. Isso explica o elemento adicionado pelo balanceador, mas não autentica o conteúdo à esquerda.

O HAProxy documenta separadamente a inserção de XFF e a geração de Forwarded. O receptor precisa saber campo, posição, política de remoção ou acréscimo e algoritmo exatos. “Primeiro” e “último” só têm sentido dentro desse contrato.

Ancorar no lado observável

No NGINX, set_real_ip_from define quem pode enviar valores corretos de substituição. Com real_ip_recursive on, a resolução encontra o último endereço não confiável depois de atravessar a parte permitida; $realip_remote_addr mantém o par original.

O Apache mod_remoteip percorre da direita para a esquerda e alerta que aceitar intermediários sem restrição torna trivial personificar outro endereço. O Envoy conta saltos a partir da direita, com regras que mudam conforme use_remote_address, e oferece seleção por CIDRs confiáveis.

Essas configurações mostram por que não existe um comando universal “obter IP real”. Existe uma topologia comprovada para um listener. Adicionar CDN, remover proxy ou abrir caminho alternativo muda a posição do primeiro nó sem confiança.

Duplicatas expõem divergências

O RFC 9110 permite combinar linhas repetidas de campos com sintaxe de lista, preservando a ordem e separando-as por vírgulas. Um proxy pode ver linhas brutas, a biblioteca uma única string e o framework um vetor. Testes com duplicatas revelam se autorização e logs interpretam a mesma solicitação.

IPv6 também desafia divisões simplistas: há dois-pontos no endereço, um possível delimitador de porta, colchetes e aspas. Casos negativos devem incluir IPv6 com porta, IPv4 com porta, unknown, identificadores ofuscados, espaços e separadores malformados.

Normalização responde qual valor foi lido. Confiança responde por que o remetente podia fornecê-lo. Um sistema auditável conserva ambas.

host e proto precisam de regras próprias

Após terminação TLS, host e esquema encaminhados podem orientar redirecionamentos, URLs absolutas e cookies Secure. proto=https escrito por um cliente não prova que uma borda confiável recebeu TLS. Um host encaminhado também não autentica a origem.

Cada parâmetro deve ter fonte e consumidor declarados. É possível aceitar o endereço observado pela borda e obter o host público de um mapa fixo. A utilidade de um parâmetro não autoriza o campo inteiro.

PROXY protocol é outro livro

PROXY protocol leva origem e destino antes do HTTP. Sua posição no transporte não o autentica. O receptor deve esperá-lo em listener dedicado ou fortemente filtrado e aceitar somente emissores autorizados; caso contrário, qualquer cliente escreve um preâmbulo com origem falsa.

Par efetivo, expectativa e aceitação do preâmbulo, endereço declarado e cabeçalhos HTTP devem permanecer separados. Sobrescrever tudo em client_ip apaga a cadeia de custódia.

A especificação aparece nos testes de negação

Tente alcançar o origin fora da borda. Se o desenho proíbe isso, a conexão deve falhar antes do HTTP. Em seguida, envie um IP permitido em XFF por um par não confiável e confirme que ele não é adotado.

Pela rota legítima, acrescente prefixo falso, insira proxy não autorizado, retire e adicione saltos. Envie duplicatas e formas difíceis de IPv6. Compare borda, origin, framework, limitador, autorização e logs. Por fim, mande um preâmbulo PROXY de uma fonte não autorizada.

Uma configuração mostra intenção. Esses conflitos controlados mostram o comportamento em execução.