Що таке Mass Assignment і як захистити дані
Автор: Редакція Domeny.ForSale Опубліковано
Коротко: Mass Assignment — це автоматичне присвоєння даних із запиту HTTP полям внутрішнього об’єкта або моделі бази даних. Цей механізм стає вразливістю, коли застосунок дозволяє в такий спосіб змінювати й поля, які користувач не повинен контролювати, наприклад роль адміністратора. Основний захист — явно визначати дозволені поля й перевіряти права доступу на сервері.
Як працює автоматичне присвоєння значень полям
Вебзастосунок отримує дані, які надсилає браузер, наприклад під час збереження профілю. Запит HTTP, тобто повідомлення, надіслане серверу, може містити ім’я користувача, адресу електронної пошти та інші значення. Далі сервер має присвоїти їх відповідним полям у своєму коді.
Mass Assignment дозволяє зробити це одразу для всіх полів, без ручного присвоєння кожного значення. Механізм зіставляє назви отриманих полів із властивостями об’єкта. Якщо дані містять поле imia, його значення може потрапити у властивість imia об’єкта користувача.
Таке зіставлення також називають autobinding — автоматичним зв’язуванням. У контексті цієї вразливості трапляється й термін object injection — ін’єкція об’єктів, хоча в інших контекстах безпеки він може означати інші механізми. Саме по собі автоматичне зіставлення не є помилкою: проблема починається, коли сервер приймає більше полів, ніж повинен.
Простий приклад: редагування профілю та зміна ролі
Припустімо, форма редагування профілю дозволяє змінити лише відображуване ім’я та адресу електронної пошти. Коректні дані, які надсилаються серверу, мають такий вигляд:
{
"imia": "Олена",
"email": "olena (at) example.com"
}
Однак у базі даних обліковий запис має більше властивостей. Окрім імені й адреси, він містить поле rol, яке визначає права користувача. Форма не показує його, оскільки звичайний користувач не повинен мати змоги його змінювати.
Проте зловмиснику не обов’язково користуватися формою. Він може змінити запит, який надсилає, і додати ще одне поле:
{
"imia": "Олена",
"email": "olena (at) example.com",
"rol": "адміністратор"
}
Якщо сервер без обмежень скопіює всі отримані властивості в обліковий запис, він може зберегти й нову роль. Якщо система керування доступом використовує це поле, наслідком може стати отримання адміністративного доступу.
Відсутність поля у формі не є захистом. Визначати, що можна змінювати, має сервер, а не вигляд сторінки чи код JavaScript, який виконується в браузері.
Які дані особливо вразливі
Mass Assignment стосується не лише облікових записів користувачів. Ризик виникає скрізь, де зовнішні дані автоматично потрапляють до об’єктів, які містять також внутрішні властивості.
Приклади полів, які потребують особливого контролю:
vlasnyk_id— може визначати, кому належить документ або замовлення;tsina— може впливати на суму, нараховану за покупку;status_oplaty— може вказувати, чи оплачено замовлення;email_pidtverdzheno— може визначати, чи буде пропущено підтвердження адреси.
Наприклад, покупець інтернет-магазину має надсилати ідентифікатор товару та вибрану кількість одиниць. Ціну сервер повинен визначати за власними даними про пропозицію, а не безумовно приймати значення із запиту.
Не кожне додаткове поле призведе до успішної атаки. Для цього сервер має прийняти його, присвоїти його значення відповідній властивості й використати це значення так, щоб воно вплинуло на роботу застосунку. Тому під час аналізу потрібно перевіряти весь шлях даних, а не лише вміст форми.
Як ефективно обмежити Mass Assignment
Основний захист — список дозволених полів: для певної операції сервер приймає лише властивості, які вказав розробник. Для звичайного редагування профілю це можуть бути imia та email, але не rol.
Послідовність дій може бути такою:
dozvoleni_polia = ["imia", "email"]
dani_profiliu = vybraty_polia(dani_zapytu, dozvoleni_polia)
onovyty_profil(avtoryzovanyi_korystuvach, dani_profiliu)
Це псевдокод, який ілюструє принцип, а не готова реалізація. Залежно від фреймворку обмеження можна налаштувати в механізмі зіставлення, валідаторі або окремому об’єкті вхідних даних, який часто називають DTO. Такий об’єкт описує дані, дозволені для конкретної операції, замість того щоб відтворювати весь запис із бази.
Самої перевірки формату недостатньо. Значення адміністратор може бути коректною назвою ролі, але звичайний користувач усе одно не має права її встановлювати. Отже, потрібна також авторизація — перевірка того, чи має конкретна особа право вносити певну зміну.
У списку заборонених полів легше щось пропустити: після додавання нової властивості моделі потрібно не забути заблокувати її. Список дозволених полів не відкриває доступу до нових властивостей автоматично. Точну поведінку фреймворку, який ви використовуєте, та його стандартні механізми захисту слід перевірити в офіційній документації.
Як перевірити власний застосунок
Тестуйте лише власну систему або середовище, на тестування якого маєте дозвіл. Для операції редагування профілю підготуйте запит із коректними даними, а потім додайте поле, яке користувач не повинен змінювати.
Перевірте не лише відповідь сервера, а й збережені дані та фактичні права облікового запису. Безпечна реалізація має відхилити недозволену зміну або проігнорувати додаткове поле, не змінюючи захищеного значення.
Для початку перегляньте місця, де всі дані запиту безпосередньо передаються методам створення або оновлення записів. Для кожного такого місця визначте дозволені поля й додайте тест, який підтверджує, що решту змінити неможливо.
Дивіться також: Що таке Path Traversal
Читайте також
