Vulnerabilidades de Segurança

[giovanecarusoredacao]

Nosso token de acesso está exposto - Já subimos pra staging

Próximos passos:
*Testar e subir para produção

Nesse PR pra staging deixei listado uma lista das validações que estou fazendo.

[AldemirLucas]

O que estava acontecendo

O token de login (a “chave” da sessão do usuário) estava sendo tratado de um jeito inseguro:

1. Ia na URL em algumas chamadas (codificado em base64, que qualquer um consegue ler de volta). Isso podia vazar em logs do servidor, histórico do navegador e cabeçalhos de referência.
2. Ficava acessível pelo JavaScript do site (cookie sem HttpOnly). Se existisse qualquer falha de XSS no site, o token podia ser roubado e a conta usada por outra pessoa.
3. O frontend do chatbot mandava o token manualmente nas requisições. O ideal é o servidor ler a sessão sozinho, sem o browser precisar “carregar” o token.

O que isso causava na prática

• Risco real de vazamento de sessão (alguém usar a conta de outra pessoa).
• A “trava” de acesso ao chatbot existia só na tela. Quem soubesse chamar a API direto podia tentar burlar.
• Em falha de login/sessão, o cookie às vezes não era limpo de verdade, e a sessão “fantasma” podia continuar no navegador.

O que resolvemos

• O token não vai mais na URL.
• O cookie de sessão passou a ser HttpOnly (o JavaScript da página não consegue lê-lo).
• As rotas do chatbot no Next leem a sessão no servidor e checam se o usuário tem acesso antes de seguir.
• Logout e erro de autenticação limpam a sessão corretamente.
• O cache de validação ficou mais curto, e 401/403 no chatbot levam de volta ao login.