Supabase RLS: ручний аудит чи сканування?

Безпека на рівні рядків - це межа між проектом Supabase, який захищає свої дані, і проектом, який тихо розкриває їх. Якщо RLS налаштовано належним чином, у вашій базі даних застосовуються правила доступу на рівні рядка для ролей, які підпадають під RLS. Привілейовані ролі, включаючи роль обслуговування, можуть обійти ці правила. Якщо його налаштовано погано, таблиці виглядають захищеними, а політики пропускають більше, ніж ви планували.

У цій статті порівнюються два способи запуску перевірки безпеки Supabase RLS: перевірка політик вручну та запуск автоматизованого аудиту RLS. Обидва мають місце. Знаючи, де кожна з них ламається, ви перевіряєте, чи ваші політики доступу до бази даних працюють належним чином.

RLS - це функція Postgres, яку Supabase надає для кожної таблиці. Після ввімкнення таблиця забороняє доступ до рядків для ролей, що підпадають під RLS, якщо це не дозволено політикою; власники таблиць і ролі з привілеями обходу є винятком. Політики оцінюються щодо поточного користувача, його заяв і запиту, який виконується. The auth.uid() функція зазвичай є якорем: політика, як using (auth.uid() = user_id) обмежує доступ до власних рядків бази даних користувача.

Модель чиста. Невдачі - ні, тому що вони рідко виглядають як невдачі.

Кілька шаблонів пояснюють більшість проблем RLS:

• RLS увімкнено на деяких столах, але не на всіх. Нова таблиця, додана після запуску або створена під час міграції, може постачатися з вимкненим RLS. Тоді кожен рядок доступний для читання будь-якою роллю з доступом до таблиці.

• Політика ширша, ніж вона читається. using (true) у вибраній політиці означає, що кожен рядок видимий. Його легко додати під час розробки для налагодження та забути видалити.

• Скрізь береться на себе службова роль. Код на стороні сервера, який використовує ключ ролі служби, повністю обходить RLS. Якщо запити користувача проходять через цей ключ, політики ніколи не застосовуються.

• Політики, які перевіряють неправильний стовпець. auth.uid() = id на столі де id є первинним ключем рядка, а не власником, ніколи не відповідатиме наміру. Політика існує, вона повертає помилку або порожній набір, а поверхня все ще поводиться.

• Оновлення та видалення бази даних без належного контролю доступу. Розробники часто ретельно захищають вибір і залишають політику запису вільною. Проходження перевірки читання нічого не говорить про те, хто може змінювати рядок наступним.

Жоден із них не оголошує себе. Кожна з них підтримує роботу програми, саме тому вони виживають до робочої версії.

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

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

Далі перевірте шлях коду. Визначте, який ключ ваша програма фактично використовує для запитів користувача та чи виконується якийсь із них через роль служби. Потім напишіть тестові запити від імені різних користувачів і переконайтеся, що результати відповідають очікуванням: користувач повинен читати свої власні рядки, а не чужі, і не повинен мати можливість оновлювати рядок, який йому не належить.

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

• Він перевіряє те, що ви пам’ятаєте перевірити. Якщо ви не думаєте спробувати видалити як другий користувач, ви можете пропустити занадто широку політику видалення. Якщо RLS увімкнено, відсутність відповідної політики видалення означає, що видалення заборонено.

• Це старіє. Політики змінюються в міру додавання функцій. Ретельний огляд, проведений минулого кварталу, нічого не говорить про таблицю, яку ви додали минулого тижня.

• Це залежить від тієї самої особи, яка налаштувала політики. Найменш імовірно, що будівельник, який написав політику, помітить власне припущення.

• Для цього потрібні записані докази. «Я переглянув це, і все виглядало правильно» не залишає нічого позаду: ні доказів, ні обсягу, ні артефакту, який можна було б сканувати пізніше.

Ручний аудит відповідає на питання "чи відповідає це моїй розумовій моделі системи?" Сам по собі він не доводить, що насправді поверне база даних.

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

Ця зміна важлива з трьох причин. По-перше, він масштабує минулу пам’ять: сканування повторює перевірки таблиць і кінцевих точок, доступних у його налаштованому діапазоні. Зовнішнє сканування не може перевірити кожну політику без відповідного доступу. По-друге, він створює докази, на основі яких ви можете діяти: знахідка називає таблицю, стан політики та умову, яка робить її доступною, щоб ви знали, що змінити і чому. По-третє, це повторюваність. Повторна перевірка перетворює одноразову перевірку на постійну перевірку.

VICE сканує веб-додатки та конфігурації Supabase/RLS, а потім звітує про результати з доказами, що стоять за ними, і вказівками щодо виправлення. Ви можете позначити виправлення та надіслати запит на повторну перевірку, але лише порівняне повторне сканування підтверджує, що проблему вирішено: виправлення перевіряється в тому самому масштабі, а не на основі редагування. Сканування за розкладом і сповіщення підтримують постійний моніторинг, тому таблиця, додана наступного місяця, не відновить прогалину.

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

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

Якщо ви розгортаєте продукт, створений на основі Supabase, і ніколи не перевіряли свою політику, чесною відповіддю буде те й інше. Почніть з автоматизованої перевірки RLS, щоб мати актуальне, підтверджене зображення того, що дозволяють ваші таблиці. Потім перевірте висновки вручну, підтвердьте призначення кожної політики та виправте ті, які відхилилися. Заплануйте автоматичну перевірку, щоб нові таблиці та нові політики перевірялися так само, як і вихідні.

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

Почніть безкоштовне сканування на vice-platform.com, щоб перевірити свій загальнодоступний веб-сайт перед реєстрацією. Для спеціалізованого сканування Supabase потрібен підтверджений домен і платна підписка або придбаний кредит; його покриття залежить від налаштованого доступу.