O xtunnel, uma ferramenta de tunelamento russa que se posiciona como alternativa a serviços como o ngrok, tem demonstrado um comportamento inesperado que pode criar sérias vulnerabilidades em aplicações web. Durante o desenvolvimento de um projeto educacional, foi observado que o xtunnel pode interferir na forma como os cookies são tratados, especialmente aqueles marcados como HTTPOnly. Essa configuração, destinada a impedir o acesso a cookies por scripts do lado do cliente, é fundamental para a segurança de sessões e tokens de autenticação.
O problema reside na maneira como o xtunnel gerencia e armazena em cache esses cookies. Em um cenário típico, um cookie HTTPOnly definido em um endpoint de login, como demonstrado no código Java Spring abaixo, não deveria ser acessível ou manipulado por proxies ou ferramentas de tunelamento de forma indiscriminada. No entanto, o xtunnel parece cachear esses cookies e, de forma preocupante, pode inseri-los em requisições subsequentes, mesmo quando não solicitados pelo contexto da sessão atual. Isso significa que, se um usuário fizer login e seu token HTTPOnly for cacheado pelo xtunnel, qualquer outra requisição que passe pelo túnel, independentemente de quem a originou, poderá ter esse token anexado.
javaprivate void setTokenCookie(String token, HttpServletRequest request, HttpServletResponse response) { if (token == null) { return; } ResponseCookie cookie = ResponseCookie.from(JwtAuthFilter.TOKEN_COOKIE, token) .httpOnly(true) .secure(request.isSecure()) .sameSite("Lax") .path("/api") .maxAge(Duration.ofMillis(expirationMs)) .build(); response.addHeader(HttpHeaders.SET_COOKIE, cookie.toString()); }
Essa falha de segurança é particularmente perigosa quando combinada com endpoints que consomem tokens de autenticação diretamente de cookies, como o método get exemplificado abaixo. Se o xtunnel insere o cookie de um usuário logado em uma requisição feita por outro usuário, o sistema interpretará a requisição como se fosse do usuário original, permitindo que um atacante se passe por outro usuário sem a necessidade de realizar o login. Isso abre portas para acesso não autorizado a dados e funcionalidades restritas, contornando completamente os mecanismos de autenticação e autorização da aplicação. Desenvolvedores que utilizam o xtunnel, especialmente em ambientes de desenvolvimento ou testes onde a segurança pode ser menos rigorosa, devem estar cientes desse risco e considerar alternativas ou implementar salvaguardas adicionais para mitigar essa brecha de segurança.
