OWASP API Security Top 10: 0xa3 excessive data exposure

# 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, возвращающих подобные данные, чтобы определить, несут ли эти ответы риски безопасности.
* Внедрите механизм валидации, базирующийся на проверке данных по схеме, в качестве дополнительного уровня защиты. В рамках этого механизма определите данные возвращаемые каждой точкой входа (в том числе в ошибках) и обеспечьте, что только эти данные возвращаются пользователю.

## Ссылки

### Внешние

* [CWE-213: Intentional Information Exposure][1]

[1]: https://cwe.mitre.org/data/definitions/213.html