Атаки на API

Самые распространенные проблемы API

👺 Некорректная аутентификация и авторизация: на уровне пользователей, объектов, функций и доступа к базам данных. Часто о ней просто не задумываются, но бывает что просто неправильно настроили

👺 Неограниченное потребление ресурсов

👺 Отсутствие валидации данных: позволяет проводить подделки запросов на стороне сервера (SSRF), когда злоумышленник вместо данных передает url, и сервер делает по нему запрос, а также инъекции кода, SQL и другие атаки

👺 Zombie API. Так называют неактуальный API, которые вследствие отсутствия регулярных обновлений становится легкоуязвимым объектом атаки.

👺 Shadow API. Так называют незадокументированный API, о котором разработчики либо не знают в принципе, либо просто забыли. Встречается в масштабных проектах с множеством приложений/микросервисов и сложной архитектурой.

👺 SMS Leak. Атака на бизнес-логику веб-ресурса, эксплуатирующая функционал автоматизированной отправки SMS с целью исчерпания баланса у SMS-агрегатора

👺 ATO-атаки. Автоматизированный захват аккаунта (Account takeover) с помощью подстановки украденных учётных данных (Credential stuffing) реальных пользователей. Пожалуй, единственная атака, с которой аналитик ничего не может сделать

👺 Неопределенный приоритет повторяющихся ключей. Что будет если просто продублировать JSON ключ? Часто об этом не думают, берется рандомное число, и злоумышленник может, например, продублировать поле цены и получить товары дешевле

👺 Коллизия значений. Например, когда строка парсится сначала из UTF-16, потом опять сериализуется, потом опять десериализуется уже в UTF-8. В процессе конверсии может произойти коллизия

Как защититься:

1. Использование анализатора URL
2. Отключение ненужных HTTP-глаголов
3. Защита от перебора логинов и паролей – блокировка или капча
4. Ограничение типов входящего контента / форматов данных
5. Спецификация запросов (запрет на доступ к ручками API, не указанным в документации)
6. Спецификация ответов API (например, с помощью OpenAPI), ограничение на ссылки и код, проверка дубликации ключей
7. Ограничения на время ожидания выполнения, максимальную выделяемую память, максимальное количество файловых дескрипторов, максимальное количество процессов, максимальный размер загружаемого файла, количество операций, выполняемых в одном запросе клиента API (например,
   в пакете), количество записей на странице, возвращаемых в одном запросе-ответе, лимит расходов сторонних поставщиков услуг на одного пользователя и в общем
8. Блокировка IP-адресов выходных узлов Tor и известных прокси-серверов
9. Запрет на взаимодействие по нешифрованному каналу
10. Проверка и очистка данных, полученных из других API
11. Проверка перенаправлений

1. Распознавание отпечатков пальцев устройств: отказ в обслуживании
   неожиданных клиентских устройств
2. Обнаружение человека: с помощью captcha или более продвинутых биометрических решений (например, шаблонов ввода)
3. Нечеловеческие шаблоны: анализ потока пользователей для выявления нечеловеческих шаблонов (например, пользователь получил доступ к функциям "добавить в корзину" и "завершить покупку" менее чем за одну
   секунду)
4. Проверка ролей на каждую ручку и каждый отдельный id объекта – имеет ли право текущий пользователь просматривать эту информацию или совершать над ней действия?
5. Использовать случайные и непредсказуемые значения в качестве GUID для
   идентификаторов записей
6. Написание тестов для оценки уязвимости механизма авторизации
7. Проверка паролей, запрет на использование слабых паролей, сильное шифрование паролей, запрет на хранение паролей в нешифрованном виде
8. Использование конфиденциальных/авторизационных данных вне URL
9. Запрет пользователям изменять свой адрес электронной почты, текущий пароль или выполнять любые другие конфиденциальные операции без запроса подтверждения пароля
10. Использование токенов: проверка подлинности, неиспользование неподписанных или слабопописанных токенов, проверка даты действия токена
11. Запрет на прописывание в ответе данных, не используемых на клиенте
12. Проверка защищенности технических API (для других машин или разработчиков)
13. Разграничение внутренних и внешних ресурсов для загрузки: хранить файлы,
    доступные всем пользователям, отдельно от корпоративной файловой сети
14. Надлежащая политика совместного использования ресурсов из разных источников (CORS)
15. Сетевое разделение различных стендов
16. Доступ к документации API должен быть доступен ограниченному числу сотрудников
17. Запрет на использование производственных данных на тестовых стендах
18. Использование единой кодировки во всей системе

Для первых 11 пунктов часто используют ПО типа API Gateway, правильно его настроив. Остальные пункты аналитик должен предусмотреть в своем ТЗ, чтобы спроектированное API было не только работающим, но и работало без утечек данных пользователей.