As sessões dos seus aplicativos auto-hospedados expiram no momento certo? Um checklist prático de avaliação

Por que o comportamento das sessões importa após o login

A autenticação confirma que um usuário fez login. A sessão permite que o aplicativo reconheça esse usuário enquanto ele navega entre páginas ou volta ao app. Se uma sessão continuar válida por mais tempo do que o previsto, alguém com acesso ao navegador ou a uma credencial de sessão copiada poderá continuar usando a conta.

Um tempo limite configurado não prova que todos os fluxos relevantes expiram como deveriam. Logout, alterações de conta e SSO podem envolver partes diferentes do sistema. Avalie e teste o ciclo de vida da sessão, em vez de procurar apenas uma configuração.

A OWASP recomenda aplicar a expiração de sessão no servidor e invalidar a sessão quando o usuário fizer logout ([Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)). O NIST afirma que os cookies de sessão devem expirar no momento da validade da sessão ou logo depois ([Session Management](https://pages.nist.gov/800-63-4/sp800-63b/session/)). Use essas orientações como verificações, sem presumir que todos os aplicativos oferecem os mesmos controles.

Diferencie login, duração da sessão, inatividade e dispositivos lembrados

Login é a etapa de autenticação. Uma sessão é o reconhecimento contínuo, pelo aplicativo, desse login. Como ela pode ser mantida por mais de um mecanismo, a data de expiração exibida para um cookie do navegador talvez não indique se o servidor ainda aceita a sessão.

Um tempo limite de inatividade encerra a sessão após um período sem atividade. A duração máxima da sessão, às vezes chamada de duração absoluta, limita por quanto tempo ela pode permanecer válida, independentemente da atividade. Consulte a documentação e teste o comportamento: não presuma que a atividade reinicia o limite ou que toda configuração chamada “tempo limite da sessão” tem o mesmo significado.

Uma opção “manter conectado” ou de dispositivo lembrado pode alterar o que o usuário encontra em uma visita posterior. Descubra o que ela faz no aplicativo específico e registre esse comportamento separadamente do tempo limite de inatividade.

Defina requisitos com base nos fluxos reais e nos riscos

Escolha os requisitos considerando como o aplicativo é usado e o que uma sessão válida ou sem supervisão poderia expor. Uma estação de trabalho compartilhada, o acesso a registros empresariais confidenciais ou a possibilidade de realizar alterações importantes podem exigir expectativas diferentes das de um aplicativo usado brevemente em um dispositivo privado.

Registre o comportamento esperado antes de testar: após inatividade, ao atingir a duração máxima, depois do logout e quando um administrador desativar uma conta. Para alterações de senha e eventos de SSO, defina o resultado necessário sem presumir que o aplicativo ou o provedor de identidade cuidará disso automaticamente.

As fontes citadas não estabelecem um único valor de tempo limite para todos os aplicativos e fluxos. Tome essa decisão de forma explícita, equilibrando segurança e usabilidade, e documente exceções, como uma sessão necessária durante uma tarefa demorada.

• Quais dados ou ações estão disponíveis, e o que uma sessão sem supervisão poderia permitir?
• É provável que os usuários trabalhem em dispositivos compartilhados ou sem supervisão?
• O que deve acontecer após a inatividade e qual é a duração máxima aceitável de uma sessão?
• Quais eventos devem encerrar o acesso: logout, alteração de senha, desativação da conta ou alteração no provedor de identidade?
• Existe uma opção de dispositivo lembrado, e o comportamento dela é aceitável para seu caso de uso?

Consulte a documentação do aplicativo para identificar os controles disponíveis

Pesquise na documentação oficial do aplicativo e da versão que você opera por termos como expiração de sessão, tempo limite de inatividade, duração máxima, logout, revogação de sessão, dispositivos lembrados e SSO. Não deduza que um recurso existe com base em um produto de nome semelhante ou em uma configuração de outro aplicativo.

Registre se cada controle é configurável, onde é configurado e se a documentação descreve sua aplicação no servidor. A expiração de um cookie e uma regra de validade de sessão no servidor são verificações relacionadas, mas uma não comprova a outra. Marque como desconhecido qualquer fluxo que a documentação não explique.

As orientações da OWASP e do NIST apoiam a verificação da expiração no servidor, da invalidação no logout e da expiração dos cookies em relação à validade da sessão. Elas não especificam controles para cada aplicativo nem os resultados de fluxos como alteração de senha, desativação de conta ou duração máxima.

• Registre o significado documentado de cada configuração de tempo limite, incluindo se a atividade reinicia o contador.
• Procure uma forma documentada de encerrar ou revogar sessões ativas e anote seu escopo.
• Verifique se o comportamento difere entre contas locais e usuários de SSO.
• Guarde o título da documentação, a versão ou data, quando disponíveis, e a data em que a consultou.

Faça testes práticos do ciclo de vida

Sempre que possível, use uma conta de teste e um ambiente que não seja de produção. Se precisar testar em produção, planeje o trabalho para evitar interrupções ou alterações inesperadas no acesso a contas reais. Não inclua credenciais de sessão ou outros segredos em capturas de tela ou anotações compartilhadas.

Para testar a inatividade, faça login, deixe o aplicativo sem uso pelo intervalo configurado e tente abrir uma página protegida ou realizar uma ação inofensiva. Teste separadamente a duração máxima: mantenha a sessão ativa conforme o plano e verifique se ela termina no limite indicado. Registre o tempo decorrido e o que o usuário vê.

Para testar o logout, encerre a sessão e tente acessar novamente uma página protegida usando o mesmo contexto do navegador. A OWASP recomenda invalidar a sessão no logout; registre se a sessão antiga ainda permite acesso. Um redirecionamento para a página de login, por si só, não é conclusivo se o conteúdo protegido continuar acessível por outra rota.

Teste a alteração de senha e a desativação da conta como eventos distintos. Verifique se as sessões existentes continuam funcionando e compare o resultado com o requisito documentado.

Use uma ação de teste inofensiva e autorizada para confirmar o status do acesso. Se o resultado não estiver claro, repita o teste em uma sessão limpa do navegador e consulte a documentação ou o canal de suporte do aplicativo.

Repita as verificações para SSO e contas locais

Se o aplicativo oferecer login local e SSO (login único), teste cada fluxo separadamente. O aplicativo e o provedor de identidade podem ter sessões distintas; encerrar uma não prova que a outra também foi encerrada.

Para SSO, registre a sequência e o resultado do logout do aplicativo e do provedor de identidade. Verifique o que acontece quando o usuário retorna ao aplicativo e tenta usar uma página que já estava aberta. Para contas locais, repita os testes relevantes sem presumir que o comportamento de SSO se aplica.

Se o aplicativo ou o provedor de identidade oferecer controles de revogação, documente o que afirmam revogar e confirme o efeito em um teste. Registre como lacuna qualquer comportamento que não esteja documentado ou não possa ser testado.

Registre o comportamento esperado e as evidências em uma matriz de testes

Uma matriz compacta transforma verificações pontuais em evidências operacionais reproduzíveis. Mantenha o resultado esperado separado do observado: o primeiro representa sua política; o segundo registra o que o aplicativo fez durante o teste.

Inclua o aplicativo e a versão, o método de autenticação, a data, a configuração relevante, a conta de teste, as etapas, o tempo decorrido quando pertinente, o resultado observado e o status: aprovado, reprovado ou não resolvido. Anote a documentação consultada e a próxima ação para as lacunas. Evite registrar senhas, tokens de sessão ou outras credenciais.

Repita a matriz após mudanças significativas na configuração do aplicativo, na autenticação ou na implantação. A frequência é uma decisão operacional da sua equipe.

• Inatividade: condição de encerramento esperada, intervalo testado e se o acesso protegido continuou disponível.
• Duração máxima da sessão: limite esperado, se a sessão permaneceu ativa durante o teste e horário de encerramento observado.
• Logout: invalidação esperada e resultado ao reutilizar o mesmo contexto do navegador.
• Alteração de senha e desativação da conta: impacto esperado nas sessões existentes e resultado observado.
• SSO e login local: teste cada fluxo aplicável e registre a sessão de qual sistema estava envolvida.
• Lacunas: controles sem documentação, resultados não verificados e responsável pelo acompanhamento.

Atribua responsabilidades entre o aplicativo, o provedor de identidade e a hospedagem

Não presuma que uma única parte controla todo o ciclo de vida da sessão. Associe cada comportamento esperado ao componente que pode configurá-lo ou verificá-lo na sua implantação. A distribuição exata depende do aplicativo, do provedor de identidade, do modelo de hospedagem e dos acordos vigentes.

O responsável pelo aplicativo deve documentar a política de acesso, verificar o comportamento do aplicativo e decidir como lidar com lacunas. Nos fluxos de SSO, coordene com o administrador do provedor de identidade e teste a experiência combinada. Deixe explícita a divisão de responsabilidades, em vez de presumir que o SSO ou a hospedagem cuidará da revogação.

A Airbip oferece implantação gerenciada de aplicativos do catálogo como cargas de trabalho Docker em servidores na nuvem da Airbip, com roteamento automatizado e certificados TLS por meio do Traefik e do Let’s Encrypt, além de gerenciamento do ciclo de vida dos serviços e backups configuráveis. Esses recursos de infraestrutura não determinam o que um aplicativo faz quando uma sessão expira ou uma conta é desativada.

Se o aplicativo não oferecer um controle de sessão necessário, não trate o gerenciamento da infraestrutura como substituto, a menos que um controle documentado e testado atenda ao requisito. Registre a lacuna e decida se deve alterar a configuração, adicionar um controle adequado, escolher outro aplicativo ou modelo de implantação, ou aceitar o risco residual.

• Defina quem é responsável pela política de tempos limite e pela aprovação de exceções.
• Defina quem configura e testa o comportamento das sessões no aplicativo.
• Para SSO, identifique o administrador do provedor de identidade e os comportamentos que ele pode confirmar.
• Documente as tarefas de hospedagem separadamente do acesso ao aplicativo e da governança de contas.
• Acompanhe comportamentos não verificados com uma decisão ou ação de acompanhamento.