Validação de redirecionamentos HTTP para requisições autenticadas

A validação de redirecionamentos HTTP deve acontecer antes que um agente encaminhe credenciais para a próxima URL. Um redirecionamento não é uma continuação inofensiva da mesma requisição. Ele é uma instrução de um servidor remoto para fazer outra requisição, muitas vezes para uma autoridade diferente, com outro método e outro destino de rede.

Essa diferença se perde quando alguém conecta um agente a um cliente de API e deixa ativada a configuração padrão de redirecionamentos do cliente. O agente envia uma requisição para uma API aprovada. A API responde com 302 Location: https://somewhere-else/.... O cliente segue o redirecionamento. Se a autenticação for adicionada cedo demais, um invasor que controle o primeiro endpoint, um parâmetro de redirecionamento ou uma dependência comprometida pode transformar uma chamada permitida em um serviço de entrega de credenciais.

Já vi esse risco ser descartado porque bibliotecas HTTP maduras costumam remover Authorization quando o host muda. Essa proteção ajuda, mas não é universal nem suficiente. Ela não diz nada sobre cabeçalhos de credenciais personalizados, parâmetros de consulta assinados, cookies, corpos de requisições redirecionadas, mudanças de DNS ou redirecionamentos para o mesmo host que levem a um endpoint perigoso. Crie uma decisão explícita para cada redirecionamento, em vez de tratar os padrões da biblioteca como sua política.

Redirecionamentos criam uma nova decisão de autorização

Cada salto de redirecionamento precisa receber o mesmo nível de análise da primeira URL, porque é o servidor que escolhe o próximo destino. O cliente solicitou um recurso e recebeu uma resposta que propõe outro URI no campo Location. A decisão de permissão original não abrange automaticamente o URI proposto.

A RFC 9110 define os redirecionamentos por meio dos códigos de status e orienta os agentes de usuário sobre como eles podem ou devem reagir. Ela não diz que uma credencial de API anexada à requisição inicial está autorizada para todo URI que um servidor possa retornar. Essa responsabilidade fica com quem faz a chamada. Em um gateway de agentes, cabe a esse componente decidir quais ações posteriores serão executadas.

Mantenha estes dois eventos separados no código e nos registros:

1. O servidor envia uma resposta de redirecionamento para uma requisição já feita.
2. O cliente decide emitir uma nova requisição para o destino resolvido.

O primeiro evento é um fato. O segundo é uma ação privilegiada. Se sua implementação combina os dois dentro de uma chamada conveniente, como client.Do(request), com redirecionamentos automáticos ativados, você ocultou o momento em que a política precisa ser aplicada.

Um redirecionamento pode atravessar várias fronteiras de uma vez. https://api.example.test/v1/export pode apontar para https://downloads.example.test/file, que então aponta para uma URL de objeto com validade limitada em um provedor de armazenamento. Essa cadeia pode ser legítima. Ela também mostra que uma regra vaga como «o primeiro host é aprovado» diz muito pouco sobre a conexão final.

Redirecionamentos relativos exigem o mesmo cuidado. Resolva Location: ../admin em relação à URL que o produziu, usando um analisador de URLs compatível com os padrões. Não concatene strings. Um caminho que começa com // é relativo ao esquema e pode mudar o host. Delimitadores codificados e formas incomuns, como um valor Location vazio, já produziram inconsistências suficientes entre clientes para que um gateway rejeite ambiguidades em vez de tentar adivinhar.

Injete credenciais somente depois que o destino passar pela validação

A ordem segura é simples: receba a resposta, analise o destino candidato, valide-o, construa a próxima requisição e só então injete as credenciais aprovadas para aquele destino. A injeção de credenciais deve ocorrer no ponto final de envio, não em um objeto de requisição mutável que sobreviva à cadeia de redirecionamentos.

Esse é o erro de projeto que causa a maioria dos vazamentos. Um wrapper cria uma requisição com Authorization: Bearer ..., envia-a e permite que o cliente HTTP clone ou repita a requisição depois de um redirecionamento. O wrapper pode ter pretendido usar o token com um único host, mas deixa de controlar cada envio.

Use uma descrição de requisição sem material secreto. Ela pode carregar o método, o corpo, a referência da credencial permitida e a URL inicial. Para cada salto, crie uma nova requisição de rede depois da validação. A camada de envio consulta a credencial somente quando tem um destino permitido.

Um modelo compacto seria:

request intent:
  method: POST
  initial URL: https://api.acme.test/v1/reports
  credential reference: billing-api-prod
  body digest: sha256:...

for each response:
  if status is not a supported redirect: return response
  target = resolve(response.request_url, response.headers["Location"])
  decision = validate(target, request intent, response.status)
  if decision is reject: record rejection and stop
  next_request = build(decision.method, target, permitted body)
  inject(credential reference, target, next_request)
  send(next_request)

O detalhe importante não é o pseudocódigo. É o tempo de vida do segredo. O token existe somente na requisição que já passou pela validação do destino. Ele nunca fica em um objeto genérico que um callback de redirecionamento possa encaminhar por acidente.

Essa ordem também torna o escopo das credenciais aplicável. Um bearer token para api.acme.test não deve autenticar automaticamente uploads.acme.test, mesmo que os dois nomes pertençam à mesma empresa. Dê a cada regra de destino uma referência de credencial explícita. Se dois serviços compartilham uma credencial de propósito, documente essa relação na regra, em vez de deduzi-la de um sufixo DNS.

A correspondência de origem evita um vazamento, mas deixa outros passarem

Uma correspondência estrita de origem bloqueia mudanças óbvias de host, mas não resolve sozinha se uma requisição redirecionada é segura. Uma origem consiste em esquema, host e porta. Trate mudanças em qualquer um desses campos como uma fronteira, a menos que exista uma exceção explícita.

O esquema importa. Um redirecionamento de HTTPS para HTTP pode expor cabeçalhos ou o conteúdo da requisição na rede. Rejeite reduções de segurança em tráfego autenticado. Um redirecionamento de HTTP para HTTPS pode parecer seguro, mas ainda muda a autoridade e pode ocultar um endpoint inesperado. Valide-o normalmente.

A porta também importa. https://api.example.test e https://api.example.test:8443 são origens diferentes. Desenvolvedores costumam esquecer isso porque os navegadores ocultam portas padrão e ambientes de teste locais usam portas alternativas o tempo todo. Um token destinado à API pública pode acabar em um serviço administrativo se a regra verificar apenas o hostname.

O caminho importa quando um host de API atende aplicações não relacionadas. Um redirecionamento de /v1/files para /internal/debug/export permanece na mesma origem, mas pode expor um corpo ou provocar uma mudança de estado insegura. Não use uma lista de caminhos permitidos como substituta da autorização da aplicação, mas limite os destinos de redirecionamento aos prefixos de API que sua integração realmente precisa.

Os parâmetros de consulta merecem atenção especial. Um destino de redirecionamento pode carregar uma URL pré-assinada, um parâmetro de estado ou um token de download de uso único. Na prática, esses valores são credenciais, mesmo quando não usam um cabeçalho Authorization. Não copie parâmetros de consulta da requisição antiga para a nova URL. Use exatamente o destino redirecionado analisado, depois de aplicar qualquer regra que proíba campos de informações do usuário, fragmentos ou parâmetros que pareçam credenciais.

Uma regra básica prática é permitir redirecionamentos same-origin somente quando o esquema continuar sendo HTTPS, a porta continuar aprovada, o caminho de destino estiver dentro da superfície de API permitida pela integração e o status do redirecionamento permitir o método pretendido. Trate redirecionamentos entre origens como uma classe separada, com regras de destino nomeadas.

Os códigos de status dos redirecionamentos mudam a requisição que pode ser enviada

Os códigos de status de redirecionamento carregam semântica de método, e um cliente que a ignore pode transformar uma leitura segura em uma escrita inesperada ou repetir um corpo sensível. Não reduza toda resposta 3xx a «seguir Location».

A RFC 9110 diz que 307 e 308 preservam o método e o conteúdo da requisição. Se a requisição original era um POST contendo a definição de um relatório, um 307 ou 308 pede que o cliente envie esse mesmo POST e corpo ao novo destino. Esse é o caso de maior risco, porque o novo host pode receber dados de negócio e uma requisição com efeitos colaterais.

O status 303 orienta o cliente a buscar uma representação usando GET ou HEAD, independentemente do método original. Isso costuma aparecer depois de um envio no estilo de formulário. Para uma ação de agente, permita-o somente se o destino do GET redirecionado for aprovado separadamente e se a integração esperar esse padrão. Um 303 não deve herdar um cabeçalho de autorização apenas porque o POST inicial tinha um.

Os causadores históricos de problemas são 301 e 302. A RFC 9110 descreve a prática antiga de mudar POST para GET nesses casos, enquanto 307 e 308 existem para clientes que precisam preservar os métodos. As bibliotecas variam nos detalhes, especialmente com métodos que não são POST e com corpos. Nunca deixe essa ambiguidade decidir o que um cliente autônomo enviará.

Documente o comportamento. Por exemplo:

• Siga 301 e 302 somente para requisições GET e HEAD.
• Siga 303 apenas emitindo um GET ou HEAD sem credenciais e valide novamente o destino antes de adicionar qualquer credencial de leitura aprovada.
• Siga 307 e 308 somente quando a regra de destino permitir explicitamente o método original e a classe do corpo.
• Rejeite um redirecionamento depois de um método não idempotente, como POST, PATCH ou DELETE, a menos que a integração tenha um fluxo de redirecionamento documentado.

Isso pode quebrar uma API mal projetada. É preferível a repetir silenciosamente uma instrução de pagamento, um upload de código-fonte ou um comando administrativo em um local escolhido por um servidor remoto. Se um fornecedor exigir escritas redirecionadas, adicione uma exceção de escopo restrito e teste a sequência exata.

As regras de destino precisam de campos, não de uma string de hostname

Um validador de redirecionamentos útil avalia um destino com base em uma regra detalhada o suficiente para descrever o serviço que você pretendia chamar. Uma lista de permissões com hostnames simples é atraente porque é curta. Ela também é o ponto onde as exceções se acumulam até que ninguém consiga explicar o que um agente pode enviar e para onde.

Para cada destino de redirecionamento permitido, decida o seguinte:

• Quais esquemas são permitidos, normalmente apenas HTTPS.
• Quais hostnames e portas normalizados são permitidos.
• Quais métodos e prefixos de caminho a requisição redirecionada pode usar.
• Qual referência de credencial, se houver, pode ser injetada no destino.
• Se o destino pode resolver para endereços de rede privados ou locais.

Normalize antes de comparar. Converta hostnames DNS para minúsculas, remova um ponto final de forma consistente, analise corretamente literais IPv6 entre colchetes e rejeite codificação percentual malformada. Nunca compare strings de URL brutas. https://[email protected]/ tem evil.test como host, apesar de conter um nome confiável antes do sinal @.

Não use endsWith("example.test") como verificação de autoridade. Isso aceita notexample.test. Mesmo uma regra de sufixo com delimitador, como *.example.test, precisa de uma revisão de propriedade. Subdomínios curinga costumam incluir sistemas de prévia, nomes controlados por clientes, redirecionadores ou infraestrutura administrada por outro grupo.

O validador deve retornar uma decisão explicada, não apenas um booleano. Os operadores precisam saber se o sistema rejeitou uma redução de segurança do esquema, uma porta não aprovada, um método proibido, um endereço privado ou um limite de redirecionamentos esgotado. Essas informações pertencem ao registro da ação, sem valores de tokens.

Defina um limite pequeno e fixo de redirecionamentos. Um limite interrompe loops e torna uma cadeia longa visível. Não aceite uma quantidade fornecida pelo agente. O gateway controla esse limite porque controla as ações de rede.

Um fluxo comum de download pode vazar uma requisição privilegiada

Os casos perigosos raramente chegam identificados como ataques. Muitas vezes parecem endpoints comuns de conveniência que aceitam uma URL ou retornam um local de download.

Considere um agente encarregado de buscar um relatório em uma API de cobrança aprovada. O agente envia POST /v1/exports com um bearer token. A API retorna um 303 para uma URL de download. O gateway a segue automaticamente e leva o bearer token porque o injetor de cabeçalhos personalizados é executado antes do hook de redirecionamento da biblioteca HTTP.

No início, o host de download é outro serviço administrado pela mesma equipe. Meses depois, uma mudança de configuração faz o endpoint de exportação aceitar um parâmetro destination, para que os clientes possam usar um provedor de armazenamento. Um invasor com acesso aos parâmetros do relatório fornece uma URL sob seu controle. A API aprovada retorna um redirecionamento para essa URL. A biblioteca HTTP trata isso como um 303 normal, e o gateway já anexou X-Service-Token.

Nada de extraordinário aconteceu. A primeira requisição à API foi permitida, a sintaxe do redirecionamento era válida e o token nunca apareceu em um prompt do agente. A falha veio da atribuição de credenciais antes que o destino fosse conhecido.

Uma implementação correta registra o 303, resolve o destino, percebe que o host não tem uma regra de destino e interrompe o fluxo. O operador vê um redirecionamento rejeitado, não uma chamada de saída misteriosa. Se o serviço de download pretendido precisar de acesso, crie uma regra separada para o host exato e use uma credencial de download que não possa chamar a API de cobrança.

Os agentes acrescentam outra rota para essa falha. Um agente pode influenciar uma URL por meio do texto de uma tarefa, de um arquivo de configuração de repositório, de um campo de resposta de API ou de uma instrução de uma ferramenta. Não presuma que uma URL veio de um desenvolvedor apenas porque aparece dentro de uma requisição criada pelo seu agente. Dados podem se tornar entrada de roteamento muito rapidamente.

As verificações de DNS precisam ocorrer no momento da conexão

A validação do hostname, sozinha, não impede a falsificação de requisições do lado do servidor. Um hostname pode resolver para um endereço público durante a revisão e para loopback, link-local ou espaço privado quando o cliente se conecta. O tratamento de redirecionamentos dá ao invasor oportunidades repetidas de explorar essa diferença.

Resolva cada hostname aprovado próximo do momento da conexão e avalie todos os endereços retornados segundo suas regras de rede. Rejeite faixas de loopback, endereços não especificados, faixas link-local, faixas privadas, endereços multicast e equivalentes IPv6, a menos que uma regra permita explicitamente seu uso. Aplique o mesmo tratamento a endereços IP literais em URLs de redirecionamento.

Não resolva um hostname uma vez, aprove um endereço e depois deixe uma pilha HTTP separada resolvê-lo novamente. Isso cria uma diferença entre o momento da verificação e o momento do uso. A conexão precisa usar o conjunto de endereços que você avaliou, ou o transporte deve oferecer uma forma confiável de confirmar o endereço do peer e rejeitar divergências. Isso é mais difícil do que parece quando entram em cena pools de conexão, proxies e DNS de pilha dupla.

Implantações com proxy corporativo precisam de um modelo de exceção definido. Se o gateway se conecta apenas a um proxy explícito, valide o proxy como peer de rede e mantenha as regras de destino da aplicação antes de formar a requisição para o proxy. Não declare todas as faixas privadas seguras apenas porque uma organização usa endereços privados de serviço. Nomeie os hosts e portas internos de que o agente precisa.

O DNS rebinding é uma das razões pelas quais uma regra de redirecionamento não pode significar uma aprovação permanente de um hostname. O comportamento do cache, os TTLs e as diferenças entre resolvedores podem mudar a resposta. Tome a decisão para a conexão que está prestes a fazer e registre o endereço de peer selecionado, sem tratá-lo como prova de que o destino da aplicação foi autorizado.

Cookies, URLs assinadas e corpos também são credenciais

As equipes costumam proteger Authorization e deixar o restante do material de saída intocado. Um redirecionamento pode vazar credenciais ou dados sensíveis por vários outros canais.

Os cookies têm regras de domínio e caminho, mas um gateway de agentes não deve depender de um cookie jar geral, no estilo de navegador, para credenciais de máquina. Mantenha os cookies desativados por padrão em chamadas privilegiadas. Se uma integração precisar deles, limite o jar a essa integração e reavalie o envio de cookies para cada destino de redirecionamento.

URLs pré-assinadas colocam intencionalmente a autorização na string de consulta. Em geral, elas devem funcionar sem adicionar outro token de serviço. Se uma regra de destino reconhecer uma URL de armazenamento pré-assinada, envie-a exatamente com o material de autorização já presente na URL e com um método restrito, normalmente GET ou PUT. Não acrescente seus cabeçalhos padrão por hábito.

Os corpos das requisições também carregam segredos. Um corpo JSON pode conter um arquivo compactado de origem, dados de clientes ou uma asserção assinada opaca. Para 307 e 308, exija uma regra explícita que permita repetir o corpo para esse serviço específico. Para os outros códigos de redirecionamento, não transforme nem reenvie o corpo silenciosamente. A conveniência de uma biblioteca não é motivo para duplicar conteúdo sensível.

O HTTP Referer pode revelar caminhos e valores de consulta quando um cliente o adiciona. Clientes de API geralmente devem evitar transportar um cabeçalho Referer entre redirecionamentos. Da mesma forma, remova cabeçalhos que descrevam a rota interna original, a sessão do agente ou a identidade do usuário, a menos que a regra de destino precise deles explicitamente.

Classifique os cabeçalhos em três grupos: cabeçalhos que sempre podem ser recriados, cabeçalhos permitidos apenas para um destino nomeado e cabeçalhos que nunca devem atravessar um redirecionamento. Isso é mais confiável do que manter uma lista vaga de «cabeçalhos sensíveis». Content-Type pode ser inofensivo para um upload permitido; X-Internal-Actor pode identificar uma pessoa que nunca autorizou o próximo host.

Audite a cadeia como uma ação com vários saltos

Um registro de auditoria deve mostrar a cadeia de redirecionamentos sem expor o material que tornou a requisição privilegiada. Uma URL final e um código de status não bastam. Eles ocultam se o cliente atravessou uma origem, mudou o método, removeu a autenticação ou rejeitou um destino suspeito antes de se conectar.

Registre a intenção da requisição inicial, o status de cada resposta, cada valor bruto de Location depois da redação, o destino resolvido, o resultado da política, o método selecionado e a classe de credencial usada naquele salto. Registre um identificador estável da credencial, nunca um token, uma senha ou uma URL assinada completa. Aplicar hash à URL inteira pode ajudar na correlação, mas não confunda um hash com uma redação segura quando a entrada tem baixa entropia.

Associe todos os saltos a um único identificador de ação pai. Assim, um investigador pode distinguir «o agente solicitou uma exportação» de «o gateway fez quatro chamadas de rede para concluir a exportação». Isso também permite que um operador revogue uma sessão ativa quando a cadeia começar a se comportar de forma inesperada.

Um registro à prova de adulteração fornece evidências úteis depois do fato, mas não interrompe um redirecionamento inseguro. A prevenção pertence ao caminho de encaminhamento. O Sallyport registra sessões de agentes e chamadas individuais em um único registro de auditoria criptografado e encadeado por hash, para que os registros de ações com consciência de redirecionamentos preservem o histórico das decisões, em vez de reduzir a cadeia a um resultado final.

Teste o registro com casos deliberadamente rejeitados. Provoque um 302 entre origens, um redirecionamento de HTTPS para HTTP, um 307 depois de um POST, um campo Location malformado e um destino que resolva para loopback. Se esses registros não explicarem ao revisor por que o gateway interrompeu o fluxo, melhore o esquema de eventos antes que um incidente force essa mudança.

Faça do comportamento de redirecionamento parte do contrato da ferramenta

Uma ferramenta que chama uma API HTTP precisa informar aos usuários se segue redirecionamentos e em quais condições. «Usa HTTP padrão» não é um contrato. O comportamento varia entre bibliotecas e muda quando alguém substitui um cliente, adiciona um proxy ou move a autenticação para um middleware.

Escreva testes usando um fixture local de redirecionamento com endpoints distintos. O fixture deve retornar códigos de status e valores Location controlados e capturar o método recebido, o hash do corpo, o host e os cabeçalhos. Suas asserções devem provar que um destino não aprovado não recebe nenhum cabeçalho de credencial, que um 303 não repete o corpo de um POST e que um 307 permitido envia somente os cabeçalhos e o corpo autorizados pela regra.

Não permita que o agente selecione uma política de redirecionamento nos argumentos da ferramenta. Um agente pode solicitar uma integração conhecida e fornecer parâmetros comuns de requisição. O gateway decide se o acompanhamento de redirecionamentos existe para essa integração, quantos saltos são permitidos e quais credenciais podem ser usadas. Essa separação impede que uma injeção de prompt se transforme em follow_redirects=true.

Para uma primeira implementação, escolha um contrato deliberadamente restrito: siga redirecionamentos HTTPS aprovados somente para GET e HEAD, injete credenciais por destino depois da validação e rejeite toda escrita redirecionada. Adicione exceções apenas depois que conseguir explicar o fluxo do fornecedor, a fronteira do destino, o comportamento do método e o registro de auditoria. Algumas rejeições explícitas vão incomodar os desenvolvedores. Um token enviado a um invasor incomodará muito mais.