← Все кейсы

10 000 очков за 1 секунду: как API позволил взломать экономику

Game API & Admin API • Black‑box Статус: CRITICAL RISK Дата аудита: 7 апреля 2026

Executive Summary

В ходе тестирования “черного ящика” обнаружено 5 уязвимостей, из них 2 — критические. Ключевая проблема: сервер чрезмерно доверяет данным с клиентской стороны и позволяет манипулировать игровой логикой.

  • Накрутка очков и захват лидерборда (взлом игровой экономики).
  • Обход платных механик (жизни/состояние игры).
  • Риск утечки GPS‑треков и PII через Admin API при компрометации админ‑доступа.

Контекст

  • Объект: Game API и Admin API.
  • Метод: black‑box (без исходников), проверка бизнес‑логики, состояний пользователя и приватности данных.
  • Вердикт: запуск в production не рекомендуется до устранения критических V01/V02.

Уязвимости (кратко)

V01 — обход бизнес‑логики начисления очков (CRITICAL)

Эндпоинт POST /v1/scores рассчитывал баллы на основе area и timeTaken, но не проверял физическую достоверность маршрута. При пустом pathPoints проверка реальности маршрута фактически отключалась.

Эффект

Любой пользователь мог вручную отправить запрос с аномальными значениями и получить начисление очков с сохранением на сервере (201 Created). Это означает накрутку лидерборда и прямой ущерб экономике/призам.

PoC (обезличенно)

Пример аномального запроса (упрощено):

{
  "area": 1000000,
  "timeTaken": 600,
  "timestamp": "2026-04-07T19:00:00Z",
  "pathPoints": []
}

Сервер отвечал 201 Created и возвращал начисленные очки, сохраняя результат.

V02 — mass assignment / манипуляция состоянием игрока (HIGH)

Эндпоинт PATCH /v1/me/game-state позволял напрямую перезаписывать внутренние свойства игрока. Например, установка lives увеличивала число жизней без серверной валидации триггеров, что убивает монетизацию.

V03 — риск утечки GPS‑треков и PII через Admin API (MEDIUM/HIGH)

В ответах Admin API присутствовали “сырые” координаты маршрутов и персональные данные. RBAC работал корректно для обычного пользователя, но при утечке админ‑доступа риск деанонимизации и слежки становится существенным.

V04 — JWT security: HS256 + отсутствие мгновенного отзыва (MEDIUM)

Токены подписывались HS256 (симметричный ключ), а логаут не делал токен недействительным мгновенно: повторный запрос с тем же токеном мог проходить. Окно снижалось TTL 15 минут, но риск при компрометации секрета сохраняется.

V05 — публичный Swagger UI (/docs) (LOW)

Документация облегчает разведку и ускоряет поиск векторов атак. Это не “дыра” сама по себе, но повышает атакуемость.

Что было сделано правильно

  • Строгая валидация схем (например, блокировка недокументированных полей).
  • Устойчивость к части инъекций/аномалий (отрицательные/нулевые значения отклонялись).
  • Базовая защита от BOLA в ключевых запросах, завязанная на ID из токена.

Рекомендации по устранению

  1. Anti‑cheat для V01: сделать маршрут обязательным, вычислять среднюю скорость на сервере, вводить физические лимиты (например, скорость > 20 км/ч → отклонять), логировать подозрительные попытки.
  2. Field filtering для V02: разрешить в PATCH только безопасные настройки UI; жизни/очки/статусы должны меняться только серверными триггерами после валидации.
  3. Приватность для V03: отдавать агрегаты вместо “сырых” треков; маскировать точки старта/финиша; включать доступ к координатам только по процессу и необходимости.
  4. JWT для V04: переход на RS256/асимметрию + механизм отзыва (revocation) или server-side session reference, в зависимости от архитектуры.
  5. /docs для V05: Basic Auth/IP allowlist/закрытие в non‑prod, чтобы снизить поверхность атаки.
Нужен аудит или разбор API?

Напиши в Telegram — уточню контекст и подскажу, как быстро найти “дорогие” уязвимости в бизнес‑логике и доступах.

Написать в Telegram