Хабрахабр

Как технологии быстрой разработки могут стать источником неприятных уязвимостей

Безопасность на реальных примерах всегда более интересна.

Как тестировщик на проникновение, люблю, когда приходят проекты, построенные на фреймворках быстрой разработки (Rapid development), подобно Ruby-on-Rails, Django, AdonisJs, Express и так далее. Они позволяют очень быстро строить систему за счет того, что бизнес модели прокидываются сразу на все уровни, включая клиентский браузер. Model (модели бизнес объектов в базе) и ViewModel (контракт взаимодействия с клиентами) такие фреймворки часто объединяют вместе, чтобы избежать лишнего перекладывания из Model во ViewModel и обратно, REST сервисы автоматом генерируются. C точки зрения разработки можно просто разработать бизнес модель на сервере, и потом использовать ее сразу на клиенте, что несомненно увеличивает скорость разработки.

Такое встречал и на одном ASP. Еще раз, я не утверждаю, что вышеупомянутые фреймворки плохие, или с ними что-то не то, у них есть средства и инструменты правильной защиты, просто с ними разработчики делают больше всего ошибок. Например, есть метод, который позволяет менять только имя пользователя, а возвращает объект профиля пользователя. NET MVC проекте, в котором разработчики наделали те же уязвимости, выставляя Models вместо ViewModels…
Уязвимость: из-за слабой валидации полей входящих моделей от клиента, можно инжектить поля, которые не предусмотрены функциональностью, но есть в бизнес-модели. Возможно получиться, что можно менять любое свойство объекта (пароль, роль), обходя стандартные workflow. Что если скопировать возвращаемый объект, поменять в нем все свойства и послать заново на вход?

Все эти проблемные места были устранены, а любая лишняя информация на скриншотах скрыта. Из разных проектов, которые мы тестировали на безопасность, приведу реальные примеры.

Система 1

Но подставив ещё Email, удалось поменять и логин пользователя. В этой системе в профиле можно было поменять только имя пользователя. Более того, с этого мыла теперь уходили инвайты другим пользователям.

image

Система 2

В этот примере простому пользователю удалось поменять роль на админа, добавив поле roles, и по урлу /admin просто открыть админку системы со всеми транзакциями, пользователями, отчетами и так далее.

image

Система 3

Понятно, что стандартный подход требовал, чтобы была оплата. В этой системе удалось продлить себе бесплатную подписку на неопределенный срок.

image

Удалось вставить не просто поле, а громадный подобъект StripeCustomer, и в итоге один раз заплатив, или у другого пользователя захватить этот объект, и продублировать его на все свои воркспейсы. Метод на вход принимал, казалось бы, только выбранный цвет по брендингу воркспейса, а возвращал объект всего воркспейса, включая полный дамп StripeCustomer объекта, который отражал оплату.

image

Система 4

В этой системе была та же проблема: можно было поменять пароль и ключ доступа в обход придуманному воркфлоу. Ну и напоследок. Злонамеренный пользователь мог бы разместить на популярном ресурсе скрипт с запросом на изменение пароля текущего пользователя данной системы, и все пользователи, которые открыли бы этот ресурс, лишились бы доступа в систему. Отсутствие защиты против CSRF и запоминание аутентификационных куков на долгий период, поднимало риск данной уязвимости до небес.

image

В серверном коде в метаданных для этого поля стояло hide, это позволило не возвращать это поле клиенту в ответе, но во входных данных это поле обрабатывалось без проблем.

image

Посыл:

  1. Никогда не доверяйте входящим данным от пользователей, они могут делать с ними все, что угодно
  2. Осторожнее с системами, в которых нет отдельного слоя ViewModel-s, а работа идет непосредственно с моделями базы
  3. Исследуйте более детально средства защиты, которые предлагает вам ваш фреймворк

Вышеизложенная информация предоставляется только для учебных и просветительских целей, как делать свои системы не надо.

Денис Колошко, Penetration Tester, CISSP

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть