Как xtunnel может скомпрометировать все аккаунты в вашем приложении

xtunnel - российский туннель, который позиционирует себя аналогом ушедшего из России ngrok. Сегодня, работая над учебным проектом, я заметил за ним любопытное поведение. Например, мы ставим на логине токен как http only куку (ниже и дальше будет представлен код на Java Spring, но подобное поведение аналогично во всех языках):

private 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());
    }

Нормальные туннели не трогают такие куки, однако xtunnel такую куку закеширует (!) и будет подставлять ее в релеватные запросы по требованию кого угодно (!!). Например, в следующий метод, кто бы его не вызвал, xtunnel подставит куки последнего залогинного пользователя:

@GetMapping
    public ResponseEntity<?> get(
            @CookieValue(name = JwtAuthFilter.TOKEN_COOKIE, required = false) String token) {
        if (token == null) {
            return ResponseEntity.status(HttpStatus.UNAUTHORIZED).build();
        }
        // do something
    }

Таким образом, пользователи в обход логина могут представляться другими пользователями, и все аккаунты скомпрометированны.

@gth-other
26.06.2026 00:55 UTC
Первоисточник

Комментарии

@jidckii
28.06.2026 18:54 UTC
+1

Надо было tuna использовать, там нет таких проблем))

@xtunnel
17.07.2026 11:28 UTC
0

Здравствуйте.

Отчёт верный, подтвердили в коде в тот же день.
Исправили.
Сразу про границу: затрагивалось приложение за конкретным туннелем — не платформа и не туннели других пользователей; подставлялась сессия последнего залогинившегося. В этих пределах всё ровно так, как Вы описали, и это критично.

Причина: обратный прокси в CLI держал общий CookieContainer (унаследованный дефолт UseCookies=true ). Прокси не должен владеть состоянием пользователя — куки обязаны идти транзитом. Поэтому httpOnly и не спасал: подстановка шла на стороне прокси, а не в браузере.

Исправлено в v2.8.1, закрыто регрессионными тестами на Ваш сценарий.

Обновитесь:

brew upgrade xtunnel

choco upgrade xtunnel

https://xtunnel.ru/#rec673966178

Спасибо за публичный разбор — он ускорил починку.