API6:2019 - Массовое Переназначение Параметров (Mass assignment)
| Источники угроз/Векторы атак | Недостатки безопасности | Последствия |
|---|---|---|
| Зависит от API : Сложность эксплуатации 2 | Распространенность 2 : Сложность обнаружения 2 | Технические последствия 2 : Зависит от бизнеса |
| Для эксплуатации зачастую требуется понимание бизнес логики, связей между объектами и структуры API. Эксплуатация массового переназначения параметров проще реализуема в API, поскольку они изначально предусматривают общедоступность внутренней реализации API и названий свойств объектов. | Современные фреймворки предлагают разработчикам функции, которые автоматически присваивают переменным и внутренним объектам значения соответствующих параметров из пользовательского ввода. Злоумышленник может использовать эту методологию, чтобы обновить или переназначить критичные свойства объектов, которые разработчик не намеревался делать доступными для пользователя. | Эксплуатация уязвимости может привести к повышению привилегий, злонамеренному изменению данных, обходу механизмов защиты и так далее. |
Как определить, является ли API уязвимым?
Объекты в современных приложениях могут иметь большое количество свойств. Некоторые из них могут быть изменены напрямую клиентом (например, user.first_name или user.address), в то время как изменение других не должно быть доступно (например, флаг user.is_vip).
Конечная точка API уязвима, если она автоматически присваивает предоставленные клиентом параметры свойствам внутренних объектов, не учитывая критичность и уровень доступности этих свойств. Это может позволить злоумышленнику изменить свойства объектов, к которым у него не должно быть доступа.
Примеры критичных свойств:
- Свойства, относящиеся к привилегиям:
user.is_admin,user.is_vipдолжны устанавливаться только администраторами. - Свойства, зависящие от процесса:
user.cashдолжны устанавливаться только внутри кода после проверки платежа. - Внутренние свойства:
article.created_timeдолжны устанавливаться только внутри кода самим приложением.
Примеры сценариев атаки
Сценарий #1
Приложение для совместных поездок позволяет пользователю редактировать базовую информацию своего профиля. В ходе редактирования отправляется следующий запрос PUT /api/v1/users/me с корректным JSON объектом в теле запроса:
{"user_name":"inons","age":24}
Запрос к GET /api/v1/users/me включает в себя дополнительное свойство credit_balance:
{"user_name":"inons","age":24,"credit_balance":10}
Злоумышленник дублирует первый запрос со следующим телом запроса:
{"user_name":"attacker","age":60,"credit_balance":99999}
Поскольку точка входа уязвима к массовому переназначению параметров, злоумышленник зачисляет деньги на свой баланс, не совершив платежа.
Сценарий #2
Портал для обмена видео позволяет пользователям загружать и скачивать материалы в разных форматах. Злоумышленник исследует API и обнаруживает, что точка входа GET /api/v1/videos/{video_id}/meta_data возвращает JSON объект с параметрами видео. Один из параметров "mp4_conversion_params":"-v codec h264" дает понять, что приложение использует консольную команду для конвертации видео.
Злоумышленник также обнаружил, что точка входа POST /api/v1/videos/new уязвима к массовому переназначению параметров и позволяет клиенту установить значение любого свойства объекта видео.
Злоумышленник устанавливает следующее значение параметра: "mp4_conversion_params":"-v codec h264 && format C:/". Это значение приведет к инъекции команды операционной системы, как только злоумышленник скачает видео в формате MP4.
Как предотвратить
- Если возможно, избегайте использования функций, которые автоматически присваивают переменным и внутренним объектам соответствующие значения из пользовательского ввода.
- Добавляйте в белые списки только те свойства, которые могут быть изменены клиентом.
- Используйте встроенный функционал по добавлению в черный список свойств, к которым клиенты не могут иметь доступ.
- Если это возможно, явно определите схемы входящих данных и проверяйте входящие данные по ним.