Guia de resolução de problemas de sessões de aplicações auto-hospedadas devido a alterações no proxy e nos cookies

A abordagem segura consiste em tratar uma comparação camada a camada entre pedidos diretos e pedidos através de proxy, cookies de resposta, armazenamento do navegador e estado da sessão no backend como uma sequência de pontos de verificação observáveis, e não como um único comando.

Numa aplicação Web auto-hospedada atrás de um proxy inverso, o risco prático é os utilizadores terminarem a sessão, ficarem presos num ciclo de redirecionamento ou não conseguirem estabelecer uma sessão após alterações no proxy ou nos cookies. Registe a identidade atual e o ponto de recuperação, comece pelo discriminador menos invasivo, interprete os resultados positivos e negativos antes de alterar outra variável e pare quando o armazenamento se tornar instável ou a única cópia recuperável ficar exposta. O fluxo de trabalho abaixo só termina quando a carga de trabalho original for bem-sucedida ou quando as evidências atingirem um limite de escalamento.

Reproduza um único percurso de sessão e preserve as evidências

Escolha um utilizador, perfil do navegador, nome de anfitrião e percurso de início de sessão. Registe o primeiro pedido que falha, a sequência de estados, os locais de redirecionamento, os cabeçalhos de resposta Set-Cookie com os valores ocultados, os cookies do pedido, os registos do proxy, os registos da aplicação e a alteração exata da configuração que precedeu a falha.

Não comece por limpar todos os cookies nem por alterar o segredo da aplicação. Utilize um perfil de navegação privado como controlo limpo, preservando o perfil com falhas para comparação. Confirme se o acesso direto ao backend funciona; isso separa a autenticação da aplicação do comportamento de URL e de cookies derivado do proxy.

Pare se a aplicação expuser tokens nos registos, se o proxy aceitar cabeçalhos de encaminhamento falsificados de clientes não confiáveis ou se o início de sessão contornar o TLS. Proteja as credenciais e corrija o limite de segurança antes de continuar a resolução funcional de problemas.

Verifique o esquema, o anfitrião e a confiança no encaminhamento

Compare o URL externo com aquilo que a aplicação considera: esquema, anfitrião, porta, caminho base e IP do cliente. Inspecione Host, X-Forwarded-Proto ou cabeçalhos de encaminhamento normalizados, bem como a lista de proxies confiáveis da aplicação. Um backend que considere que os pedidos HTTPS são HTTP pode recusar cookies Secure ou gerar um redirecionamento interminável para HTTPS.

Utilize um único proxy confiável para definir ou substituir os cabeçalhos de encaminhamento e configure a aplicação para confiar apenas nesse salto. Não acrescente cegamente valores fornecidos pelo cliente. Teste um início de sessão e um redirecionamento absoluto após cada alteração, em vez de alterar simultaneamente os cabeçalhos do proxy e o URL base da aplicação.

O guia da ZimaSpace sobre o diagnóstico de início de sessão direto versus através de proxy utiliza a mesma comparação entre acesso direto e através de proxy após o reinício de um proxy. O exemplo do Immich é mais específico, mas o percurso das evidências é aplicável: comprove que a sessão do backend funciona e, em seguida, inspecione os cabeçalhos de encaminhamento, o encaminhamento e o estado do navegador.

Inspecione o âmbito dos cookies e as decisões do navegador

Verifique o nome do cookie, Domain, Path, Secure, HttpOnly, SameSite, a expiração e a existência de cookies duplicados com o mesmo nome em caminhos ou domínios diferentes. As ferramentas de desenvolvimento do navegador mostram se um cookie foi armazenado, rejeitado ou omitido do pedido seguinte; os registos do servidor, por si só, não revelam essa decisão.

O artigo da OWASP sobre o comportamento dos cookies SameSite explica como os valores SameSite controlam o envio de cookies entre sites. Se a autenticação atravessar sites ou utilizar um fluxo incorporado, SameSite=None também requer Secure; numa aplicação simples no mesmo site, alargar desnecessariamente o cookie enfraquece o desenho.

Elimine apenas o cookie afetado no perfil de controlo depois de o registar e, em seguida, repita o início de sessão. Se um cookie novo funcionar enquanto o perfil preservado falhar, compare o âmbito e a expiração; se ambos falharem, volte aos cabeçalhos de resposta ou ao armazenamento da sessão no backend, em vez de continuar a limpar o estado.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifique o estado partilhado da sessão e valide a correção

Em aplicações com vários contentores ou replicadas, confirme que todas as instâncias utilizam o mesmo segredo de assinatura da sessão, a mesma fonte de tempo e o mesmo backend de sessão partilhado, quando necessário. Um proxy que alterne entre instâncias pode parecer causar terminações de sessão aleatórias quando uma instância não consegue validar o cookie de outra.

A análise da PortSwigger sobre o limite de segurança SameSite centra-se na segurança, mas esclarece que SameSite é um limite do navegador e não um interruptor genérico para reparar inícios de sessão. Preserve a proteção contra CSRF, correspondendo à origem real e ao fluxo de redirecionamento da aplicação.

Valide o início de sessão, o fim de sessão, a expiração por inatividade, o reinício do navegador, a alteração da palavra-passe e o acesso através dos nomes de anfitrião internos e remotos previstos. Feche o problema apenas quando os cookies antigos falharem de forma segura, as sessões novas sobreviverem ao encaminhamento normal e nenhum atributo de encaminhamento ou de cookie tiver sido flexibilizado para além da necessidade documentada.