Какая информация будет раскрыта при перехвате запроса?

Краткий ответ

При перехвате (сниффинге) HTTP/HTTPS-запроса раскрывается огромный объём конфиденциальной информации, степень которой зависит от типа соединения (HTTP или HTTPS) и используемых средств перехвата.

Детализация раскрываемой информации

1. При перехвате незашифрованного HTTP-трафика

Вся информация передаётся в открытом виде. Перехватчик видит:

• Метаданные запроса:

  GET /api/users/profile HTTP/1.1
  Host: example.com
  User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
  Accept: application/json, text/html
  Accept-Language: ru-RU,ru;q=0.9
  Connection: keep-alive
  

• Учётные данные и токены:

    *   `Authorization: Basic dXNlcjpwYXNzd29yZA==` (Base64-кодированные логин и пароль).
    *   `Cookie: session_id=abc123def456; auth_token=xyz789`.
    *   Параметры в URL: `https://site.com/login?username=admin&password=12345` (если часть URL после `?`).

• Тело запроса (Request Body): Все данные формы (логины, пароли, платёжные реквизиты, личные сообщения) передаются как plain text.

  POST /login HTTP/1.1
  ...
  Content-Type: application/x-www-form-urlencoded
  
  username=ivan&password=mySecretPassword&remember_me=true
  

• Параметры, заголовки и путь: Полный URL, включая query-параметры, заголовки, которые могут содержать служебную информацию о клиенте, его предпочтениях и сессии.

2. При перехвате HTTPS-трафика (с помощью MITM-атаки)

HTTPS (HTTP over TLS/SSL) создан для защиты от такого перехвата. Однако с помощью поддельного корневого сертификата (например, в корпоративных сетях или при установке специального ПО) можно расшифровать трафик. В этом случае раскрывается **всё то же, что и в HTTP**, плюс:

• Сертификат сервера, который можно подменить.
• Ключи сессии после успешного установления MITM-соединения.

Без успешной MITM-атаки (простой сниффинг сетевого интерфейса) для HTTPS будет видно лишь:

• IP-адреса и порты источника и назначения.
• Доменное имя (SNI) при установлении соединения.
• Объём и время передачи данных.
• Факт соединения с определённым сервисом.

3. Структура типичного перехваченного запроса (HTTP)

POST /api/v1/orders HTTP/1.1               # Метод и эндпоинт
Host: shop.example.com                     # Целевой домен
User-Agent: Go-http-client/1.1             # Клиентское приложение
Content-Type: application/json             # Формат данных
Authorization: Bearer eyJhbGciOiJ...       # Токен доступа (JWT)
Cookie: cart_id=session_abc; locale=ru     # Куки
Accept-Encoding: gzip                      # Поддерживаемое сжатие

{"product_id": 456, "quantity": 2, "card_last_four": "7890"}  # Тело запроса (JSON)

4. Какие уязвимости и атаки становятся возможными

• Кража сессии (Session Hijacking): Перехват session_id из кук или заголовков.
• Кража учётных данных: Прямое получение логинов, паролей, API-ключей, OAuth-токенов.
• Атака «человек посередине» (Man-in-the-Middle, MITM): Активное вмешательство в трафик, модификация запросов или ответов.
• Анализ поведения пользователя (Profiling): По URL и заголовкам можно определить, какие страницы посещает пользователь, каким ПО пользуется.
• Внедрение вредоносного кода: Подмена ответа от сервера (например, JavaScript).

5. Как защититься от перехвата (Меры для Go-разработчика)

1. Всегда использовать HTTPS. Принудительный редирект с HTTP на HTTPS.

   // Использование TLS в сервере Go
   err := http.ListenAndServeTLS(":443", "server.crt", "server.key", nil)
   

2. Применять HSTS (HTTP Strict Transport Security). Заголовок, предписывающий браузеру использовать только HTTPS.

   w.Header().Set("Strict-Transport-Security", "max-age=63072000; includeSubDomains")
   

3. Защищать куки. Устанавливать флаги Secure, HttpOnly, SameSite.

   http.SetCookie(w, &http.Cookie{
       Name:     "session",
       Value:    sessionID,
       Secure:   true,    // Только по HTTPS
       HttpOnly: true,    // Недоступно из JavaScript
       SameSite: http.SameSiteStrictMode,
   })
   

4. Хэшировать и солить пароли. Никогда не передавать и не хранить в открытом виде.
5. Использовать токены с ограниченным временем жизни (JWT с коротким expiry).
6. Валидировать и санитизировать все входящие данные.
7. Для внутренних сервисов использовать mTLS (mutual TLS) для взаимной аутентификации клиента и сервера.

Вывод для Go-разработчика

Как разработчик, вы обязаны проектировать системы с предположением, что сеть ненадёжна (zero-trust network). Все конфиденциальные данные должны передаваться исключительно по защищённому каналу (TLS 1.2/1.3). В Go это обеспечивается стандартными пакетами crypto/tls и net/http. Помните, что перехват запроса — это не только теоретическая угроза, но и реальный инструмент отладки (например, через прокси-серверы вроде Charles Proxy или mitmproxy), который наглядно демонстрирует, насколько уязвим незашифрованный трафик. Безопасность должна быть не опцией, а базовым принципом разработки.