Какие виды токенов вы знаете в контексте тестирования безопасности и API?

«Какие виды токенов вы знаете в контексте тестирования безопасности и API?» — вопрос из категории Тестирование безопасности, который задают на 24% собеседований AQA / Automation. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

При тестировании безопасности и API я работаю с различными токенами, проверяя их генерацию, хранение, передачу и валидацию.

Основные виды токенов и что я проверяю:

  1. Access Token (JWT — JSON Web Token)

    • Назначение: Короткоживущий ключ для доступа к защищенным ресурсам API.
    • Тестирование:
      • Структура: Проверяю, что токен состоит из трех частей (Header.Payload.Signature), декодирую через jwt.io.
      • Алгоритм подписи: Убеждаюсь, что используется надежный алгоритм (HS256, RS256), а не none.
      • Payload: Проверяю наличие и корректность claims (exp, iat, sub, scope).
      • Пример проверки в автотесте (Python, requests + pyjwt):
        import jwt
        # ... получение токена из ответа API ...
        decoded = jwt.decode(access_token, options={"verify_signature": False})
        assert "exp" in decoded, "Токен должен содержать срок действия (exp)"
        assert decoded["scope"] == "read:data", "Неверный scope токена"
  2. Refresh Token

    • Назначение: Долгоживущий токен для получения нового Access Token без повторного ввода логина/пароля.
    • Тестирование:
      • Проверяю, что Refresh Token хранится безопасно (httpOnly, Secure флаги в куках).
      • Тестирую сценарий: Access Token истек -> использую Refresh Token для получения новой пары.
      • Проверяю инвалидацию Refresh Token после одноразового использования или при logout.
  3. Bearer Token

    • Назначение: Способ передачи Access Token в заголовке HTTP-запроса.
    • Тестирование: Убеждаюсь, что токен передается в заголовке Authorization: Bearer <token>, а не в URL (чтобы не попадал в логи).
  4. API Key

    • Назначение: Статичный идентификатор для аутентификации вызова API (часто для сервис-сервисного взаимодействия).
    • Тестирование: Проверяю, что ключ передается безопасно (не в URL), есть возможность его отозвать и перевыпустить. Тестирую лимиты запросов (rate limiting), привязанные к ключу.
  5. CSRF Token

    • Назначение: Защита от межсайтовой подделки запроса в веб-формах.
    • Тестирование:
      • Проверяю, что токен уникален для сессии и привязан к пользователю.
      • Проверяю, что POST/PUT/DELETE запросы без валидного CSRF-токена отклоняются.
      • Использую инструменты вроде OWASP ZAP для автоматического сканирования уязвимостей CSRF.

Общие проверки безопасности: Для всех типов токенов я проверяю отсутствие их в логах приложения, корректную обработку истечения срока действия и отказ в доступе при передаче некорректного/поддельного токена.