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

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

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

RLS - это функция Postgres, которую Supabase предоставляет для каждой таблицы. После включения таблица запрещает доступ к строкам для ролей, подчиняющихся RLS, если это не разрешено политикой; Владельцы таблиц и роли с привилегиями обхода являются исключениями. Политики оцениваются по текущему пользователю, его утверждениям и выполняемому запросу. 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 требуется подтвержденный домен и платная подписка или приобретенный кредит; его покрытие зависит от настроенного доступа.