В ходе тестирования “черного ящика” обнаружено 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 из токена.
Рекомендации по устранению
- Anti‑cheat для V01: сделать маршрут обязательным, вычислять среднюю скорость на сервере, вводить физические лимиты (например, скорость > 20 км/ч → отклонять), логировать подозрительные попытки.
- Field filtering для V02: разрешить в PATCH только безопасные настройки UI; жизни/очки/статусы должны меняться только серверными триггерами после валидации.
- Приватность для V03: отдавать агрегаты вместо “сырых” треков; маскировать точки старта/финиша; включать доступ к координатам только по процессу и необходимости.
- JWT для V04: переход на RS256/асимметрию + механизм отзыва (revocation) или server-side session reference, в зависимости от архитектуры.
- /docs для V05: Basic Auth/IP allowlist/закрытие в non‑prod, чтобы снизить поверхность атаки.
Напиши в Telegram — уточню контекст и подскажу, как быстро найти “дорогие” уязвимости в бизнес‑логике и доступах.
Написать в Telegram