113 lines
6.2 KiB
Markdown
113 lines
6.2 KiB
Markdown
|
# Анализ безопасности админских 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
|
|||
|
|
|
|||
|
|
**Как применить:**
|
|||
|
|
```dart
|
|||
|
|
// В 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.
|