Куда отправлял пароль при регистрации?

Разбор вопроса и стратегия ответа

Вопрос "Куда отправлял пароль при регистрации?" на собеседовании для QA Engineer — это проверка понимания безопасности данных, архитектуры веб-приложений и типичных уязвимостей. Он звучит просто, но требует детального развернутого ответа, затрагивающего принципы работы клиент-серверного взаимодействия, методы аутентификации и распространенные ошибки в реализации.

Основные принципы безопасной передачи пароля

В правильно спроектированной современной системе пароль никогда не должен отправляться или храниться в открытом (plain text) виде. Вот типичный безопасный flow:

1. На стороне клиента (браузера): Пароль, введенный пользователем в форму, должен быть хеширован или обработан перед отправкой. Часто для этого используется JavaScript-библиотека или встроенные механизмы. Однако более надежный и современный подход — использование HTTPS (TLS/SSL), который шифрует весь канал связи, делая перехват данных между браузером и сервером крайне сложным.
2. Передача по сети: Зашифрованные данные (или хеш) пароля отправляются по защищенному каналу HTTPS на сервер.
3. На стороне сервера (Backend): Это ключевой этап. Сервер должен получить данные и выполнить дополнительную обработку:

    *   Если от клиента пришел хеш, его необходимо *досолить* (добавить уникальную `salt`) и повторно захэшировать более стойким алгоритмом (например, **bcrypt, Argon2, scrypt**). Отправка "готового" хеша с клиента менее безопасна, так как этот хеш сам становится эквивалентом пароля.
    *   Чаще на сервер приходит пароль (зашифрованный TLS), и вся криптография происходит уже там.
    *   **Сравнение происходит не с самим паролем, а с его хешем.** Сервер вычисляет хеш от полученного пароля (с применением `salt`, хранящегося в БД для этого пользователя) и сравнивает его с хешем, хранящимся в базе данных.

// Пример ПЛОХОЙ реализации (НИКОГДА ТАК НЕ ДЕЛАЙТЕ)
// Клиент отправляет пароль в открытом виде
fetch('/api/register', {
  method: 'POST',
  body: JSON.stringify({ username: 'user', password: 'MySecret123' }) // ПАРОЛЬ В ОТКРЫТОМ ВИДЕ!
});

// Пример ЛУЧШЕЙ практики (упрощенно)
// 1. Клиент: Отправка по HTTPS (шифрование на уровне транспорта)
// 2. Сервер (Node.js/Express псевдокод):
const bcrypt = require('bcrypt');
const saltRounds = 10;

app.post('/api/register', async (req, res) => {
  const { username, plainTextPassword } = req.body; // Пароль пришел по HTTPS

  // Хеширование с солью на сервере
  const passwordHash = await bcrypt.hash(plainTextPassword, saltRounds);

  // Сохранение в БД: username и passwordHash. САМ ПАРОЛЬ НЕ СОХРАНЯЕТСЯ.
  await User.create({ username, password: passwordHash });
});

Куда НЕ должен отправляться пароль и связанные риски

Как QA Engineer, я должен знать типичные уязвимости, которые нужно искать при тестировании:

• В URL как GET-параметр: https://site.com/register?user=login&pass=12345. Пароль останется в логах сервера, истории браузера, referrer headers.
• В открытом виде в теле запроса без HTTPS: Перехватывается любым сниффером в сети (например, Wireshark).
• В веб-сокеты без шифрования: Аналогичная угроза перехвата.
• На сторонние/подозрительные эндпоинты (MитаM-атака): Проверка, что форма отправляет данные именно на ожидаемый домен, а не на hacker.com.
• В localStorage/sessionStorage или куки в открытом виде: Доступны через JavaScript при XSS-атаке.

Что должен проверять QA Engineer

Мои действия при тестировании функции регистрации и логина включали бы:

1. Анализ сетевого трафика (через DevTools -> Network):

    *   Проверка, что запрос использует метод **POST** (а не GET).
    *   Проверка, что используется протокол **HTTPS**.
    *   Изучение **тела запроса (Payload)**. Пароль не должен быть виден в открытом виде. Если виден — это критический баг. Допустимо наличие захешированного значения или просто зашифрованного TLS потока.

1. Проверка наличия и силы шифрования (TLS): Проверка сертификата.
2. Тестирование на уязвимости:

    *   **SQL-инъекция:** Попытка использовать в пароле символы `'` или `;`.
    *   **XSS:** Попытка ввести тег `<script>` в поле пароля (хотя он обычно не отображается, отправка должна быть безопасной).
    *   **Проверка сложности пароля** на стороне клиента и сервера.

1. Валидация ответов сервера: При ошибке сервер не должен возвращать в ответе чувствительные данные (например, "пароль слишком короткий" для существующего пользователя может подтвердить его существование в системе).

Вывод для собеседования: Пароль должен отправляться по защищенному соединению HTTPS на заранее определенный, доверенный эндпоинт API сервера аутентификации (например, POST /api/v1/auth/register), где он будет немедленно преобразован в криптографический хеш с использованием соли. Роль QA — убедиться, что этот процесс соответствует best practices, не содержит утечек в логах, устойчив к основным типам атак, а сами пароли нигде не хранятся и не передаются в читаемом виде. Безопасность — это многоуровневая защита, и тестирование каждого из этих уровней является критически важной задачей инженера по обеспечению качества.