mnemo_cards/mnemo_cards_backend/docs/ADMIN_AUTH_SECURITY.md
Dmitry a92cade04f
Some checks failed
Backend CI / test (push) Waiting to run
Backend CI / build (push) Blocked by required conditions
Deploy Mnemo Cards / Deploy Backend (push) Waiting to run
Deploy Mnemo Cards / Deploy Web App (push) Blocked by required conditions
Deploy Mnemo Cards / Final Verification (push) Blocked by required conditions
Deploy Telegram Bot / Deploy Telegram Bot (push) Has been cancelled
Return debug info in API response for admin auth errors
This will show the exact reason for token verification failure
2025-12-12 01:05:05 +03:00

6.2 KiB
Raw Blame History

Анализ безопасности админских endpoints авторизации

Текущие публичные endpoints

  1. POST /api/v2/admin/auth/request-code - генерация кода
  2. POST /api/v2/admin/auth/verify-code - верификация кода и получение токена
  3. GET /api/v2/admin/auth/code-status/<code> - проверка статуса кода

Анализ безопасности

Существующие защиты

  1. Двухфакторная аутентификация через Telegram

    • Код должен быть заявлен админом в Telegram боте
    • Проверка, что telegramUserId находится в списке админов
    • Без доступа к Telegram аккаунту админа невозможно получить доступ
  2. Ограничения кода

    • Код одноразовый (isUsed)
    • Срок действия 5 минут
    • Код генерируется случайно (100000-999999)
  3. Проверка прав доступа

    • Даже если код заявлен, проверяется, что пользователь имеет admin=true в БД
    • Новые пользователи не получают админские права автоматически

⚠️ Потенциальные уязвимости

  1. Отсутствие rate limiting

    • Можно генерировать неограниченное количество кодов
    • Можно делать множество попыток верификации (брутфорс)
    • Можно часто проверять статус кодов
  2. Брутфорс кода

    • 6-значный код = 900,000 возможных комбинаций
    • Без rate limiting можно перебрать все коды за несколько часов
    • НО: код должен быть заявлен админом, что защищает от брутфорса
  3. Утечка информации через code-status

    • Можно проверять статус любых кодов
    • Раскрывает информацию о существовании кодов
    • Может помочь в брутфорсе (если знать, что код существует)
  4. Отсутствие защиты от перехвата

    • Код передается открыто (но это необходимо для UX)
    • HTTPS должен использоваться обязательно

Рекомендации по улучшению

1. Добавить Rate Limiting (КРИТИЧНО)

Создан файл admin_auth_rate_limiter.dart с реализацией:

  • Генерация кодов: максимум 10 кодов в час с одного IP
  • Верификация: максимум 20 попыток в час с одного IP
  • Проверка статуса: максимум 30 запросов в минуту с одного IP

Как применить:

// В main.dart или где настраивается middleware
final rateLimiter = AdminAuthRateLimiter();
final app = Pipeline()
    .addMiddleware(adminAuthRateLimit(rateLimiter))
    .addMiddleware(/* другие middleware */)
    .addHandler(router);

2. Усилить защиту от брутфорса

  • Добавить задержку после неудачных попыток верификации
  • Логировать все попытки верификации для мониторинга
  • Блокировать IP после N неудачных попыток

3. Ограничить доступ к code-status

  • Требовать минимальную авторизацию (например, по IP whitelist)
  • Или использовать временный токен для проверки статуса
  • Или ограничить проверку только для кодов, созданных с того же IP

4. Мониторинг и алертинг

  • Логировать все попытки генерации кодов
  • Логировать все попытки верификации (успешные и неуспешные)
  • Отправлять алерты при подозрительной активности

5. Дополнительные меры

  • Использовать CAPTCHA для генерации кодов (опционально)
  • Добавить проверку User-Agent и других заголовков
  • Использовать более длинные коды (8-10 цифр) для большей энтропии

Оценка текущего уровня безопасности

Текущий уровень: СРЕДНИЙ

Почему не КРИТИЧНО небезопасно:

  1. Основная защита работает: код должен быть заявлен админом в Telegram
  2. Брутфорс неэффективен: даже если перебрать все коды, они не будут заявлены админом
  3. Одноразовость: использованный код нельзя использовать повторно

Почему нужно улучшить:

  1. DoS атаки: можно перегрузить сервер запросами
  2. Информационная утечка: code-status раскрывает информацию
  3. Лучшие практики: rate limiting - стандартная практика безопасности

Вывод

Текущая реализация достаточно безопасна для production, но настоятельно рекомендуется добавить rate limiting для защиты от DoS атак и улучшения общей безопасности.

Основная защита (требование заявки кода админом) работает корректно и защищает от несанкционированного доступа даже без rate limiting.