Помилки конфігурації можуть призводити до витоку чутливих даних на платформах Microsoft Power Pages

Компанії, які розробляють вебсайти за допомогою Microsoft Power Pages, можуть випадково надавати надмірні привілеї доступу до баз даних автентифікованим або анонімним користувачам, що призводить до витоку чутливих даних, зазначають дослідники.

Як повідомляє CSO, згідно з дослідженням компанії AppOmni, яка спеціалізується на безпеці SaaS, багато сайтів, створених за допомогою Power Pages, піддаються ризику через неправильну конфігурацію доступу до даних і використання налаштувань за замовчуванням.

Автори дослідження вказують, що причиною проблеми є ненадійна реалізація власного коду та надання надмірного доступу до баз даних.

Ризики витоку даних

Ці помилки в налаштуваннях зазвичай призводять до витоку персональних даних (PII) клієнтів або внутрішніх документів компаній, які зберігаються на бізнес-сайтах. Про це повідомив Аарон Костелло, керівник досліджень безпеки SaaS в AppOmni.

Під час авторизованого тестування сайтів Костелло виявив кілька мільйонів записів із чутливими даними. За його оцінкою, загальний обсяг витоку для всіх сайтів на базі Power Pages може бути значно більшим.

«В одному випадку великий провайдер бізнес-послуг для NHS відкрито демонстрував дані понад 1,1 мільйона співробітників NHS. Зокрема їхні електронні адреси, номери телефонів і навіть домашні адреси», — зазначив Костелло у своєму звіті.

Неправильне розуміння механізмів контролю доступу Power Pages

Microsoft Power Pages — це платформа з низьким кодом (low-code), яка дає змогу організаціям створювати бізнес-сайти. Вона забезпечує:

• контроль доступу на основі ролей (RBAC);
• роботу вбудованої бази даних (Microsoft Dataverse);
• інтерфейси перетягування компонентів (drag-and-drop).

Для зв’язку з базою даних використовуються такі API:

• Web API — сучасний API з повним спектром прав доступу до записів;
• OData Feed та Embedded List API — старі API, які забезпечують лише можливість читання.

Power Pages пропонує кілька ролей із різними дозволами, які можна призначати на рівні сайту, таблиць, стовпців і записів. Основними з них є:

• автентифікована (для всіх зареєстрованих користувачів);
• анонімна (для незареєстрованих користувачів).

Однак якщо сайт дозволяє зовнішнім користувачам створювати облікові записи, то автентифіковану роль потрібно розглядати як зовнішню для організації.

Типові помилки конфігурації

У багатьох випадках, з якими стикався Костелло, адміністратори надавали глобальний доступ до таблиць для анонімних або автентифікованих користувачів. Це давало змогу зовнішнім користувачам отримувати доступ до всіх записів у таблиці.

Адміністратори могли припускати, що на рівні стовпців встановлено додаткові обмеження, але ці функції рідко використовуються через складність налаштування, яке включає:

1. Створення регулярного виразу у Power Apps для маскування вмісту стовпця.
2. Увімкнення безпеки стовпців у Power Pages.
3. Створення профілю безпеки стовпця у PowerApps Management.
4. Призначення ролей користувачів до профілю безпеки.
5. Налаштування дозволів на читання для стовпця.

Фактори, які призводять до витоку даних

1. Доступ через Web API. Надмірний доступ до стовпців бази даних через Web API. Наприклад, використання Webapi/<object>/fields зі значенням *, що дозволяє отримувати всі стовпці таблиці.
2. Відкрита реєстрація та зовнішня автентифікація. Ці опції увімкнені за замовчуванням, що дає змогу користувачам реєструватися й отримувати доступ через API, навіть якщо відповідні сторінки не відображаються на сайті.
3. Глобальний доступ до таблиць. Зовнішні користувачі отримують доступ до всіх записів у таблиці, навіть якщо вони належать іншим ролям.
4. Ігнорування безпеки стовпців. Відсутність маскування чи обфускації чутливих стовпців.

Як зменшити ризики

Power Pages відображає попередження щодо небезпечних конфігурацій, наприклад:

• ризик використання анонімної ролі в дозволах таблиці;
• попередження для дозволів із глобальним доступом для анонімної ролі.

Однак такі попередження не застосовуються до автентифікованої ролі, яка також може бути зовнішньою.

Аарон Костелло рекомендує:

1. Проводити аудит доступу, починаючи з налаштувань сайту, таблиць і записів, а також стовпців.
2. Здійснювати перегляд таких налаштувань:

• Налаштування сайту:
• Webapi/<object>/enabled.
• Webapi/<object>/fields.
• Authentication/Registration/Enabled.
• Authentication/Registration/OpenRegistrationEnabled.
• Authentication/Registration/ExternalLoginEnabled.
• Authentication/Registration/LocalLoginEnabled.
• Authentication/Registration/LocalLoginDeprecated.
• Дозволи таблиць/записів:
• Будь-яка таблиця з типом доступу «Глобальний» і зовнішніми ролями.
• Дозволи стовпців:
• Будь-які стовпці, доступні зовнішнім користувачам, без увімкненої безпеки стовпців.

«Замість надання надмірних прав на рівні записів і стовпців організаціям варто використовувати індивідуальні API для перевірки введених даних», — радить Костелло.

Дотримання цих рекомендацій допоможе уникнути витоку чутливих даних і забезпечити захист бізнес-сайтів.

Читайте також на ProIT, скільки ІТ-організацій стикалися з витоками секретного коду.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!