API3:2019 Предоставление Излишних Данных
| Источники угроз/Векторы атак | Недостатки безопасности | Последствия |
|---|---|---|
| Зависит от API : Сложность эксплуатации 3 | Распространенность 2 : Сложность обнаружения 2 | Технические последствия 2 : Зависит от бизнеса |
| Предоставление излишних данных легко эксплуатировать. Для этого нужно перехватить трафик и проанализировать ответы API на предмет критичных данных, которые API не должно возвращать пользователю. | API рассчитывают, что клиентское приложение отфильтрует отображаемые пользователю данные. Поскольку API используются в качестве источника данных, иногда разработчики пытаются сделать его универсальным для всех клиентов, не думая о критичности возвращаемых пользователю данных. Автоматизированные инструменты зачастую не обнаруживают эту уязвимость, поскольку без детального понимания логики приложения очень трудно определить, должно ли API возвращать те или иные данные. | Предоставление излишних данных обычно приводит к разглашению конфиденциальных данных. |
Как определить, является ли API уязвимым?
API уязвим, если он спроектирован так, что возвращает критичные данные клиентскому приложению, которое в свою очередь фильтрует их перед отображением пользователю, то злоумышленник с легкостью может перехватить трафик и увидеть критичные данные.
Примеры сценариев атаки
Сценарий #1
Команда мобильного приложения использует точку входа /api/articles/{articleId}/comments/{commentId} для отображения метаданных комментариев в представлении статей. Злоумышленник перехватывает трафик от мобильного приложения и находит в ответе дополнительные критичные данные об авторе комментария. Точка входа реализована так, что использует стандартный метод toJSON() на объекте модели User, содержащем персональные данные, для сериализации этого объекта.
Сценарий #2
Система видеонаблюдения, базирующаяся на IOT, позволяет администраторам создавать пользователей с различными привилегиями. Администратор создал учетную запись для нового охранника, которая должна иметь доступ только к определенным зданиям на объекте. Когда охранник использует мобильное приложение, оно отправляет запрос в точку входа /api/sites/111/cameras, чтобы получить данные о доступных камерах и отобразить их на панели управления. Ответ API содержит список данных о камерах в следующем формате: {"id":"xxx","live_access_token":"xxxx-bbbbb","building_id":"yyy"}. Клиентское приложение показывает только те камеры, к которым охранник имеет доступ, однако ответ API содержит полный список камер на объекте.
Как предотвратить
- Не рассчитывайте, что клиентская часть приложения отфильтрует критичные данные.
- Проверьте, что ответы API содержат только те данные, которые отображаются клиентским приложением.
- Разработчики серверной части должны всегда задаваться вопросом "Кто получит данные?" перед публикацией новых точек входа API.
- Избегайте использования стандартных методов, например,
to_json()илиto_string(). Вместо этого вручную выбирайте свойства объектов, которые вы возвращаете в ответе. - Классифицируйте критичную информацию и персональные данные, с которыми работает приложение, путем анализа всех вызовов API, возвращающих подобные данные, чтобы определить, несут ли эти ответы риски безопасности.
- Внедрите механизм валидации, базирующийся на проверке данных по схеме, в качестве дополнительного уровня защиты. В рамках этого механизма определите данные возвращаемые каждой точкой входа (в том числе в ошибках) и обеспечьте, что только эти данные возвращаются пользователю.