Проектирование API с защитой от повторной отправки и накрутки запросов
При проектировании API необходимо учитывать множество аспектов безопасности, чтобы сервис мог противостоять атакам злоумышленников. Некоторые угрозы легко минимизировать на этапах проектирования и написания кода. Например, защититься от атак на аутентификацию и авторизацию помогают проверенные реализации современных стандартов, таких как OAuth 2.0 и OpenID Connect.
Чтобы не допустить различных инъекций (sqli, code injection, …) нужно осуществлять валидацию ввода. Шифрование обеспечивает безопасность данных при передаче и хранении. Однако есть угроза, связанная с атаками на бизнес-логику (API6:2023 — Unrestricted Access to Sensitive Business Flows), для которой защитные меры не всегда очевидны, особенно на начальных этапах. Примером реализации такой угрозы является атака повторного воспроизведения (Replay attack). Разберем подробнее, что это такое.
Атака повторного воспроизведения (Replay attack) – это атака, при которой злоумышленник повторно отправляет запрос к приложению (в нашем случае к API-эндпойнту) с модификацией или без неё, чтобы совершить нужное ему действие. Чаще всего это делается, чтобы обойти необходимость авторизовать данное действие. Одним из вариантов replay-атаки является накрутка запросов, которую регулярно используют для игры не по правилам. Примеры:
- искусственно набрать голоса и победить в онлайн-голосовании
- повысить приоритет ресурса в выдаче поисковых систем
- создать большое количество подписчиков и отзывов для продвижения в соц. сетях и на маркетплейсах
- набрать игровые очки или валюту в различных онлайн-играх
- вызвать проблемы в работе сервисов вплоть до полного отказа
Основной причиной возникновения атак повторного воспроизведения и накруток является отсутствие строгих проверок на стороне API. Недостаточная аутентификация или ее отсутствие позволяет отправлять сообщения от имени других пользователей. Отсутствие подписи в сообщении дает возможность его модифицировать. В некоторых операциях (напр. голосование) требуется только один запрос от пользователя, а повторные необходимо отклонять. Также почти во всех операциях требуется следить за количеством запросов в единицу времени, чтобы осложнить возможность делать накрутки.
Реализовать строгие проверки на стороне API помогают различные технологии защиты:
1. Одноразовый токен (nonce)
API генерирует и запрашивает у клиента уникальный одноразовый токен, который предотвращает повторное выполнение запроса. Таким образом каждое выполнение запроса будет требовать нового токена.
2. Использование одноразовых кодов подтверждения (OTP)
Похожая технология, только генерация кодов осуществляется независимо на стороне клиента и на стороне API. Наиболее популярные реализации – TOTP (код на основе временной метки) и HOTP (код на основе счетчика).
3. Подпись сообщения (HMAC)
Клиент подписывает каждый запрос, включая в него временную метку. API проверяет подпись и время, если что-то не совпадает, то отклоняет запрос.
4. Лимиты на количество запросов в единицу времени (rate limits)
Такие ограничения должны иметь несколько вариантов настройки: лимиты по обращениям к конкретным API-эндпойнтам, лимиты по пользователям или сессиям. Обычно запросы свыше лимита отклоняются или вызывают включение механизмов дополнительных проверок, таких как CAPTCHA.
Таким образом, если вы хотите обезопасить свое API от атак повторного воспроизведения и накруток, предусмотрите ряд проверок на стороне сервиса, которые можно реализовать с помощью различных технологий.
